Optimising Maps

[Springheel]

but as I have found, monsterclip should not intersect with visportals

 

This can't be a hard and fast rule, because I have more than one visportal where monsterclip passes right through it without any pathfinding problems.

[Melan]

Monsterclip through VPs doesn't cause pathfinding problems, but it has crashed the dmapping process on multiple occasions in my missions. Then again, I used large blocks going through multiple VPs to cordon off entire map sections (and keep down the AAS file size), maybe I shouldn't have done that and kept with smaller individual MCs.

[Baddcog]

Well, regarding lights and monster clip.

 

Brushes can be cut at boundries to compensate for those issues.

 

I had to do that in the outside area of Heart. The ground had some really big tris and a lot of lights hit them. I just sliced the ground in half, made sure lights didn't hit both halves if they didn't have to. Then pulled the verts down a little bit so the ground wasn't a flat plane but not noticeably bent. That way it wouldn't optimize back into a few tris.

 

Generally looking at tris and light counts you can easily see problem areas and it's a fairly easy fix.

[Mortem Desino]

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.

That's a bit of a rare occurrence, but I've experienced this in large indoor/outdoor areas (the NHAT 1 cathedral I think was it). Lots of long, thin tris, each one that may get overlapping light volumes hitting it.

 

Crashing VPs? That only has happened to me when non-parallel visportals meet in open air (see picture). (If the visportals are all parallel, and create one flat plane, all is good.)

That's a no-no that violates the rule "Visportals must have worldspawn on all sides", But it will still compile. If the player walks through it during runtime, freeze crash!

[Baddcog]

And that could easily be fixed by making the non-door visportal angled to meet up to the wall at either side of the door.

[Tels]

That's a bit of a rare occurrence, but I've experienced this in large indoor/outdoor areas (the NHAT 1 cathedral I think was it). Lots of long, thin tris, each one that may get overlapping light volumes hitting it.

 

Crashing VPs? That only has happened to me when non-parallel visportals meet in open air (see picture). (If the visportals are all parallel, and create one flat plane, all is good.)

That's a no-no that violates the rule "Visportals must have worldspawn on all sides", But it will still compile. If the player walks through it during runtime, freeze crash!

 

I think the problem here is that you have 3 rooms meeting in one point, instead of the maximum allowed 2. A visportal is supposed to sep. two rooms only.

[demagogue]

Yeah I think that's right. When you look at the way rooms (leafs) are constructed in the .proc, and a VP is defined as a surface separating the two volumes, I could see how it would spazz when one VP surface covered 3+ rooms. Otherwise, as long as it's just facing 2 room volumes, it's not a problem for the VP to be made of multiple VP-brushes and I believe even at multiple angles, as long as it's a sealed surface separating the two.

[Springheel]

Is there any benefit to making out of reach func_statics noshadows 1, if they aren't hit by any shadowcasting lights? Say, the trim at the top of a building that is only hit by the ambient_world light?

[Mortem Desino]

That's a good question!

 

First instinct says: no, since it's not inside any light volume. I noshadows it anyway out of habit now. Make it future-proof.

[Tels]

Is there any benefit to making out of reach func_statics noshadows 1, if they aren't hit by any shadowcasting lights? Say, the trim at the top of a building that is only hit by the ambient_world light?

 

There won't be any (or much of it) speed advantage, so I'd not set it to noshadow. You never know when you add a light (and forget to remove the noshadow), or when the player manages to go up there with his lantern and moves the missing shadows. Could even throw a candle up there and notice them missing.

 

And all that for not getting any performance advantage - so in my book, no. Use noshadow as a very very last optimzation resort.

[Mortem Desino]

Okay, I've changed my mind. Tels' future proofing is much smarter than mine.

[Springheel]

Ok, thanks.

 

Next question...is there any performance benefit to setting func_statics that can't be reached by the player/AI to either nonsolid and/or noclipmodel? A trim on the second floor of a brush building, for example.

[Melan]

Next question...is there any performance benefit to setting func_statics that can't be reached by the player/AI to either nonsolid and/or noclipmodel? A trim on the second floor of a brush building, for example.

Take extra care with that, since players can, and will try to get up everywhere, and it is really jarring to find an element of architecture to be non-solid. If it is just a minor trim, it may not matter, but even then, the player may try to hit it with an arrow or something, and then the bluff is up.

[nbohr1more]

As I understand it, the physics system will become more encumbered the more stuff there is to track. Though mostly this is done to keep map sizes small rather than for performance.

[Bikerdude]

Yes, this would considered good mapping practice. As having FS instead of loads of WS reduces draw calls. Also with said FS I have always set them to noclipmodel and noshadow so they present as low an overhead to the engine as possible. But there are things you need to be aware of..

 

• 
   
  
• When making an bunch of WS(worldspawn) FS(func_static), you should always apply the caulk texture to the hidden surface's.
  
• Always be aware of player view in regards of VPing, even if a small part of the FS can be seen pocking out past the wall of building the whole FS will be rendered. For example if you have a bunch of windows on the side of a building, it would be better to either have each as an individual FS or in pairs to make an FS.
  
• Dont be tempted to created big single FS, as I have learned it dosent help with perf
  
• I have also learned then having your chosen WS as FS or a model makes no diff to the engine in regards perf, but the advantage of FS is you can go back and make changes should you need to.
  

 

I learned the above after releasing my cathedral map, so when I did the updated I was able to squeeze extra perf from the mission. Jdude was the first person to show me the error of my ways in regards the above when I was working on lemony coast map etc. When i saw how it should have been done I was like, "ah, I see now, doh!" I then put all that I had learned into making "Return To the City version 2".

 

The other thing you might consider that I have just been started learning about and see on map done by Dram is to use triggers to remove/add entities to the map on the fly. Sorta like how func_portals turn VPz on/off etc. I can see this being very helpfull in that you can remove entities from being rendered/computed by the engine, thus saving yet more perf.

[nbohr1more]

The most depressing thing I've read recently is that texture variety is pretty high on the list of performance offenders. If you can find places where the textures variety can be reduced and grimes \ decals can make it look acceptable then that is another (painful) option... Though making a texture atlas out of a bunch of the textures in a scene can reduce this problem a great deal. (a lot of work though...)

[Melan]

The most depressing thing I've read recently is that texture variety is pretty high on the list of performance offenders. If you can find places where the textures variety can be reduced and grimes \ decals can make it look acceptable then that is another (painful) option... Though making a texture atlas out of a bunch of the textures in a scene can reduce this problem a great deal. (a lot of work though...)

Hah! This is hardly productive from me, but if texture variety reduces performance, than performance can <expl. del.> and also <expl. del.>, plus do me a favour and <I guess I will stop now>.

 

Seriously, compromises are sensible, but there are some simply not worth making. The balance of which I guess is the fine art of optimalisation.

[OrbWeaver]

The most depressing thing I've read recently is that texture variety is pretty high on the list of performance offenders. If you can find places where the textures variety can be reduced and grimes \ decals can make it look acceptable then that is another (painful) option...

 

I don't really buy that as a performance optimisation: it is true that multiple textures require multiple draw calls, which may have a performance impact, but applying decals also requires extra draw calls, since the decals are separate textures too. Using decals instead of a single large texture is a possible way of avoiding excessive texture size, but it's not doing anything to reduce texture count.

[nbohr1more]

The concept is that the decals are repeats of the same decal texture. You can then group them into a single func_static that applies all decals with the same texture at once.

 

That was a method used in Strombine.

 

Edit:

 

Texture Sheet concept (texture atlas):

 

http://wiki.splashdamage.com/index.php/Texturesheets

Edited April 11, 2011 by nbohr1more

[Baddcog]

I don't believe making f_s's non-solid matters to performance. It only matters if collision detections are run right?

 

So a wood trim high up on a house only comes into play if the play throws/shoots something at it. Tries to walk on it, whatever. So I say leave collision just in case.

 

-----------

I think tex useage mainly depends on the users GPU. I have a gig of ram on mine alone. So more tex might take more load time, but i see no performance lost due to too many textures/in game loading. Most cards have at least 512MB anymore which is a pretty decent amount of space for DDS. Really it's the TGA normals that are hurting us here, and if we get the normal/dds thing solved load times and texture usage will improve a lot.

 

------

Tying bunches of decals together if the use the same tex is good way to decrease draws and vary textures. I think mainly it just takes smart usage of textures to get the biggest impact for low end users. Don't use every tex available in DR in one area. And don't have every texture swap out at every vp.

 

ie, in the first 2 vp's use stone_01 and swap it out at 3rd vp. use wood_01 in vp 1, then swap it out for wood_02 in vp 2,3,4... That way you cross vp areas and unload/load 1-2 textures at a time, not 20-30. Keep a smoother cycling of textures throughout areas instead of drastic changes.

[Mortem Desino]

I don't believe making f_s's non-solid matters to performance. It only matters if collision detections are run right?

 

So a wood trim high up on a house only comes into play if the play throws/shoots something at it. Tries to walk on it, whatever. So I say leave collision just in case.

But all that collision information in static objects gets stored in the dmap file *.cm. That file can get awfully large. Not a major concern, but if you're strapped for RAM and malloc calls, that might be a solution.

[nbohr1more]

The Great "Light Carve" challenge:

 

1) Optimize your map by manually splitting large surfaces to reduce light counts

2) Set some items to Func_Static and caulk (etc)

3) dmap and check your FPS

 

4) save a backup

 

5) Use a "light carve dmap": dmap lightCarve map_name.map

6) Note how much bigger the map compiles to

7) compare your FPS to step 3

 

Who can get closest to the FPS (or better) of lightCarve and keep their map small.

 

Any takers?

[OrbWeaver]

1) Optimize your map by manually splitting large surfaces to reduce light counts

 

Good luck getting any noticeable difference in performance by doing that. If lightCarve makes a difference, it is because it is carving everything, everywhere. Manually splitting the odd brush here and there would be a monumental waste of mapper effort.

[demagogue]

You ask but then didn't actually put any example baseline numbers for a sense of scale.

 

What kind of improvement in FPS can lightCarve do for a familiar FM scene, and how much bigger does it make the map? Are we talking like roughly +10 FPS for +30MB or what...

[Baddcog]

In the courtyard at the begining of Heart I split the ground brush in two, angle each one so they wouldn't merge, then make sure that the lights I did have hit one side or the other (there were up to 6 or more hitting one huge tri). After that it was no more than 4 I think, and probably saw 5-10 fps increase.

 

It was a long time ago though.

 

So in certian circumstances IF you have a lot of lights and some very big brushes it can make a difference. But it worked much better by manually splitting that one brush than it did by using carve (which created tons of extra polys and they still had multiple lights hitting them).

 

Maunal gave me a few large tris each with say 4 lights hitting them. Carve gave me several hundred tris, each with 2-4 lights hitting them.

 

(Can't say what the 'final' released vers was like as I passed it off to Fid at some random point and never looked again, but I believe he got the more optimized vers)