Map Optimization wiki for DR really lacking

[Goldwell]

So I am trying to do some optimization for my map and when I turned to the wiki for help I found that the article for map optimization is rather lackluster and obviously incomplete.

 

Can someone please finish it or perhaps give me a few pointers please?

 

http://wiki.thedarkmod.com/index.php?title=Map_Optimization

[Sotha]

1) Make sure everything is visportalled properly. Put visportal in every door, and every corner so that views are blocked. You can examine visportalling in game with r_showtris 4 (or was it 3) and r_showportals 1.

2) func_staticify all detail objects. Only the sealing geometry should be worldspawn. Func_statics should be roughly 'object size.' A balcony is one func_static, one car is one fs, one chimney is one fs all ceiling beams in one room is one fs. Note that AI does not see func_statics, so you need to place monsterclip around each fs object the AI can walk to.

3) Make sure you properly monsterclip all areas the AI can reach. Raise monster_clip brushes sky high to avoid the generation of useless pathing areas.

4) Optimize lights. Avoid having more than 2 or 3 overlapping lights per scene. Turn every object to noshadows, except large objects that a person would expect to see casting shadows. Bottles and cheese wedges don't really need shadows! You can analyze your scenes by activating r_showprimitives 1 and walking in game. If the amount of shadow tris is high in a certain scenes, you should deactivate shadows. Remember, if you have one object of 1000 tris, and it gets hit by 3 lights, it will cost 1000(the object)+1000+1000+1000 (three shadows) tris! Patches are particularily shadow-hungry. If you have patch terrain, make sure you set them to noshadow: the ground generates a lot of shadow tris and projects the shadows below the patch, to the sealing geometry, resultlingin a lot of shadow tris nobody is gonna see. Ditto for wall modules.

[Springheel]

Turn every object to noshadows, except large objects that a person would expect to see casting shadows. Bottles and cheese wedges don't really need shadows!

 

This one is a bit of an artistic call. Small, low poly objects like bottles and cheese have a pretty minor impact on performance, but the lack of a shadow can make them look like they're floating, depending on the light in the room. I would only turn shadows off on props if you are desparate to squeeze out every last ounce of performance.

[RJFerret]

Heh, at first I was curious how you didn't find the wiki article complete, as Sotha basically summarized what I remember is saying, before realizing you found an old orphaned article from 2010! I added a wikilink in that article to this very comprehensive one Performance: Essential Must-Knows.

 

Although that article is lengthy and very detailed, I wonder if the post above can be put in as an overview intro, as it's more natural language/less minutiae is helpful and emphasizes the priorities.

 

Although it doesn't point out how much impact AIs in view have.

 

A note on patch shadows, if your terrain is varied or rugged enough to self-shadow, then you obviously won't want to turn those shadows off, or your terrain will look unnaturally flat/wrong. Obviously the key objects of which to turn shadows off, are those that would be casting shadows into areas never seen.

 

The command: "r_showprimitives 1" will list a stream of info in the console. As Bikerdude said in another thread, "the draw call count you want below 1500", more can be handled to varying degrees on different systems, but that's the breaking point where FPS starts to drop. So I'd check that first, to efficiently optimize areas that might be lower/more impacting, and not spend time on areas that are acceptable already.

 

A sneaky thing I have done in my maps where there could be lots of potentially overlapping lights, is simply reduce their vertical radius so they don't all reach the ground. (An outdoor campfire with up to five lights, one even moving, had surprisingly good performance this way, only two reached the big ground patch, three didn't.) The command: "r_showlights 2" shows light volumes in game.

 

It really helps to design to start with, avoiding long sight lines with lots of details in camera view. You'll notice most good maps have zig-zagging or twisting routes. On my WIP, I created an alley opening toward a building that had dismal performance when in the alley facing out regardless of closed visportals. Simply moving that area to the other side of a neighboring building doubled the performance.

[HMart]

This one is a bit of an artistic call. Small, low poly objects like bottles and cheese have a pretty minor impact on performance, but the lack of a shadow can make them look like they're floating

 

A way to minimize that floating looking would be to implement SSAO, that has also the benefit of making the levels require less real shadows, thats how Frictional Games worked on their Amnesia game, for example they sometimes only have a single shadow casting light per room but none of the objects feel obviously that they lack a shadow. SSAO makes wonders.

[Obsttorte]

What does SSAO stand for and what does it?

[RJFerret]

Gotta' love use of jargon to obscure info.

 

I presume not semicarbazide-sensitive amine oxidase, an enzyme, but: http://en.wikipedia.org/wiki/Screen_space_ambient_occlusion

 

But what darkening of corners has to do with optimizing shadows, I don't know.

[Lux]

Nvidia uses HBAO (horizon based). Here is a more general link that explains *some things more specifically.

 

http://en.wikipedia.org/wiki/Ambient_occlusion

[HMart]

What does SSAO stand for and what does it?

 

Screen Space Ambient Occlusion

 

sikkmod for doom3 has it but is really not ideally implemented has it doesn't not take into account alpha mapped surfaces.

 

Gotta' love use of jargon to obscure info.

 

I presume not semicarbazide-sensitive amine oxidase, an enzyme, but: http://en.wikipedia....bient_occlusion

 

But what darkening of corners has to do with optimizing shadows, I don't know.

 

I'm not trying to obscure anything, i don't know why you would think that, SSAO is a very well known (or so i thought) tech in the game dev world, it was invented by Crytek and used extensively on Crysis 1 and later games.

 

SSAO doesn't only darkens corners see this two Crysis images to now what it really does.

 

http://bassemtodary....-occlusion1.png

 

 

See the contact "shadow" of the dead soldier on the ground, with doom3 to have the same effect a real shadow would be needed, i'm not saying that with SSAO you don't need shadows what i saying is with SSAO you can use less real shadows and still make the world objects with no shadow seam like they are grounded.

 

Nvidia uses HBAO (horizon based). Here is a more general link that explains *some things more specifically.

 

http://en.wikipedia....bient_occlusion

 

Theres also HDAO for ATI and uses dx10+ geometry shaders it looks and runs better then SSAO, but the later works in all GPU's

 

For better info: HBAO also runs on AMD/ATI cards and the same is true for Nvidia with HDAO, but is best to use the tech from the respective makers in their cards because of optimizations.

Edited January 28, 2014 by HMart

[RJFerret]

I'm not trying to obscure anything, i don't know why you would think that, SSAO is a very well known (or so i thought)...

Sorry, I wasn't referring to your motivations at all. :-) That's just the purpose of jargon, to isolate others from your "tribe", a code that helped survivability in prehistoric people when they were competing for resources.

 

It helps not to abbreviate a term until after you've defined your usage of it, then folks may search/learn regardless of one's assumptions of others' knowledge. ;-) Thanks for the further insights/examples beyond my Wikipedia explanation.

[Springheel]

I'm missing something...where is the dead soldier?

[HMart]

Sorry, I wasn't referring to your motivations at all. :-) That's just the purpose of jargon, to isolate others from your "tribe", a code that helped survivability in prehistoric people when they were competing for resources.

 

It helps not to abbreviate a term until after you've defined your usage of it, then folks may search/learn regardless of one's assumptions of others' knowledge. ;-) Thanks for the further insights/examples beyond my Wikipedia explanation.

 

Apologies accepted , i will try to explain what i mean next time before using abbreviations.

 

I'm missing something...where is the dead soldier?

 

Theres two images there one is a simple link another is a image link, the dead soldier is on the first image, sorry for the confusion.

[Lux]

We're still allowed to google abbreviations aren't we?

[HMart]

Guys look to this Frictional Games article about SSAO it is fantastic, they even give the code they used away perhaps it can be of any use to you guys?

 

http://frictionalgames.blogspot.pt/2014/01/tech-feature-ssao-and-temporal-blur.html

[nbohr1more]

We have discussed SSAO before many times on these forums.

 

One of the main concerns is that it will change the lighting in existing missions and may break their

gameplay. I don't see that as a big concern when you consider that JC Denton's "enhanced ambient"

also added some new directional shading to missions which didn't seem to break anything... but theoretically

some mission authors might need to widen or brighten light sources to keep areas of their maps challenging.

 

The easy solution is to include a control to enable or disable the effect.

 

I can't speculate on the challenge of adding SSAO to this engine. The last I heard Sikkpin couldn't improve on his post process

method because of the strange way the Z Buffer works with Infinite Far Z.

 

I don't think his hack SSAO method is too expensive but others may disagree?

 

I think this is mostly a tabled discussion until the Dhewm3 merge where experimentation will be easier to do.

 

If someone wanted to post a patch to try out, that would be cool....

[Springheel]

I'm definitely open to the idea of SSAO or other graphical improvements, but to have a real chance of being implemented it needs to fulfill three criteria:

 

1. Not bugger existing maps.

2. Not require a massive overhaul of existing assets (like adding a new AO image to every texture in existance).

3. Not kill performance.

[Obsttorte]

To me it seems more like a cosmetical feature. If implemented as a post-process shader, I guess it shouldn't affect the lightgem value at all (I'm just guessing that this is independent from what get's actually rendered).

[Sotha]

..Aand if it DID affect the light gem, we could probably counter it with a lg modifier: if SSAO darkens the scene, apply an opposing ambient light bonus.

[HMart]

I'm definitely open to the idea of SSAO or other graphical improvements, but to have a real chance of being implemented it needs to fulfill three criteria:

 

1. Not bugger existing maps.

2. Not require a massive overhaul of existing assets (like adding a new AO image to every texture in existance).

3. Not kill performance.

 

1 - Don't know about that, but SSAO is just a post process shader that should not affect the real lighting values of the game or the gameplay code.

 

2 - Has a post process effect it has no real effect on the game textures, think of it like a real time photoshop filter over the final frame.

 

2 - It does have a toll on the performance (not much if you only use 8 or 16 samples) but you can counteract the small drop on performance by disabling real shadows (not important) on the game, is all a balance.

 

 

 

To me it seems more like a cosmetical feature. If implemented as a post-process shader, I guess it shouldn't affect the lightgem value at all (I'm just guessing that this is independent from what get's actually rendered).

 

That is what i think also, about only being a cosmetical feature, that is true but is more than that imo, for example like i said above and you can clearly see on the video of the Frictional Games guys, SSAO has the ability to fake "soft shadows", even on the moving objects, with that you can disable real shadows on the game and still have the feeling the objects are on the ground and not floating.

 

Frictional games used this to full effect on their Amnesia game, some rooms only have one shadow casting light and i don't remember seeing more than two per room on the entire game.

Edited February 1, 2014 by HMart

[nbohr1more]

The problem is that the current lightgem actually captures screenshots of the player view. Unless SSAO can be applied after those captures it will affect gameplay. With the source code this could now be fixed. I can't say how difficult it would be but I know historically the team has tried to avoid tinkering with the lightgem because of how crucial it is. I'd say its a worthwhile endeavor and would help bridge this visual gap between us and light mapped games.

[Sotha]

..But who would have the ability (and time) to experiment with this?

 

It didn't seem to be a lot of code, but it needs a skilled person to stick the code to the right place and weave it to fit with it's surroundings.

[Springheel]

Patches are particularily shadow-hungry. If you have patch terrain, make sure you set them to noshadow: the ground generates a lot of shadow tris and projects the shadows below the patch, to the sealing geometry, resultlingin a lot of shadow tris nobody is gonna see. Ditto for wall modules.

 

Does setting patch terrain to func_static have any effect on pathfinding?

[grayman]

Does setting patch terrain to func_static have any effect on pathfinding?

 

Yes.

 

For any given patch tri (func_static or not), it can be no higher than 13 off the underlying brush. If it is, then the AI won't be able to use the AAS area on the brush for pathing. (I think it's 13 or so.)

 

For rats, which are small, the distance is 6 or 8 or something like that.

[Springheel]

Wait, that's true regardless of whether it's funcstatic or not?

[grayman]

Yes.

 

And the distance limit of the patch above the underlying brush is around 80, not 13. So it's probably the AI's height.

 

The AAS areas are laid down on the underlying brushes, not on the patch, whether it's func_static or not.

 

Even though AI can't see func_statics, pathfinding will let an AI walk around on func_statics that have AAS areas beneath them.