Jump to content


Photo

Usefulness of Convert to func_static

func_static vs worldspawn

20 replies to this topic

#1 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 13 February 2018 - 09:12 AM

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.


  • Anderson likes this

#2 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12679 posts

Posted 13 February 2018 - 09:30 AM

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.


  • Anderson likes this

#3 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7501 posts

Posted 13 February 2018 - 09:48 AM

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.


  • Judith and Anderson like this

#4 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 13 February 2018 - 10:56 AM

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, 13 February 2018 - 11:02 AM.


#5 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7501 posts

Posted 13 February 2018 - 11:33 AM

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.


  • rich_is_bored, Judith and HMart like this

#6 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 13 February 2018 - 12:23 PM

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.



#7 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37376 posts

Posted 13 February 2018 - 12:25 PM

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


  • Judith likes this
TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#8 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 13 February 2018 - 12:37 PM

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, 13 February 2018 - 12:37 PM.


#9 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 13 February 2018 - 01:42 PM

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



#10 teh_saccade

teh_saccade

    Advanced Member

  • Member
  • PipPipPip
  • 630 posts

Posted 13 February 2018 - 03:34 PM

pretty... make them all subtle movers, so it breathes, and that'd be an excellent room for a mystic artifact on a plinth at the end - send it all crashing down as the objective is achieved and the spell is broken... back to reality.


  • Judith likes this

#11 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 13 February 2018 - 05:21 PM

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.



#12 stumpy

stumpy

    Advanced Member

  • Member
  • PipPipPip
  • 1845 posts

Posted 13 February 2018 - 07:11 PM

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.



#13 Abusimplea

Abusimplea

    Member

  • Member
  • PipPip
  • 468 posts

Posted 13 February 2018 - 10:48 PM

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.



#14 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 14 February 2018 - 04:56 AM

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.



#15 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7501 posts

Posted 14 February 2018 - 05:34 AM

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.


  • Judith likes this

#16 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 14 February 2018 - 05:46 AM

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.



#17 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 14 February 2018 - 10:14 AM

Huh, I only got to 20 AIs in a blank box, and the framerate is already down to 35 FPS. It gets back to 60 PFS when there are 15-16 AIs walking around. No crowdy places then ;)



#18 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8985 posts

Posted 14 February 2018 - 10:27 AM

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... :(


  • Judith likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#19 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37376 posts

Posted 14 February 2018 - 12:16 PM

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.


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#20 Abusimplea

Abusimplea

    Member

  • Member
  • PipPip
  • 468 posts

Posted 14 February 2018 - 03:56 PM

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.



#21 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1585 posts

Posted 14 February 2018 - 04:19 PM

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.





Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users