Using the new model exporter

[Springheel]

Given that the latest version of DR allows you to export models while keeping their smoothing (thanks greebo!), I was wondering about the performance implications.

 

My assumption is that if you have a shelf with five goblets on it, all static, all using the same texture, that it would be worthwhile to export them as a single .lwo model, since that would reduce the number of drawcalls by a factor of 5. I realize that the benefits would break down if the models were further apart, as the engine can cull individual goblets that the player can't see if they are separate, but in most cases where models are close together, it seems like it would be a benefit. Am I wrong?

 

It also seems like there wouldn't be much performance impact from exporting different types of models together, since the number of drawcalls is likely to stay the same. It would reduce entity count, but not performance?

[nbohr1more]

Yes, this should have performance benefits akin to converting brushes to func_static.

 

The downside, of course, is light carving. If a single light hits part of that merged model then all

it's polys are evaluated... even those goblets in the shadows outside the light bounding box.

 

In many cases it's a win and you'll have a lower entity count and less memory usage.

[peter_spy]

That might save a few DCs here and there, but it's not what eats up the majority of DCs per scene in current TDM assets. It's multiple materials per model and complicated multi-stage materials. That said, it would be awesome if the engine could use some kind of automatic mesh instancing, as other engines do.

[nbohr1more]

TDM \ Doom 3 does some backend instancing for models that are identical but it's not GPU instancing. Instead it's a sort of back-end batching as I recall.

(Similar to how our particle emitters batch all the particles models together.)

[Dragofer]

but it's not what eats up the majority of DCs per scene in current TDM assets. It's multiple materials per model

Multiple materials result in one DC each on an .ase model as well as mesh splits, producing duplicate verts which put a strain on our shadowcasting system, while it's been my understanding that .lwo models aren't subject to these drawbacks.

 

Then again it seems unlikely that a huge .lwo model with 30 different materials still only makes one drawcall, so there's probably more to this?

[peter_spy]

I don't think any models are immune to that. Multiple materials = mesh splits and clogging the CPU ->GPU pipeline, in any engine that's asking for a disaster. That, along with more complex materials (basically anything more complex than d/s/n image stages), makes the drawcalls and triangle count go higher, which is also multiplied by numer of lights hitting the model.

[Springheel]

The term "disaster" might be just a tad hyperbolic.

[peter_spy]

Worst Case

To have many small meshes is bad. If they’re using different material parameters on them, it gets even worse.

https://simonschreibt.de/gat/renderhell-book3/

 

 

• When possible, combine the nearby objects into a single object that has a single material. For example, if your level contains a table with dozens of objects on it, it makes sense to combine it in your 3D application (this might require combining textures into one big texture atlas as well). Reducing the number of objects that Unity needs to render can boost the performance dramatically.
• Do not have needless meshes. If you have a character in your game, it should probably be only 1 mesh. If you have a ship, it should probably only be one mesh. There is a significant overhead for each mesh Unity renders due to realities of hardware and drivers.
• One material per mesh. Each material that is rendered is treated like a separate mesh getting rendered.

https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html

 

 

The render thread needs to process each object (culling, material setup, lighting setup, collision, update cost, etc.). More complex materials result in a higher setup cost.

 

Mesh Draw Calls are displayed when using the stats commands show the draw calls caused by 3D meshes - this is the number artists can reduce by:

• Reducing object count (static/dynamic meshes, mesh particles)

• Reducing view distance (e.g. on the Scene Capture Actor or per object)

• Reducing Elements per draw calls (combine materials accepting more complex pixel shaders or simply have less materials, combine textures to fewer larger textures - only if that reduces material count, use LOD models with fewer elements)

https://docs.unrealengine.com/en-us/Engine/Performance/CPU

 

Using multiple materials per mesh is used often in offline rendering (archviz), because they need static images, and have tons of RAM, renderfarms etc., so they can afford that rendering cost. In games and realtime this is always carefully avoided, as much as possible.

 

And I can see the result of that in my work; that was the reason why I decided to make all models, textures, and materials myself. I can have much better graphic fidelity with unwrapped models using 1 material per mesh, than with stock TDM models. My scenes have several hundred drawcalls, while with stock assets they had several thousand.

Edited May 11, 2018 by Judith

[Springheel]

I wasn't arguing that more materials can increase drawcalls. There are lots of ways to do that, and lots of ways to reduce them when necessary. But referring to having higher drawcalls as a "disaster" is rather silly.

 

Losing your map in a HD crash is a disaster. Releasing your mission with a critical map-breaking bug might be considered a disaster. Having higher drawcalls than you want during the building process isn't even close.

[peter_spy]

Using multiple materials per mesh. TDM would have fewer performance problems if majority of models had used max 1-2 materials per model, and possibly the same set of textures (e.g. fully unwrapped models). Especially since the drawcall limit is so low in comparison to e.g. newer versions of OpenGL, or DirectX 11. Current TDM approach is common in architectural visualisations, but not in realtime.

Edited May 11, 2018 by Judith

[peter_spy]

Since Spring ninja-edited his post, my response makes less sense now.

 

But yeah, it's rather common knowledge that multiple materials decrease performance like hell in game engines. Maybe that knowledge wasn't available at the time TDM models were made? I can't know that. I've been keeping up with Unreal engines basically from the start, so at some point I came across that information. I don't think brushing it off like it was nothing is wise either.

[chedap]

 

Worst Case

To have many small meshes is bad. If they’re using different material parameters on them, it gets even worse.

 

I think it's easy to take this advice out of context. It's not the "worst case" to have an armchair split into wooden parts and leather parts. "Worst case" is something like this:

Each model with up to a dozen materials, and each character with up to a dozen of these models, and each scene with no occlusion/portal culling at all (do the math). It's an example from Morrowind, which, while less complex in terms of graphics than Doom 3 (single-stage materials, no shadows), was only a couple of years behind.

 

Now, it's true that having an idea of what to strive towards is useful. Art assets aren't a case of "make it work > make it right > make it fast", they'll usually be left in whatever state they were originally created, so it's better to make them good on the first try.

 

But there are other "best practices" to consider, such as leaving room for iteration through non-destructive workflow. If you can just mark objects for batching and uncheck the option any time you wish, that's one thing. But if you've combined contents of an entire shelf into one model and later need to remove or shift things around, you'd have to either fiddle with exporting to model again, open up 3D modeling software or rebuild all of the shelf's contents from scratch. Hardly an organic workflow.

 

The same applies to other things. Yes, having each mesh use a single material is good for performance, but having a set of meshes that share tileable materials is better for flexibility and vram footprint (download size as well), even more so in TDM, since same materials can be used not just for premade models, but for custom architecture as well. Naturally, it applies to modular architecture as well (which to be honest is the last thing I expected TDM mappers to get infatuated with, not that I want to start a drama about it).

 

 

Back on topic though, there's a not-quite-but-sort-of-a bug with the model exporter. By default it points to a folder, but without a filename. That will throw a "can't rename to .bak" error and create a dummy file named "_".

[Springheel]

I don't think brushing it off like it was nothing is wise either.

 

 

No one was arguing that it was. But there is lots of ground between, "brushing it off like it was nothing" and calling it "a disaster".

[peter_spy]

I think it's easy to take this advice out of context. It's not the "worst case" to have an armchair split into wooden parts and leather parts.

 

Definitely, although there's nothing wrong with simplifying that, if a difference is fairly redundant, e.g. if a chance that player hits a given part is quite low. Arrows sticking or not sticking into surface would be more important IMO, as it might have gameplay implications.

 

"Worst case" is something like this:

 

Now that is a disaster I don't think I have sufficient knowledge on that, but I guess such setup was ok before materials were introduced? Definitely would kill any engine now.

[peter_spy]

having a set of meshes that share tileable materials is better for flexibility and vram footprint (download size as well), even more so in TDM, since same materials can be used not just for premade models, but for custom architecture as well.

 

Sure, but that's trading off performance aspect you can't do much about (DC limit is something you can't mitigate much without rewriting portion of the engine) for things that visibly improve with hardware: texture memory is less and less a problem with 2-3 GB VRAM cards, people don't have problems with downloading 40 GB games from Steam, so they probably won't mind a 1 GB mission, etc.

 

As for the original question, it's nothing grundbreaking really, you could already do that with SEED and "watch brethren" option as well. You need to think of intended use of certain object or group of objects in your map. You can have one goblet as a model and group of goblets merged by SEED, or a separate model of several goblets scattered on the floor, etc. I guess the difference is in memory used for models, but that's not a huge issue in normal circumstances.

Edited May 11, 2018 by Judith

[Epifire]

On a note of combing models (before I knew about this whole option in newer DR versions) I was matching positions in Softimage, combining and exporting them. This was done for large building facades outside the map that were made of 15 or so LWO's with about three materials a piece. Before and after specification checks showed that combining meshes that were almost always in view at the same time, saved me about 500 drawcalls with all the fog, ambient or other lights I had hitting it. DCs wont kill an engine near as quickly as dynamic shadows but it's all good to keep in mind for clearing that performance overhead. All this just amounts to you being able to provide more dense details packed into a level that will not only run great for a good machine, but shouldn't kill a low end one either.

 

But Springheel to answer your first question in the OP my experience has been... If it all stays relatively within the player view screen at a given time and is on the same visleaf; I combine them. As nbohr1more pointed out, whatever lighting graces a portion that's in view, it'll calculate and consider the entire mesh. So if you've made a long railway like me, you'd wanna separate sections realistically between visleafs and the PVS to keep that in check. Otherwise yeah, it's a TDM mappers dream come true.