Optimising Maps

[Springheel]

I'm curious about what kind of optimising people would recommend. I haven't really done much optimizing on my map yet, and I notice it takes a lot of time to load compared to other maps of its size. What would be some of the more important things I should do to decrease loading time and increase FPS? I've got it well visportalled, but how beneficial is it to do things like adding "noshaows" to things not hit by lights, or adding "noclipmodel" to things? I also haven't converted much to func_statics yet--is the idea there to combine as many worldspawn brushes as possible into a single func_static to get the most benefit?

 

The optimising page on the wiki is pretty light on explanations of these things.

[ungoliant]

one thing I have started doing in my map for performance is faking a shadow-mesh for complex brush func_statics by setting noshadows, and then using shadow texture patches in appropriate places.

[Baddcog]

Noshadows shouldn't effect compile time as it's a run time thing.

 

I think func_statics will decrease it a lot. As worldspawn they are cutting up your terrain into a lot more tris, that's compile time.

 

Best thing to do is group them.

 

ie: all vertical beams inside a barn one func_static. All horizontal beams (y) another func_static. all (x) horizontal another.

func_statics won't cut up terrain into more tris, but they will cut themselves up where they touch. So grouping them in peices that don't touch each other is best.

f_s 1 won't cut up f_s 2. So having the vertical beams in 1 group, and horizontal in another speeds up compile AND saves tris.

 

But f_s's also don't cull unseen faces, so it's best to caulk them as you go (pretty hard to do later). This is up for debate though, seems it doesn't make much of an fps impact to have the extra faces, but imo squeeking all the extra performance is worth it to get rid of as many as possible.

 

Anyway, you're probably looking at several hundred unseen faces in a barn with f_s beams, but if not f_s'ed you might have a thousand extra tris (unseen culled)

 

Also, func_statics are culled by portals. They can cross, but if the portal closes and one brush is on the open side, then all brushes in that func_static will still be drawn. (so group in peices within portal areas)

[ungoliant]

But f_s's also don't cull unseen faces, so it's best to caulk them as you go (pretty hard to do later). This is up for debate though, seems it doesn't make much of an fps impact to have the extra faces, but imo squeeking all the extra performance is worth it to get rid of as many as possible.

 

are you saying that dmap will not optimize out unseen faces on fs? wouldn't that result in more shadows being cast if a light hits it as opposed to leaving it as worldspawn? that would seem to reinforce the idea of manually creating a fake shadow mesh on complex fs, or even leaving some areas as worldspawn instead of converting to fs, if the performance hit on shadows is higher than the hit on tri-count.

[Sotha]

are you saying that dmap will not optimize out unseen faces on fs? wouldn't that result in more shadows being cast if a light hits it as opposed to leaving it as worldspawn? that would seem to reinforce the idea of manually creating a fake shadow mesh on complex fs, or even leaving some areas as worldspawn instead of converting to fs, if the performance hit on shadows is higher than the hit on tri-count.

 

Yes. All surfaces will be there on a func_static. Nothing is removed. You should always convert detail brushwork into FS. If they are worldspawn, they will generate useless tris, even if some tris are saved because of non-seen-surface optimization. Try it yourself. Make a map with a worldspawn wall and put a small 8x8x8 brush touching the wall. Save two varieties, the other with the 8x8x8 brush func_static and the other worldspawn. Your work will look exactly the same in-game, except in the worldspawn variety the wall is split into numerous useless tris because of that worldspawn 8x8x8 block. The func_static one will have two useless tris, which you could manually optimize away with caulk.

 

You can save Func_static tris with caulk:

http://modetwo.net/d...php?title=Caulk

[ungoliant]

i'm aware of the caulking concept, just never realized that it should be done with unseen faces on FS. I had always read that caulking unseen faces is nigh on being a rewardless endeavor. apparently there was a caveat that the principle does not apply to FS, that I didn't read, or somehow ignored. well this thread has definitely helped me a lot so far.

[Sotha]

i'm aware of the caulking concept, just never realized that it should be done with unseen faces on FS. I had always read that caulking unseen faces is nigh on being a rewardless endeavor. apparently there was a caveat that the principle does not apply to FS, that I didn't read, or somehow ignored. well this thread has definitely helped me a lot so far.

 

Caulking is good if you get it in your work flow. All mappers probably would benefit of this practice.

 

You make a func_static object, which you will clone and place in many locations. A window, perhaps, which you put everywhere. When you have created the object, it is worthwhile to spend 10-20 seconds to caulk all the unseen surfaces like seen in the image 1 of the wiki article. Then you should clone the object normally and place the object everywhere. This few seconds extra work will save a lot of tris if you duplicate the object.

 

Caulking is not worth it if you do it later so that you consider to manually go through all the surfaces of the cloned objects and caulk them. Don't bother.

 

But if you can save a lot of tris with a small workflow change, that is always good.

[ungoliant]

this is likely a practice I will adopt when DR 1.6 is released. At current I can see pixels from interior faces at every brush joint, resulting in lots of pink lines all over the place if i caulk interior faces, which is borderline on hair-ripping intolerable. Apparently this bug has been fixed, so once released i'll probably start doing this.

[nbohr1more]

One thing I've been wondering about is whether grouping func_statics is how you "batch" texture calls. Those Quake 4 mappers like Method and Lunaran keep mentioning batching in their optimization discussions and I can't for the life of me understand how you can tell Doom 3 to "process these textures together, then process this other set next" other than to group FS...?

 

Quote from Lunaran stating that batching textures gained enough performance to run as if the polys were cut to a 3rd of the amount:

 

 

One of the engine issues I tried to tackle was how texture variety kills performance by splitting batches. The idea I wanted to try was to build the map in something slightly more akin to the Geometry Competition process, with fewer larger and more featureless textures to model forms, and liberal use of decals on top (paged for batchiness) to add all those missing stains and seams and construction tells to the brushwork that are normally baked into the textures themselves. The idea is you get a lot of variety instead of repeating the same 128x128 panels all over, and also more freedom with brushwork, because texture application would be much more fluid and receptive, because you place all the welds and edges by hand. The big green machines around the map were built the same way - two big painted-metal pages, put together over a myriad of different machine-looking shapes with some rusty edge-trim applied wherever necessary.

 

Performance-wise it worked great: the main room of this map has about 160k triangles in the worst corners but runs as if it had a third of that...

 

[Baddcog]

I'm not really getting what you're saying and what that guy is saying about batching....

 

Basically batching should cause fewer draw calls, alot of engines do it automatically, Doom3 doesn't.

 

Func_statics should batch. ie, 2 beams as seperate F-S's would be 2 draw calls, as 1 f_s 1 draw call. Because they are now considered one piece. Much like have 2 pots as one model, it only would call that texture once per model. But 2 pot models, it would call the tex once for each.

 

I think what he's saying is he used a plain texture everywhere. Put a bunch of dirt decals over it for variety. Then func_staticed the decals all into one, so it only calls the texture of the decal once for the entire room, not 20-30 times.

 

So f_s a bunch of decal patches or wood beams should be very similar to using Seed to bunch models together.

 

Patches don't cut each other up, so you can bunch overlapping ones together unlike brushes and not have an effect.

Now I'm actually thinking this could improve performance in the Rift. I used a TON of patches, but most used the same texture. So areas in the caves probably have 50 drawcalls that could be 1.

 

Tel knows much more about this than I do, but I think that's right.

---------

 

@ ungoliant,

I'm not positive on this, and it doesn't seem like anyone is because the results are unexpected.

 

Say you have beams along a wall (f_s). The unseen faces aren't caulked so they are drawn. You have a light in the middle of the room. Every face it hits should cast a shadow. But I don't think the unseen faces do, as their normals point the other way. So caulking them doesn't give a big performance impact (as the biggest rendering impact is shadow casting). And they are 'culled' in game because player can't see them.

But they are still sitting on the processors waiting to be seen (or GPU, not sure).

 

BUT, if a light volume from the other side of the wall hits it it will cast shadows. Which is a waste because the wall blocks them anyway. I noclipped on one map that had a guard sitting in a chair next to a wall. Once no clipped I could see his shadow, and the chairs shadow casting through the wall onto a wall in the alley way. In game the portal and the wall behind him 'mask' that. But the lights cast the shadow of everything in their volume onto every face in their volume (so it seems the light in front of gaurd not only casts his shadow against the wall behind him, but also on the wall outside behind that wall...)

So the light outside is also casting shadows inward. If the door portal is closed then the backside of beams wouldn't cast through, but once the portal is open I think they would.

So the shadows that unseen faces are casting are coming from and completely different area then you would expect, not the obvious light right in front of them.

 

 

If caulked they aren't even sitting in cue. So it might not be a big gain, but every little thing you can take off the cpu or gpu is good imo. Especially on lower end systems.

 

Either way, some tests were done. I caulked a ton of faces in graymans castle map and we saw a little FPS gain but not much. Other tests didn't reveal a huge difference either.

----------

 

Anyway, caulk is great for editing. You can hit the filter caulk option, and it lets you see what will be there in game, whether it's f_s or worldspawn. Which is really nice with big complex maps, you can see into rooms instead of having to zoom into them.

You can zoom way out, see the entire map and look into it, not see a bunch of boxes.

[nbohr1more]

Yeah, that makes sense now. Group your decal patches into a single FS or use SEED to selectively group 'em depending on distance... if you want to go for hardcore optimizing...

 

Though I think more distance parameter tweaks or occlusion parameter tweaks will be needed for SEED show reasonable gains for that effort...

 

Now this has me wondering "If seed_combine could group differently depending on which visportal view or view-direction you are seeing, then we'd probably be as low to the metal for view optimization as you could practically get with this approach..?"

[grayman]

I caulked a ton of faces in graymans castle map ...

 

I made a castle map?

 

Gee, I'm more prolific than I thought.

[Mortem Desino]

Here's a good example of Func_Statics still cutting up into tons and tons of tris:

Here I've got some bumpy terrain. It's just one patch. On either side of the terrain is brushwork.

 

_______

What happens if It's all left as worldspawn?

Ugh. Yuk.

 

_______

 

What if I make all 7 items one func_static?

Better, but no cheeseburger.

 

_______

 

Now, suppose I make the brushes their own func_static, and the patchwork its own func_static.

Now, that's more efficient cutting of tris. I can optimize out about 16 more tris with caulk (a minor issue). The difference from this one to lets-make-em-all-func-static is over 80 tris. Plus ~40 tris more than when it was all worldspawn.

 

 

 

 

 

Now, people may balk and say that Doom3 can push the tri count. That's absolutely true. But having overlapping lights (say, moonlight and and streetlight, and a stray torch light volume from inside a nearby building,) cast onto this before it was optimized would really kill graphic performance.

 

Which brings me to an aside point: Even if it's all noshadows, multiple overlapping light volumes (usually more than two lights) can start to kill performance.

[Baddcog]

Exactly, and that last shot still shows faces under the patch, that can't be seen, yet they are rendering. Caulking them would just optimize more.

 

I knew patches still cut up worldspawn, but when I was last mapping i don't think I knew they could be func_staticed. So wasn't sure if that would help to stop them from cutting up surrounding terrain, looks like it does.

So I really see no reason to not make patches func_statics. They don't seal anyway.

[nbohr1more]

It appears that you can gauge your batching via "r_showbatch" in Quake 4 (not possible in Doom 3) so it might be worth it to pickup that title to help diagnose portal loads.

 

Old D3W gem:

 

http://www.doom3worl...9&view=previous

 

Related:

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=8&t=20800&view=next

Edited April 4, 2011 by nbohr1more

[Bikerdude]

Springs.

 

the other things to way to check how your map is gonna perform (I got this tip from jdude) is to use 'r_showtris 2' what you looking for is to see what the engine is rendering out of site of the player. Here are some screenshots, one with a VP in place and working and one with it removed. You can see how the WS is render outside of the room with the VP removed, this is whats considered bad optimization.

 

the same 'tris-way-of-working' applies to the rest of the map, you try an limit whats get rendered so as to keep the draw call count under 1200-1500 in any given direction the player might look. And talking of draw count, type 'r_showprimitives 1', then look at the draw count - see attached. For example, on map you consider portaled and tris'd correctly but still getting crap fps, use the r_showprimitives to show the draw count, then you can remove items from the map, or choose to put a func_portal on a VP and change its close distance to get the draw count down when a player looks that way up the map etc.

 

The other thing to consider when thinking about fps as in that show primitives screenshot, is whats going on in the background - which would explain my low fps of 38 in that screenshot. Dont forget to change the think distance and intervale on Ai and if possible add change the 'neverdormant' to '0' if they are in a part of the map where they don't need to be active using up valuable cpu cycles. The statmap isnt a good exmple here as its has way more stuff and Ai in a map hat a player would otherwise have.

 

Its what I used to get the draw count down and the fps up on RTTC-v2.

[demagogue]

Everyone mentioned good things. I'd just add that reducing lights (or spreading them out) and noshadows at some places does help.

 

One thing about turning border-work brushes into func_statics is that it can inadvertently open up internal leaks or deadly slivers in the seams it was covering up. So I found it good to do it a few at a time and make sure it didn't break anything, though I might have been better off with cleaner brushwork to begin with.

[nbohr1more]

Added this thread to the "Performance: Essentials Must-Knows" wiki.

 

Another related thread:

 

http://forums.thedarkmod.com/topic/11530-avoiding-sudden-framerate-drops/

Edited April 5, 2011 by nbohr1more

[Baddcog]

Everyone mentioned good things. I'd just add that reducing lights (or spreading them out) and noshadows at some places does help.

 

One thing about turning border-work brushes into func_statics is that it can inadvertently open up internal leaks or deadly slivers in the seams it was covering up. So I found it good to do it a few at a time and make sure it didn't break anything, though I might have been better off with cleaner brushwork to begin with.

 

I've been thinking of posting some shots up of detail vrs structure. Would be a cool thread to see editor screenshots of everyone's maps like this.

 

A shot of all details hidden, only worldspawn showing. The exact same screenshot with all func_statics/patches showing. I try to never use detail brushes at all to fill the void.

All world spawn should just be very blocky basic terrain. Then detail is tacked onto that.

 

the exception would be a wood beam that is flush, but divides a top/bottom of a wall. (Where I have one wall, then just cut it twice to put a trim through it.

[Sotha]

All world spawn should just be very blocky basic terrain. Then detail is tacked onto that.

 

Amen! The sooner the mappers realize this, the easier their lives are gonna be..

[demagogue]

I just don't like everything being so square. I don't mind basic blocks, but a few non-90-degree angles go a long way. In my original style of building, I used to cover up the intersections with border brushwork. That's how I got myself into trouble later. But it's possible to have brushes with acute and obtuse intersections without trouble if you do it carefully, without slivers (e.g., cutting a flush seam). And it makes the space so much more dynamic and interesting IMO.

 

 

Edit: BTW, I love that there's a place where I can talk about the dynamic and interesting features of room space and wall angles. This is not something I can usually do in day-to-day life.

[Baddcog]

Yeah, I'm not saying everything has to be 90* angles.

 

For example I took a look at RTTC to help Melan optimize. There were a lot of brushes of all types that were odd shaped.

 

Say like a cylindrical building that is non-enterable. That cuts up a lot of terrain and is IMO not good to sink a vp into to try and seal.

 

Instead I f_s'ed it, then built walls of caulk inside to make a square room with a nice square vp seal. Still looks the same to player, but is easier to compile and cuts tris a ton.

------------

 

This is a thread on the tf2maps.net forums that is what I'm taking about doing here so authors get a better idea of how simple geometry should really be. Of course there are differences between Hammer and Radiant, but they are very similar engine and work in very similar ways.

 

http://forums.tf2maps.net/showthread.php?t=1429&highlight=structure+detail

 

One thing hammer does is the flat colored polys seen in a lot of these shots. I don't know if DR does that, but I think just having base textures is fine, in fact better because these shots don't show useage of No Draw (caulk) to seal behind patches, etc...

 

Here are a few shots of my older maps. These could be optimized more and aren't they best examples

 

in fact since then I've realized that they are still too complex and in the Damn map I've improved performance even more.

[OrbWeaver]

One thing to note about turning detail into func_statics is that while it does indeed reduce polygon counts, sometimes reducing polygon counts results in increased light counts (because you have a few large surfaces hit with multiple lights), which in some situations might nullify the performance benefit you get from simpler geometry. Obviously it will depend on the circumstances of the particular map (as well as the hardware it is being played on), but it may not be an automatic win to turn every piece of detail into a func_static without testing the before-and-after performance.

[rebb]

This has probably already been mentioned somewhere, but much what is being said on this page http://www.iddevnet.com/quake4/LevelEditor_Performance also applies to Doom3 Mapping - even tho Doom3 is missing many of those nice debug CVars.

[Melan]

One thing to note about turning detail into func_statics is that while it does indeed reduce polygon counts, sometimes reducing polygon counts results in increased light counts (because you have a few large surfaces hit with multiple lights), which in some situations might nullify the performance benefit you get from simpler geometry.

It is this balancing act that makes it hard to wrap my head around optimalisation. Should a mapper place priority on details, surfaces, drawcalls, light count or what? Generally, we can set up general guidelines like "don't go overboard with details in your basic mission architecture", "break up lines of sight" and "cut down on shadowcasting/overlapping lights", but if you go into the details, these are more tradeoffs than absolutes.

 

Also, there is a level of simple basic architecture beyond which you have to start placing monsterclip to compensate for "squarified" building footprints (func_static does not block pathfinding), but as I have found, monsterclip should not intersect with visportals -- which is a new layer of complication to itself.