Performance (Custom Meshes vs Func_Statics)

[kingsal]

Hey All,

 

I wanted to get some people's thoughts on the pros and cons of converting a bunch of DR func_statics to mesh objects. The obviously benefit of mesh objects is that you can easily change/ place them without dmaping. The downside is.. well its a lot of work build them (especially in the case of architecture where their best made to be modular) .

 

Meshes:

What is the performance impact of creating custom mesh objects vs func_statics in DR.

My assumption is that func_statics impact your dmap times whereas custom meshes impact your loading times? Does the engine treat a mesh object and a func_static any differently?

 

Textures:

Is the engine faster at loading lots of small textures or a few large ones (assuming both are used on multiple meshes)?

 

Thanks in advance

 

 

[nbohr1more]

Func_statics get turned into meshes on map load so they are largely equivalent in the engine.

 

That said, if you re-use meshes the engine only loads the original and uses a pointer to keep track of the others (saves on RAM and processing).

 

For both func_static and meshes, these do not split at portals or split geometry at the light boundaries so watch out for light counts and just know

that if a light radius poly touches a single mesh poly, the whole mesh is evaluated for that light.

 

Fewer large textures or "texture atlas" is more optimal but the image_downsize configurations for lowend players will murder image quality if you do it that way.

So it might be best to use a hybrid strategy. Detailed textures being tiny and individual, whereas large low frequency textures all atlas-ed together.

 

Oh, the biggest problem are shadow tris, so the downside of light counts can be offset a great deal with the use of low-poly shadow meshes.

They will still have the same problem of not splitting but the lower poly counts will mean that the CPU effort will be greatly reduced.

[nbohr1more]

Hmm.

 

I guess if you made an optimal texture atlas that wouldn't kill the video ram of lowend players you could add the nopicmip stage keyword

to the stages to prevent downsizing. You'd want to test that with a bunch of lowend users first to prevent a bunch of malloc error reports.

[kingsal]

This is all great info nobohr1. I might post more questions here as they come up. Thanks so much!

[Obsttorte]

Func_statics get split up the same way worldspawn does in regardence to how the tris are generated from the single planes. Hence they tend to have more tris in comparision to the same model exported as mesh. Additionaly, if you create a func_static and copy it, it will use it's own model, whereas using meshes means that all objects are referring to the same model. This doesn not only reduce loading times and performance impacts, but also the size of the cm file.

 

There is actually no advantage of using a func_static over a mesh. The latter is always better. At least I do not know of any advantage a fs might have.

[NeonsStyle]

What about brushwork? If you increase the brush detail of a room significantly than normal how much would that impact performance? Is it linear? I have something in mind that

would be a large increase in brushes in a room, but I'm concerned on performance for it too. Better to know these things before starting.

[nbohr1more]

Brushes are more expensive that func_static or models in many cases. They always generate collision unless you use custom materials with the "nonsolid" keyword

and they are heuristically split into more triangles to attempt to keep light counts low and ensure that they obey BSP visibility branching.

 

Brushes do sometimes win in scenarios where larger light counts are involved because models and FS will render the whole thing for each light that hits them

but in most cases models and FS have better performance attributes.

 

Brushes are mostly intended for prototyping, simple walls, and collision\pathing design as I can tell.

 

Most of the level detail in Doom 3 was models with minimal brushwork.

 

We've recently been evangelizing a modular workflow which involves re-using generic room model or

building model components to build out levels Lego-style then add detail patches and caulk with brushes.

Of course that requires building a model (module) library which is currently WIP but Sotha has already shown the benefits of the technique in his recent missions.

[Moonbo]

Much more important than the number of brushes or models in a scene is the number of lights and if they are shadow casting or overlapping. I had instances where, based on the lighting layout, brushwork was actually cheaper than func statics because I could carve up the brushes so that multiple lights didn't hit them vs. if they had been a single FS.

[kingsal]

I poked around the Doom 3 maps a bit they're incredibly well done and I would encourage everyone to do it. As nbohr mentioned, the brush work is simply used for laying out the design and guts of the level. Most of the visual fidelity comes from modular static meshes and smartly placed lighting. This is definitely challenging in a handcrafted medieval setting.

 

Another performance note:

This feels like a huge oversight on my part. I recently realized that shadow casting light volumes will overdraw past world brushes (even when separated by portals). This is a huge killer on performance. So for instance, if your light volumes on the first floor collide with objects on the second floor. It will still calculate the shadows of anything the light touches, even though they are not visually rendered. I think the general principle is to keep your shadow casting lights small and use ambient lights to "fill" the room. This of course, will be tough if you have lots of strangely shaped medieval rooms which doom does not .

 

I can't be certain, but are the long load times for FMs in part due to the use of func_statics over meshes? It could also be the texture count.

[nbohr1more]

Mipmap generation for normal maps is the biggest culprit there.

If haven't already done so, set the normal map compression cvar to 0. Leaving it at 2 does nothing since none of our normal textures are compressed and the decode logic for compressed normals is already disable in anticipation for a better option. Users are wasting time waiting while the engine encodes textures in RAM that it never uses.

Reused meshes will help loading time though.

[kingsal]

Here is an example:

Unless I am totally wrong about this, I believe the torch light's volume is still generating the shadows of the barrels in the room next door even though they are separated by a wall. Am I understanding this correctly?

[nbohr1more]

I believe you are correct.

 

Use r_showShadows in the console to see what is being generated where.

[Bikerdude]

This feels like a huge oversight on my part. I recently realized that shadow casting light volumes will overdraw past world brushes (even when separated by portals). This is a huge killer on performance. So for instance, if your light volumes on the first floor collide with objects on the second floor. It will still calculate the shadows of anything the light touches, even though they are not visually rendered. I think the general principle is to keep your shadow casting lights small and use ambient lights to "fill" the room.

Thats interesting to know.

 

When I have worked on my own maps, or when asked to do a perfing run on other peoples maps I have always had to reduce thier light volumes which were just big. This was mostly due to wanting to prevent over lapping light volumes, but now I see that I have inadvertently been reducing the issue you spoke about also. I also think I was the first person (some one will correct me if I am wrong) that used bounce lights to fill a room or a section of a room.

[Destined]

This feels like a huge oversight on my part. I recently realized that shadow casting light volumes will overdraw past world brushes (even when separated by portals). This is a huge killer on performance. So for instance, if your light volumes on the first floor collide with objects on the second floor. It will still calculate the shadows of anything the light touches, even though they are not visually rendered. I think the general principle is to keep your shadow casting lights small and use ambient lights to "fill" the room.

 

This is really good to know. Maybe it should be mentioned in the tutorial in the Wiki, so new mappers will know of this issue as soon as they start mapping.

[Obsttorte]

Here is an example:

Unless I am totally wrong about this, I believe the torch light's volume is still generating the shadows of the barrels in the room next door even though they are separated by a wall. Am I understanding this correctly?

volta_v2_0_2016-08-31_11.34.40.jpg

 

 

That's true. It can happen that a light causes an object to draw a shadow into the visible are, even though the model and/or the light is not rendered. However, the shadow has to be visible so there is a need for the shadow generation. Otherwise the engine can't decide whether a shadow has to be rendered or not.

[kingsal]

I would definitely suggest people at least be aware of it. The shadow over-draw was adding 300-400 drawcalls to my current level until I finally figured out what was happening.

 

As biker mentioned, reducing light volumes solves many of these nasty issues. However, a lot of the default tdm lights such as torches spawn lights with fairly large volumes. So that's something to be careful of.

 

Another consideration would be to design levels with this problem in mind, lots of open space between rooms to avoid light overlap. I keep getting myself into this rabbit hole.. lots of tightly packed rooms with shared walls.. ugh. Its a nightmare to light.

 

 

Biker- I do remember you using bounced lighting in your maps. Its such a nice effect...

Edited September 1, 2016 by kingsal

[Obsttorte]

However, a lot of the default tdm lights such as torches spawn lights with fairly large volumes. So that's something to be careful of.

Yeah, back in the day I always reduced them from 320^3 down to 192^3. You can use the set <spawnarg> on <attachmentName> spawnarg to alter spawnargs on attached entities.

[NeonsStyle]

Fascinating. So much to learn here. I had no idea about D3 map setup. I've looked at them in an editor, but never from a performance point of view.

 

Given this issue with lights impacting adjacent rooms. Currently, if you adjust the size of a light, it adjusts all sides, would it be possible to make it so

you could set the size of each side uniquely?

[Destined]

Currently, if you adjust the size of a light, it adjusts all sides, would it be possible to make it so

you could set the size of each side uniquely?

 

That is a very good point. This would make things much easier (regarding performance). However, I could imagine, that the light might not look realistic anymore.

[Obsttorte]

You can offset the light origin to achieve this. I think the spawnarg is light_origin, which takes the light position relative to the light entities origin. However, it may not look good due to the light texture used (so you would have to adjust this, too, to get the best results).

 

The easiest ways to avoid too high performance impact of lights are to

• avoid overlapping lights
• avoid several lights hitting the same tris (r_showTris will show you the tris), split surfaces up where neccessary
• avoid too much shadow casting entities within light bounds
• only use shadowcasting lights where really neccessary, ambient lights are your friends
• avoid entites casting shadows into adjacenting rooms if possible

There are a few more things which can help with performance, though

• split up your level geometry in a way so that visportals can do their job properly, this means that you should avoid that the player can see into zones of which he can only see a tiny bit
• take the vertical aspect into account when creating outdoor areas (many mappers oversee this, as we tend to think two dimensional)
• plan visportal placement in probably performance houngry areas before you build the area, placing vp's afterwards will not always be of much help
• make use of the lod system
• if you use a func_static very often (for example a custom decoration, window frame or whatever), export it as a model and use this instead
• turn all decorative elements into func_statics, if they are rather small, make them non-solid and non-shadow casting
• generally models have less tris then func_statics, so if you have performance drops in areas with fs check the tris (r_showTris) and export them as model if the tris count is high
• only put details in areas where the player can see it, in dark spots for example the player might not notice the difference if details are lacking
• avoid the use of too much textures

These are a few things to consider, but I guess there are more ways to improve performance. Note that if you are going to do an performance houngry mission, like something that plays outdoors, you have to make performance considerations before you start building the level. This makes things much easier for you and everyone else as if you have to fix the performance afterwards.

[nbohr1more]

Yes, it's called light_center. The only problem being that the particle flames are attached to the origin rather than the light center. You can use an offset arg to adjust that though or make a custom light def where the attach point is the light_center as I recall.

[Spooks]

You can offset the light origin to achieve this. I think the spawnarg is light_origin, which takes the light position relative to the light entities origin. However, it may not look good due to the light texture used (so you would have to adjust this, too, to get the best results).

 

This is an important thing to remember. All lights are basically static textures and changing the light center of a big_round light for example will not change how the light looks - just where the bumpmapping, shadows and fresnel highlight are coming from. If you want a light to be snug against a corner and taper off into the center of a room you would need to create a custom texture for it.