[ErickC]

Please bear with me, I've forgotten a lot in the last few years.

I'm trying to remember, was the 64 part limit an MSTS limitation, or an export module limitation? If it's an export limitation, does collapsing nodes (should I consider this a manual form of drawcall batching?) have an effect at all?

[Genma Saotome]

Named sub-objects in your model always result in additional draw calls which degrade performance in all games that are CPU intensive -- both MSTS and Open Rails for instance. If you've got any named sub-objects that are optional (e.g., they're helping you get things clear while you work) you should explode/collapse them before you do your final export.

There is one situation where the draw call matter can be a wash WRT the rest of the model and that's when the sub-object is using a texture that is not applied anywhere else. IOW, that texture is 1 drawcall by itself, Applying it only on a named sub-object essentially means the sub-object goes along for the ride and doesn't cost you another draw call.

[ErickC]

Interesting. I was never in the habit of collapsing parts into the parent node in the LOD manager (let's face it, I could barely be bothered to sort alpha parts), but I was under the impression that it merged the collapsed node into the parent part at shape export.

[Genma Saotome]

It might.

We have so many different tools its hard to know what each one does.

The only tool I know of that reveals the truth of the matter is Shapeviewer. If you look at the hierarchy window you'll see the exported structure: Yellow boxes are draw calls for textures. Brown boxes are drawcalls for sub-objects. You can verify what your tool does with that.

[wacampbell]

Its difficult to generalize on this issue.

First off, the 64 part limit is imposed by MSTS. It will crash if the hierarchy statement in the .s file has more than 'about' 64 entries. I think there is an array that overflows in the program. I don't think Open Rails has the same limit.

And its very dependent on your CAD tool's exporter.

I believe the designer of the .s file format intended the hierarchy to be only for animated objects, but unfortunately some of the CAD tool exporters take the short cut of using a hierarchy level for each object in the source file.

I don't know all the CAD programs, but the Blender exporter, which I wrote, aggressively collapses the hierarchy on export. It understands what levels of the hierarchy are essential to retain - mainly animated elements - and all the rest are collapsed. You might actually have a 1000 objects in your blender model, with multiple textures, but they could all collapse to a single level of hierarchy on export.

As Dave suggests, the ShapeViewer report is the best way to judge what's happening.