View Full Version : Mesh libraries/shared components in rolling stock

December 1st, 2015, 02:06 PM
I've been asked the question whether it is good practice to create traincar assets using attached meshes from a mesh library for common components such as axleboxes or buffers, or whether it is better to create unique instances of these components within each traincar model, with consequent duplication of textures etc. One school of thought says that if you have 30 different wagons, but with identical axleboxes and buffers, it's better to source the axleboxes and buffers from a mesh library sharing one texture. The other says that attached meshes are inherently less efficient than a single mesh and texture, even though the same texture may be duplicated 30 times in a consist. Is there a definitive answer? If not, what are the circumstances where one approach should be preferred over the other?


December 2nd, 2015, 12:57 AM
Historically, it's better to build them as a single mesh unless you're talking about multiple thousands of polygons per object (in which case, the cost of the attachments is fairly small compared to the per-object cost, but be careful about LOD here- you'll probably want to drop back to welded geometry in your LODs.)

T:ANE SP1 adds some significant improvements to instancing, which can mean that the cost of an attachment becomes quite a lot less if re-used heavily throughout a scene. This is dependant on hardware to some degree, and is also very dependant on what exactly is in the scene: If you have 100 instances, you could get a nice win here. If you have 100 sets of 1 instance each, you're paying all the costs of the attachments with none of the wins of instancing, so you could lose out pretty badly. If you use any kind of effects such as animation or texture replacement, you may not benefit as much or at all from instancing.

I'd also add that unless you're saving a substantial portion of your vertices or textures by doing this, that the potential gains won't be worth risking the potential costs. If you're talking about something that's below 5% of your overall model, then you're really not gaining much by "optimising" it in this way- and if it turns out that you're doing something that hurts performance, you could end up making performance a lot worse. Obviously if you're talking 20%+ of the model then it's worth asking this kind of question and running some actual tests.

In short: if you think you have a good idea for improving performance, try out both ways and test the results. Keep in mind that performance is hardware-dependant and situation-dependant, so you'll often be reducing performance in one scenario to get a win in a different area. Focus on what the common use case is likely to be, but keep things in balance so that if you guessed wrong, performance still remains acceptable. If you don't notice a lot of difference in performance between the two options, go for whichever is the simplest construction since that's less likely to have unexpected interactions (ie. prefer one mesh with extra polygons over ten meshes with less polygons.)