View Full Version : Mesh-table LOD - how do we cull attachments?

January 11th, 2016, 02:17 AM
Is there a way to cull attachments from an asset using mesh-table LOD?

Over the last couple of days I've been helping, or trying to help, another who is making a bridge (non spline) and is using mesh-table LOD. The asset has an attached track and is using a derivative of Andi's ProTrack. To help solve the problem I made my own simple bridge asset and recorded the performance (poly and draw counts) in Preview Asset. Rather than replicating everything here you can see the results in this post (http://forums.auran.com/trainz/showthread.php?126934-Undestnding-and-writing-a-LOD-entry-in-config-file-For-a-bridge-for-build-TANE-4-2-3&p=1476544#post1476544).

The poly counts shown in the three LOD images are well above the poly counts for my three meshes (6144, 1536 and 24) so they must be including the counts from the track.

It seems to me that the bridge asset could be more efficient if the lowest poly mesh included a painted track rather than the track itself. That would require a cull option.

January 11th, 2016, 03:57 AM
This isn't really feasible, for two reasons:

* Attached track doesn't actually attach in the sense that you seem to expect. It uses the attachment points to determine its position, but it doesn't become a child of the attachment point (when you think about it, this is obvious, because there are multiple attachment points involved) and therefore the visibility of the attachment point does not affect the track.

* mesh-table LOD doesn't have any concept of culling attachment points. Again, you need to keep in mind what's actually happening here: unlike an LM file where the mesh is actually swapping LODs, you are instead making one mesh disappear entirely and (maybe) a new mesh appear. The two meshes aren't actually tied to each other in any way other than in the creator's head. This means that anything which was truly parented to the first mesh would disappear, even if a same-named attachment point existed in the second mesh. This is basically never what you want, so we avoid this.


January 11th, 2016, 04:51 AM
Thanks. It took a few reads to follow but I think I got there in the end.