Jump to content
The Dark Mod Forums

Usefulness of Convert to func_static


peter_spy

Recommended Posts

While I was prototyping my main location for the demo, I encountered something that might be worth checking further, especially if you use a lot of brushes in your map.

 

I was using multiple brushes to approximate a model for my target location. It had a lot of DCs, so I thought I'll convert it to func_static, so every face isn't counted as a model (which is typically the case with BSP vs static meshes). I did the conversion and compiled the map. When I ran it again, stats actually showed a bit higher DC count, while tris and shadow tris went down a little bit. Tried deleting all the files (.map, .cm, .proc) – no effect. There might be something wrong on my end, so I encourage you to test this on your own.

 

But if this is normal, then it means Convert to func_static is much less useful than I thought. There's not much of a conversion going on here. I mean, you can still do it to add noshadows 1 option for shadow optimization, but that's basically it. That means making "models" in DarkRadiant should rather be discouraged, since the engine has pretty low drawcall limit.

  • Like 1
Link to comment
Share on other sites

That being said, here are a few benefits:

 

1 - World brushes cut into other world brushes, creating more tris. Turning a set of world brushes into func_static can reduce tri complexity.

 

2 - Many more spawnargs other than noshadows can be applied to func_statics (i.e. noclipmodel, hide/show, LOD, etc.).

 

3 - Func_statics can be manipulated by scripting (i.e. hide/show, teleporting, remove from game, etc.).

 

And benefits of using models created from func_statics:

 

1 - As for changing func_statics into models, it can be recommended for func_statics with angular faces, small faces, etc., due to DR's tendency to slightly alter brush definitions over time, which cause brush movement to be problematic for large maps that take months to build. This might not be as much of a problem as it was a few years back, but I've adopted the habit of converting to models for some func_statics.

 

2 - Repeating the same func_static in the same PVS (i.e. multiple windows of the same home-grown design) can be a case where you would consider converting the f_s to a model, then replacing the multiple f_s instances with model instances.

  • Like 1
Link to comment
Share on other sites

I was using multiple brushes to approximate a model for my target location. It had a lot of DCs, so I thought I'll convert it to func_static, so every face isn't counted as a model (which is typically the case with BSP vs static meshes). I did the conversion and compiled the map. When I ran it again, stats actually showed a bit higher DC count, while tris and shadow tris went down a little bit. Tried deleting all the files (.map, .cm, .proc) – no effect. There might be something wrong on my end, so I encourage you to test this on your own.

I would assume (having not looked at the code) that the engine is smart enough to batch multiple polygons with the same shader (and illuminated by the same light) into a single draw call. Even the atrociously badly-optimised DarkRadiant render does this, so for the D3 engine to submit each brush face as a separate render operation would be a major facepalm. I would therefore not expect conversion to func_static to make a significant difference to the drawcall count if the textures on the model faces remain the same.

 

But if this is normal, then it means Convert to func_static is much less useful than I thought. There's not much of a conversion going on here. I mean, you can still do it to add noshadows 1 option for shadow optimization, but that's basically it. That means making "models" in DarkRadiant should rather be discouraged, since the engine has pretty low drawcall limit.

I think grayman's answer pretty much covers the benefits of converting to func_static, which are as much to do with map organisation than render optimisation. One of the headline features of D3 engine (at the time) was the "single unified renderer" where both map geometry and models are rendered in exactly the same way, which is consistent with what you are seeing. You still get at least one draw call for each group of polygons with a particular texture, regardless of whether they are part of the base map or a func_static, but the func_static does allow you to set certain spawnargs like noshadows which can help with optimisation.

 

 

That means making "models" in DarkRadiant should rather be discouraged, since the engine has pretty low drawcall limit.

 

I would discourage making models in DarkRadiant for the simple reason that it is a very poor tool for modelling, and does not even offer the most basic features needed to make models look good, such as smooth shading. But with regard to rendering performance, I don't think it will make any difference whether you make the model with brushes and convert to func_static, or add a func_static pointing to an ASE or LWO model. As far as the engine and the GPU are concerned, they are all just groups of textured polygons.

  • Like 2
Link to comment
Share on other sites

Hmm, I did another test. I created several wood planks with brushes and one wood material, converted it into func_static, then made identical .ase model and imported it in DR. In that regard, results are basically the same.

 

It seems overall big difference in DCs between my models and TDM stock assets comes from the difference between how models were made. I make fully unwrapped models, typically with 3 textures (_D, _S, _N) and one relatively simple material (often just texture declarations). TDM assets often use multiple materials with more stages, so that's where the key difference seems to be.

Edited by Judith
Link to comment
Share on other sites

It seems overall big difference in DCs between my models and TDM stock assets comes from the difference between how models were made. I make fully unwrapped models, typically with 3 textures (_D, _S, _N) and one relatively simple material (often just texture declarations). TDM assets often use multiple materials with more stages, so that's where the key difference seems to be.

 

Right. Your three textures are actually inputs to a single shader, so only one draw call is required per light. Once you start adding extra material stages for things like frobbing, map-wide ambient light etc, the draw calls start ramping up.

 

If draw calls are the current performance bottleneck, and it is still the case that almost all TDM materials have extra stages, then perhaps the material-stage-based approach to things like ambient lighting and frobbing needs to be re-thought. With the fully OSS engine it ought to be possible to move some of this logic into the shaders themselves, improving both performance and the workload on material creators.

  • Like 3
Link to comment
Share on other sites

Exactly, if I stick to one simple material per mesh, the DC count stays low. It's either additional stages in material definition or multiple materials per mesh (e.g. when using multiple tiling textures) that seem bump the DC count pretty high. Drawcalls seem to be the bottleneck right now. I only have 2 machines (one decent i7 desktop and one older i5 laptop), but 3500 DCs seem to be the place from where FPS starts to drop on both systems. (I know it's unfair, but in comparison, a single DX11 thread is capable of 35 000 DCs on the same desktop.) Number of tris and shadow tris per scene seem to scale with hardware.

Link to comment
Share on other sites

I have to mention that shadow tris are the bottleneck for me, not drawcalls, so there is some variation depending on one's hardware.

  • Like 1
Link to comment
Share on other sites

It probably requires more tests. I can see huge difference in shadow tris tolerance for my machines. The most complicated shadow scene I had on my desktop was 230k shadow tris. My laptop handled around 130k shadow tris. Both are way above current recommended limit (80-100k)

Edited by Judith
Link to comment
Share on other sites

While this test is purely synthetic, it kind of shows how tris and shadow tris can scale with hardware. There are 9 copies of one mesh here, set of chamfered boxes, 27k tris each, with one light inside. Lights are slightly overlapping. There's also ambient_world here. As you can see, as long as everything else is low, tris and shadow count per scene can be huge. Also, this image was shot with FXAA enabled in nvidia drivers and downscaled from 1440p, it also uses postprocess effects.

 

obraz.png

Link to comment
Share on other sites

That's a nice idea for some dream sequence :)

 

I did some more tests, and while this probably won't hold for a full complex map, it might be some sort of indicator when it comes to complexity of a single scene.

 

First, I tried to push tris count and shadow count as much as I can, but separately. It looks like my machine can handle as much as 6 million tris or 500k shadow tris, before it drops below 60 fps. But these values alone don't mean much, as missions are more complicated than that. That's why I added things like fog, 7 AIs, patrol points, and a few skins for these boxes to account for bigger material complexity per scene. Even with thinking AIs I was able to reach almost 5 million tris and 400k shadows, as long as drawcalls were low. One of the factors was the number of AIs actively searching for me. With detection or combat the number of tris wasn't a problem, but with 4-5 AIs looking for me, the scene had to be around 3 million tris and 300k shadows to hold 60 fps. Drawcalls were around 600-700 at all times.

Link to comment
Share on other sites

i use it a lot, especially in complicated area's where the game basically hangs due to too many draw calls (really bad game lag, 1 frame per minute lag). In the source engine which is based off idtech, it says, make a room as draw simple as possible, convert complicated stuff to func_static. The engine then treats the func_static as a non_world brush, but still renders it as a world brush. This is in relation to vis_portals, as well as normal area, func_statics are the only thing you can stick through a vis_portals without it causing game lag, or converting the func_static to a model.

Link to comment
Share on other sites

One huge benefit of models: All the tris get rendered regardless of the mood of the game's "optimizer".

TDM seems to randomly drop "degenerate" tris of brushes and func statics - leading to missing tris all over the place. Degenerate tris in models render just fine...

It probably only affects non-experienced beginners like me, that never did any 3D modelling before though.

Link to comment
Share on other sites

Btw. if you have the console printing on, you'll see that "remove degenerated triangles" takes a lot of mission first loading time. That seems to be true for missions using a lot of brushes, but I saw these messages too when I kitbashed several .lwo models. I seems like idtech4 just likes all triangles to be positioned nicely and with as little clipping or z-fighting as possible.

Link to comment
Share on other sites

First, I tried to push tris count and shadow count as much as I can, but separately. It looks like my machine can handle as much as 6 million tris or 500k shadow tris, before it drops below 60 fps. But these values alone don't mean much, as missions are more complicated than that. That's why I added things like fog, 7 AIs, patrol points, and a few skins for these boxes to account for bigger material complexity per scene. Even with thinking AIs I was able to reach almost 5 million tris and 400k shadows, as long as drawcalls were low. One of the factors was the number of AIs actively searching for me. With detection or combat the number of tris wasn't a problem, but with 4-5 AIs looking for me, the scene had to be around 3 million tris and 300k shadows to hold 60 fps. Drawcalls were around 600-700 at all times.

 

I'm not sure conflating CPU-bound tasks such as AI searching with rendering tasks is particularly useful for performance profiling, because they are largely independent. It may give you an idea of how complex a particular mission can be on your own machine, but it won't necessarily give much insight into how the map will perform on other people's machines because there are so many variables.

 

In order to identify a performance bottleneck you really need to focus on one thing, i.e. a really complex render with no AI if you want to profile rendering, or a blank-textured box with 100 AI if you want to examine AI performance.

 

One huge benefit of models: All the tris get rendered regardless of the mood of the game's "optimizer".

TDM seems to randomly drop "degenerate" tris of brushes and func statics - leading to missing tris all over the place. Degenerate tris in models render just fine...

It probably only affects non-experienced beginners like me, that never did any 3D modelling before though.

 

If the engine is removing degenerate triangles it is doing that for a reason. My understanding is that degenerate triangles are either those with no area (all three points in a line), or facing the wrong way, which mean that they won't render correctly anyway. Bypassing optimisation as a "solution" for geometry issues is like enclosing your map in a big box so you don't have to worry about leaks. It's not a solution, it just hides the problem and most likely results in a slow-performing and buggy map.

  • Like 1
Link to comment
Share on other sites

I'm not sure conflating CPU-bound tasks such as AI searching with rendering tasks is particularly useful for performance profiling, because they are largely independent. It may give you an idea of how complex a particular mission can be on your own machine, but it won't necessarily give much insight into how the map will perform on other people's machines because there are so many variables.

 

Probably not, or only to the extent that operation of drawing triangles is part of CPU to GPU pipeline. In that regard I have to include CPU being busy with both drawing triangles and other tasks. Still, I'm not a programmer, so it's more guesswork than scientific results.

 

In order to identify a performance bottleneck you really need to focus on one thing, i.e. a really complex render with no AI if you want to profile rendering, or a blank-textured box with 100 AI if you want to examine AI performance.

 

I might do that AI test as well. Rendering tests apparently show huge capabilities and engine scalability, at least on Intel/Nvidia based systems like mine.

Link to comment
Share on other sites

Part of that is that skinning is done on the CPU so all animations that cause bone based mesh transforms are very expensive.

There is ongoing work to make TDM more like Doom 3 BFG so we can port code which allows skinning to be done on the GPU.

 

I think there is a cvar to skip animations which you could use to isolate the two factors.

 

Well. A starter would be g_stopTime but that would only give you what the AI meshes are costing in overall CPU\GPU usage.

To my knowledge it stops AI thinking too... :(

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

If you want to test the animations alone, you could use ambient AI--they play a single animation but don't think. I forget what the entity is off the top of my head, but I think there are some in the prefabs.

Link to comment
Share on other sites

If the engine is removing degenerate triangles it is doing that for a reason. My understanding is that degenerate triangles are either those with no area (all three points in a line), or facing the wrong way, which mean that they won't render correctly anyway. Bypassing optimisation as a "solution" for geometry issues is like enclosing your map in a big box so you don't have to worry about leaks. It's not a solution, it just hides the problem and most likely results in a slow-performing and buggy map.

Yes it does it for a reason. But no, the tris weren't "lines" nor where they back facing.

Degenerated triangles appear to be those in which the relationship between the radius of the inscribed circle and that of the circumscribed circle is smaller than N. N seems to be unknown.

I don't find the thread, where that has been discussed because the forum's search is crap (it does not find shit and discourages multiple tries - a seriously bad combination of "features").

The (for me) unpredictable behaviour of the engine is one reason, i mod for Factorio but not TDM.

Link to comment
Share on other sites

Well. A starter would be g_stopTime but that would only give you what the AI meshes are costing in overall CPU\GPU usage.

 

Yup. I ended up using 52 AIs, a small army of pagans and builders :) With time stopped the framerate was 60 FPS and DCs were around 2,5k. Animations or AI thinking (or both) brought framerate down to 19 FPS.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 0 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...