As the TrainzWiki says:
LOD on Moving or Animated Objects
This technique mainly applies to KIND Traincar and KIND Bogey assets, however all types of animated or regularly moving objects have a few things in common:
They are not good candidates for mesh stitching. If Trainz is aware that an asset instance will be moving or animated, it will render directly rather than attempting to stitch the meshes.
- They are typically high-polygon.
- They are often comprised of several components using Attachment Points.
- They typically have a higher performance cost that the base mesh would imply (additional animation costs, attachment costs, scripting costs, physics costs, etc.)
For these types of asset, the LM.txt file style of LOD should be used. This style of LOD outright prevents the mesh stitching optimisation and is also more expensive to load and maintain than other styles of LOD, thus it should only be used in the conditions described above. Regular scenery meshes should never use this technique.
This style of LOD explicitly supports animation and attachment points, including providing controls to hide attachments in lower-detail variants.
LM.txt files are a drop-in replacement for the regular IM files. In cases where this form of LOD is acceptable, you can simply substitute the "xxx.im" reference in the asset's config.txt file for an "xxx.lm" reference (note that there is no trailing ".txt" in a resource reference.) On disk, you will include a single "xxx.lm.txt" file which will then reference multiple "xxx-n.im" files.
This below is mainly directed at animated scenery items or scenery items which could take advantage of an animation when these are not often used in game in the same scene on the screen, which a creator could animate to use a LM text file for a better text distance referenced change of LODs by the creator. Meaning, say, if you create a moving animated crane, moving animated forklift or something like the build in animated saw mill, airport, oilfield etc., one can use a LM text file to nominate and control the distance (actually it is the screen percentage of the asset being seen in the PoV on your screen) where a LOD transition should occur. So, if a creator is
"sneaky" and wants to take advantage of "animated assets" like animated scenery assets indeed can (see above), all a creator has to do is to place a small animation on his/her animated creation to be able to use a LM text file for a better visual way of a LOD change in game. I said
"sneaky" and mean, to be used only minimally so for certain assets in Trainz, not by suddenly having an animation on every scenery items one creates, just to be able to use a LM text file for LODs on it.
I probably get shot down for even daring to suggest the above, as N3V's James Moody did to me in the past when I suggested something similar in the forum. But bear with me, some scenery objects need animation to look good in game, as they move around and do their animated routine and as logic dictates, these are special items in game beside looking good too. Meaning, say you create an animated saw mill, you probably only use such in game in one scene only, which one can see on the screen at a given time. So this would be probably only one, two or possibly three or so of such different animated scenery objects visually being seen on screen at a given time.
Say, as example, an animated railway station, which will only be seen every 10 km or so, where these are normally placed on a given track, animated round houses/turn tables, animated airports, animated oilfields and animated factories and so on. Which will visually enrich Trainz tremendously. Which are also only placed few and far between on one's route but not willy nilly everywhere. A user building his/her route in Trainz surely would not place too many of such animated objects into the same scene visible on screen. If such user does indeed place many of such animated objects close to each other to be seen on a single screen, well, said user will very soon find out this is no good by having stuttering or even stopping of the game and if smart and savvy, will reduce such animated items to be seen at the same time in that scene for getting a better performance of Trainz.
By having locomotives, bogies and rolling stock also in the same scene/screen, this would be normal and nothing one can do about that. Yet, as said, having the odd 2-3 or so other animated scenery objects there too, should IMHO not introduce such a huge strain on performance, to bring Trainz to its knees. Unless the coders of TANE don't know how to fix and eliminate other performance robbing issues in the code, instead on clamping down so hard on these poor little few animated scenery objects in a given scene on the screen.
Shees... other games have many animated cars, tanks, army vehicles, animated people, animated animals, animated scenery objects, flowing animated rivers and animated waterfalls, animated birds flying about, animated crumbling buildings, animated crumbling tanks when hit, vehicles, ground with big holes in it when hit etc., lighting bolts, arrows, other missiles shooting and flying all over the place in fights in certain games, all at the same time with all or most of the afore mentioned animations working and to be seen in it too. Some of these games are already a few years old and these games DO NOT have any serious performance issues to run these games and show all these mentioned animations very nicely.
One might ask the question, WHY is TANE or any other Trainz version so different to other games? Is it perhaps not having good and smart programmers doing the coding for Tane and Trainz? I am not saying that this is so BUT one is still wondering why these stark differences in viewing pleasure are between Trainz and other games. Again, why this is so DIFFERENT with Trainz/TANE when compared to some or even many other games?
As a side note, I wonder if one could get an AURAN/N3V created buildin airfield or any such other heavy animated buildin scenery item with lots of attachment points attaching many different meshes for that scenery item into TANE, how may errors and warnings would that item suddenly show in TANE and possibly not getting commited. Like too many polygons/triangles, having to use LODs on the attached meshes and so on, we mere mortal creators are seeing when trying to get a reasonable scenery item with attachment points attached meshes into TANE's CM, Yet, that same AURAN/N3V buildin item is oblivious to all errors and warning we creators would get if creating the same object and hence can merrily function error free and thus be seen in TANE. As this is surpressed in their code to show errors.
Is it again, one rule for them and another, a much stricter rule for us content creators?
My observations only.
VinnyBarb
Even I think it is about time.