Newbie DarkRadiant Questions

[MirceaKitsune]

For users who didn't see my post in the other thread: I shared a screenshot of how I'm doing vis portals in large open areas, using what I call "virtual cubes" via portals that are edge connected around the faces / edges / corners of large buildings essentially radiating from them.

As I said there it seems to be working well. That is for visuals at least: As @Dragofer pointed out, sound can also impact performance with portals. Currently I only added one long range speaker: Toggling it didn't seem to affect performance, though I'm getting some unexplained FPS drops in certain angles which I'd like to be able to better debug.

Street lamps aren't visible from too far away, I've kept the area cramped enough to have efficient portaling. I was just thinking that if I could turn lights off based on distance I could improve performance even further, without too much detail being lost and becoming visually annoying. If this isn't possible yet I can skip that optimization, though I could have sworn I once read about LOD for lights being implemented or someone told me they were very long ago.

Edited June 30, 2021 by MirceaKitsune

[stgatilov]

On 6/30/2021 at 12:45 AM, Geep said:

In DR, I examined the "Hare in the Snare" FM you mentioned, but that just provides custom art to the main menu, as well as video brief & debrief; not helpful for what I need.

It displays its own GUI (completely unrelated to main menu) manually:

Spoiler

// entity 3788
{
"classname" "atdm:gui_message"
"name" "debrief_video"
"gui" "guis/debrief.gui"
"origin" "-1008 -1081 203"
"show" "56"
}
// entity 3789
{
"classname" "func_static"
"name" "debrief_rug"
"model" "models/darkmod/decorative/rug_round_small.lwo"
"origin" "-744 72 112.075"
"rotation" "1 0 0 0 1 0 0 0 1"
}
// entity 3790
{
"classname" "info_location"
"name" "location_debrief"
"origin" "-742 69 167"
}
// entity 3791
{
"classname" "speaker"
"name" "debrief_speaker"
"origin" "-1040 -1008 256"
"s_global" "1"
"s_maxdistance" "10.000000"
"s_omni" "1"
"s_shader" "video/hits_debrief_video_sound"
"s_waitfortrigger" "1"
}

 

You can implement whatever you want in this .gui file.

[Destined]

11 hours ago, MirceaKitsune said:

Street lamps aren't visible from too far away, I've kept the area cramped enough to have efficient portaling. I was just thinking that if I could turn lights off based on distance I could improve performance even further, without too much detail being lost and becoming visually annoying. If this isn't possible yet I can skip that optimization, though I could have sworn I once read about LOD for lights being implemented or someone told me they were very long ago.

This could be achieved with location settings. You could use a script that turns off lights, when you leave the location and turn it back on, when entering. However, this requires a lot to set up (if you don't use the location system already) and planning to get set the locations in a way that the player does not see the lights go out and back on. But it would at least be an option.

[OrbWeaver]

On 6/29/2021 at 7:05 PM, MirceaKitsune said:

I remember someone expressing interest in how I create what I called "virtual cubes" out of vis portals, to have open outdoor areas be more performance efficient. Figured I'd share this screenshot which exemplifies a part of it.

The question is: do you see an actual performance difference in terms of FPS with/without those portals?

[MirceaKitsune]

  @OrbWeaver Replying here since as Dragofer said this thread is more fitting for discussing the portals.

1 hour ago, OrbWeaver said:

The question is: do you see an actual performance difference in terms of FPS with/without those portals?

For one of my cities yes: Adding a ton of those visportals actually had a small noticeable performance benefit. For the other one I couldn't see any, there's still a FPS drop I cannot explain from some positions / angles which I could use a way of debugging if anyone can suggest me a view command.

For reference: This is what the area where I get great performance looks like. I know it might look scary but this actually works nicely

[Dragofer]

"LOD" for lights could be done with a looping script that compares the distance of all lamps on the map to the player's position every 0.5s and turns them on or off. But lamps are really visible because of how they light up a whole area so it'd be quite noticeable.

And really, the elephant in the room for performance is how open a scene is. For example, in this shot you have long straight streets with islands of buildings, with the result that most of the visportals in this scene would only ever close if you completely turned your camera away from them. The player gets a peek into many visleafs simultaneously.

Looking at a mission like Fiasco at Fauchard Street could be really useful for inspiration. Here the streets are narrower and wind their way through closely packed towering buildings, giving lots of easy opportunities for effective visportals and keeping the player wanting to find out what's around the corner. Probably most players enjoy a flat 60fps here with no need for further optimisation from the mapper.

Perilous Refuge is a quite open mission thematically because of the harbour, but it uses architectural features like an underpassage, a tunnel and how the streets are laid out around the buildings in order to minimise how many locations are rendered simultaneously.

 

[peter_spy]

2 hours ago, MirceaKitsune said:

For one of my cities yes: Adding a ton of those visportals actually had a small noticeable performance benefit.

You mentioned that you don't use commands like r_showprimitives, you may want to use it to check if there is any tangible benefit. E.g. I bet that and these "virtual cubes" do nothing, as they don't have any brushwork to work with. You just seem to repeat what player frustum is doing already.

[MirceaKitsune]

37 minutes ago, Dragofer said:

"LOD" for lights could be done with a looping script that compares the distance of all lamps on the map to the player's position every 0.5s and turns them on or off. But lamps are really visible because of how they light up a whole area so it'd be quite noticeable.

And really, the elephant in the room for performance is how open a scene is. For example, in this shot you have long straight streets with islands of buildings, with the result that most of the visportals in this scene would only ever close if you completely turned your camera away from them. The player gets a peek into many visleafs simultaneously.

Looking at a mission like Fiasco at Fauchard Street could be really useful for inspiration. Here the streets are narrower and wind their way through closely packed towering buildings, giving lots of easy opportunities for effective visportals and keeping the player wanting to find out what's around the corner. Probably most players enjoy a flat 60fps here with no need for further optimisation from the mapper.

Perilous Refuge is a quite open mission thematically because of the harbour, but it uses architectural features like an underpassage, a tunnel and how the streets are laid out around the buildings in order to minimise how many locations are rendered simultaneously.

 

I didn't wish to sacrifice the city design and make it way too closed: I used towers and buildings in between to create portals around, precisely so I could have an open design but with good performance too. I may make tweaks to the architecture to further improve this in the future.

One reason why I made those portal cubes: I have different areas or buildings at different heights. Using this system can hide at least a horizontal slice of an area behind a building, thanks to the view being under or over a horizontal portal thus closing it as the view doesn't go all the way around it. That was the one reason for this in my previous screenshot... without the horizontal ones you wouldn't be seeing the red portals closed over in the back (they would be green and active).

Another trick I use is leaving the tops of buildings textured with portal_sky: This prevents buildings from appearing as if they're all at the same height, while still allowing portals to be connected in between them. Only thing you need to be careful about is that you can't see anything through them, otherwise you'll get the sky cutting in front of geometry... dealing with this in a few places already but finding ways to improve the effect.

  

7 minutes ago, peter_spy said:

You mentioned that you don't use commands like r_showprimitives, you may want to use it to check if there is any tangible benefit. E.g. I bet that and these "virtual cubes" do nothing, as they don't have any brushwork to work with. You just seem to repeat what player frustum is doing already.

I'll give it a go next time I test, thanks. It would be useful to know more of these commands, as well as the general polygon count that I wouldn't want it the engine reporting more of at any given time.

[OrbWeaver]

What Peter said.

Some of those portals are clearly useful because they are turning red (so occluding some geometry), and maybe some of the tall thin ones around the edge are useful to turn the open space into a sort of square donut shape where opposite corners don't necessarily need to be rendered.

But you still have a huge number of portals which appear to do little or nothing. For example the large horizontal portals hovering in mostly empty space don't seem to add much value, since they will probably never close and don't contain anything to hide even if they did close.

[MirceaKitsune]

13 minutes ago, OrbWeaver said:

What Peter said.

Some of those portals are clearly useful because they are turning red (so occluding some geometry), and maybe some of the tall thin ones around the edge are useful to turn the open space into a sort of square donut shape where opposite corners don't necessarily need to be rendered.

But you still have a huge number of portals which appear to do little or nothing. For example the large horizontal portals hovering in mostly empty space don't seem to add much value, since they will probably never close and don't contain anything to hide even if they did close.

True, I'll have to redo my setup to reduce them and pack them even more intelligently. Case in point: This is from the third and final city. I used to think this octagonal tower radiating portals to the surrounding walls would be very effective... it seems there are angles from which most of the area will still be open unless you're standing very close to the tower. Really sucks.

@peter_spy I used "r_showprimitives 1" from positions and angles where I get unexplained slowdowns. Here are two outputs I get, let me know if they seem a bit too much.

views:4 draws:4077 tris:759959 (shdw:0) (vbo:759893) image:192 MB
views:4 draws:1710 tris:168725 (shdw:0) (vbo:168701) image:192 MB

 

[roygato]

31 minutes ago, MirceaKitsune said:

I didn't wish to sacrifice the city design and make it way too closed: I used towers and buildings in between to create portals around, precisely so I could have an open design but with good performance too. I may make tweaks to the architecture to further improve this in the future.

This is one of the tragedies in mapping for this game. I'd love some Dishonored city-missions, with wide streets, tall buildings and long sight-lines, but it may be unattainable with acceptable performance.

[OrbWeaver]

26 minutes ago, MirceaKitsune said:

Here are two outputs I get, let me know if they seem a bit too much.

views:4 draws:4077 tris:759959 (shdw:0) (vbo:759893) image:192 MB
views:4 draws:1710 tris:168725 (shdw:0) (vbo:168701) image:192 MB

 

It's been a while since I checked polygon counts in actual missions, but to me the second one looks fine but the first one is huge. That's almost a million triangles in one scene.

You'd need r_showTris=2 (or 3) to see exactly where the triangles are coming from though. With a number that high, I wonder if you have a reflective surface (e.g. water) which requires the whole scene to be rendered again just to produce the mirror effect.

[peter_spy]

40 minutes ago, MirceaKitsune said:

views:4 draws:4077 tris:759959 (shdw:0) (vbo:759893) image:192 MB

views:4 draws:1710 tris:168725 (shdw:0) (vbo:168701) image:192 MB

It's a bit hard to interpret these numbers without screenshots but the first one is indeed a bit high. Also, either none of your lights are casting shadows, or you have shadowmaps on, since shdw value is 0. I think it's safer to use Stencil Shadows for prototyping FMs, since what I gathered from talks with Cabalistic, shadowmaps are still a very unoptimized feature. If you want a nice compromise between quality and speed, set Soft Shadow Quality to Low or Medium. This way you will have some numbers in the shdw column which is also an important metric.

[Geep]

@stgatilov

Regarding the Hare in the Snare FM,

Quote

it displays its own GUI (completely unrelated to main menu) manually...

Yes, but what it's displaying is a video for debriefing. I've already got invoking a video covered.

Quote

You can implement whatever you want in this .gui file.

Sure, and maybe I'll research it. Still would like to find an example of someone else already having deployed a mid-game single-slide gui, to save me from having to experiment.

[Geep]

@Dragofer

Could you say a bit more about large speakers crossing visportal cubes causing rock-bottom fps when TDM calculates sound propagation across them? This is the first I've heard about this engine bug, and it's concerning. In particular -

Is this something inherent to the visportal cubes configuration (such as visportals not associated with doors; or mix of horizontal and vertical portals) or just due to the total number of visportals that the speaker sphere encompasses?

Will an info_location also have such a problem with the total number of non-location-boundary visportals contained within it?

 

[Dragofer]

@geep It happened anytime I subdivided an open space, i.e.:

- a house with an accessible roof, an inner yard and surrounded by an outdoor wilderness. The offending visportals were vertical, all around the top of the roof. Turning them into caulk resolved it.

- a beach with various houses subdivided into a grid with horizontal subdivisions at the level of the rooves. Even when the visportals were bordered by thin caulk pillars instead of adjacent visportals, the map was unplayable.

I think the problem is just with having a speaker crossing many large visportals, and reaching into areas from several directions.

I can't say what role info_locations have.

 

Regarding the visportal discussion, I've moved the remaining 2 posts over here too because the conversation was getting a little disjointed.

[peter_spy]

Oh and one more thing about measuring performance, which might be worth a separate article actually: have you tried using frametime instead of FPS counter? IMO this is should be much more useful metric for mappers, mostly because you'll be aware how much overhead you have, at all times, as opposed to FPS going below 60 when something is already very wrong.

To use this, in your video settings set your Vsync to Off, set Uncap FPS to On and use highest Max FPS available (400). Also bind a toggle r_glProfiling 0 1 to a key. When you toggle the profiling, you'll see the breakdown of rendered components, but you can ignore most of it and just focus on the uppermost value for the GPU:

This is, roughly, how long it takes you GPU to draw one frame. If you want to have 60 FPS in your mission, you need to stay below 16,6 milliseconds. And this way you know, that when you reach e.g. 8,3 ms, you're at approx. 50% capacity of your hardware.

Now, let's say you have a section which is barely detailed, but you've already going above 10 ms, then you know that something might be wrong, and it's time to check showprimitives to look for the possible culprit.

Edited July 1, 2021 by peter_spy

[MirceaKitsune]

I'm baffled: From one of the problematic angles, I am in fact able to pass one million triangles being rendered at a time. Amazing my GPU handles it so well and I barely notice what I can call an annoying FPS drop.

I have no idea where they could be coming from! I have simple brush geometry with only a few standard models and prefabs in view as well as a bunch of AI, everything is aligned to the grid and of course no map leaks. Could I be running into some bug that's causing dmap to duplicate or overly subdivide surfaces?

Here are two screenshots with r_showtris 1 enabled as well. As you can see I don't have that much going on in the view... yeah there are a few models on but seriously it couldn't be a million tris. Note that I added a few func_emitter particles here but the issue existed before them so don't worry about that.

[MirceaKitsune]

Okay something must be going wrong somewhere: I'm in a different area in a small room that's well isolated by portals, only a few models (albeit somewhat high-poly) and an AI, roughly 8 torches if we count the other room through the grate. This place also gives me a huge performance hit. I tested once more and even in here it tells me I'm rendering one million triangles! It makes no sense, I just couldn't be reaching quite this much with only a few models.

[nbohr1more]

What is your light count?

Each light generates new triangles within it's bounding box.

[Wellingtoncrab]

I think r_showtris 1 only shows directly drawn triangles, which if I understood correctly from the DR tutorial videos aren’t all the tris calculated by the engine when rendering a frame. While there are not so many tris directly drawn in your scene, there could be overdraw if there is a “leak” between intended visleafs or just by the nature of the long sight lines and open portals in your scene. You could perhaps see by using r_showtris 3.

[nbohr1more]

1 hour ago, Wellingtoncrab said:

I think r_showtris 1 only shows directly drawn triangles, which if I understood correctly from the DR tutorial videos aren’t all the tris calculated by the engine when rendering a frame. While there are not so many tris directly drawn in your scene, there could be overdraw if there is a “leak” between intended visleafs or just by the nature of the long sight lines and open portals in your scene. You could perhaps see by using r_showtris 3.

Yes, r_showTris 1 only shows the final visible tris. Since this is not a deferred rendering engine, many triangles are drawn or go through drawing phases before the final image is created. I think r_showTris 2 is more accurate to the real amount of work done.

[peter_spy]

Yup, you can use showtris 2 or 3 with showportals to see whether your portals work with your brushwork to cull the geometry:

 

About lights, nbohr is right, they act as multiplier to your number of tris, every object hit by a light gets redrawn. Multiple and overlapping shadowcasting lights are the fastest performance killer.

IIRC, the tris also get redrawn if you have additional material stages, i.e. other than diffuse normal and specular.

You can also use that gl profiling command to see what takes most time, e.g. DrawInteractions is for lights, ShaderPasses is for materials.

[OrbWeaver]

High light counts are one possibility. I'd also look at your models carefully to check their polycounts (you can see this info in DR in the Model Selector). I wonder if some of those chain models have high polycounts due to the many small links.

[peter_spy]

That gate at the end of the corridor looks like it uses geometry for all the ornamental pieces instead of alphatest parts, so that might be a culprit as well.