Mesh LOD and Texture Resolution

TrainzDev

New member
LOD was first introduced into Trainz way back in TRS2004. Initially it was used only for locomotives, but ten years later it is recommended for every mesh based asset.

Since TS2009, Trainz has a texture LOD system - it will automatically use a lower mip level of a texture if the object is further away, and will avoid loading mip maps of higher resolution than necessary for a given scene to reduce the memory footprint.

However, some content creators have got into the habit of changing the texture file for each LOD level to a resized copy of the same texture at a lower resolution.

This is unnecessary, and can cause graphical problems. If a creator has copied the texture, resized it to a smaller resolution, and used the smaller copy on the lower LOD level, the LOD change will be more obvious. When the mesh is swapped, a new texture is required. Texture loading happens in the background, so a few frames will pass with only a low resolution copy of the texture available, before the high resolution version is available. The result is the LOD appears to swap down then back up again very quickly at each transition point.

It can also cause increased memory usage. If there is more than one copy of the object in the scene, it is likely that each of the different resolutions will be loaded at once - and Trainz will then be forced to use more texture memory than if the texture had not been changed. And if the LOD doesn't also adequately cut the polygon count, you might even have an object that is less efficient than if it had no LOD at all.

So when you are making a mesh, consider very carefully if you really need to change textures when the LOD levels change. Do not change the texture purely to reduce the resolution, as we do that for you already. Generally you should avoid changing the texture unless absolutely necessary - e.g. if you are moving significant amounts of detail from geometry into texture with that LOD change.

There is an exception to this rule, and that is objects which use alpha transparency. Trainz uses alpha-to-coverage to represent transparent objects. Alpha-to-coverage is fast, and doesn't exhibit the sorting issues that historic versions of Trainz were known for, but multiple alpha blended objects placed behind each other won't stack up to appear as solid as they would if done by the older, slower methods. To counteract this, Trainz generates mip maps of textures with alpha which tend towards being more opaque, so distant objects (e.g. old format trees) don't fade to translucent shadows at extreme range.

The catch here is that some objects do need to fade out in the distance to look realistic. The classic example would be a lightweight fence, e.g. a mesh or barbed wire fence.

A conventional approach with a high resolution texture results in this appearance:

before.jpg

Looks great close up, with lots of detail. But as you go into the distance, it gets overly heavy, taking on the appearance of a much more solid 3 bar fence. Eventually it becomes a single black stripe.

In real life, the wires should visually melt away, leaving just the posts clearly visible. To achieve this effect, we use a series of appropriately sized textures to maintain correct appearance over the visible range. Try to keep the texture size to around one texture pixel per screen pixel at the closest end of each LOD level's visibility. This will cause Trainz to use the full size of the texture rather than a lower mip level, and minimise the effect of the alpha becoming more opaque as further mip maps are used.

This copy has had the lower LOD textures resized down in a graphics editing tool to be closer to one pixel per pixel when the LOD is at it's largest. No other changes were made to the content.

after.jpg
 
LOD - Level of Detail
Mesh - this is what most assets contain in order to display in-game and created by a 3D modelling program like Gmax, 3DSMax, Blender or Sketchup

Shane
 
Regarding different textures at different LOD levels. The scenario is there is one texture, 5 LODs but 4 LODs use one bigger part of the texture while the farest LOD uses a different small part of the (same) texture?. Will that be less efficient than using the same part of the texture for each LOD level? I refer here to my tracks which use this technique.
The picture represents the mentioned texture, the green line shows the fragment which is used by the last LOD. The texture.txt file has the following inside:

(please click on the image to enlarge)

Code:
Primary=main_fa_01-main_fa_01.tga
Tile=none
Compression=DXT1
 
samplaire;bt3013 said:
Will that be less efficient than using the same part of the texture for each LOD level?

Generally speaking, yes. By using a small part of the texture, you're forcing the game to keep the high-detail version of the texture loaded.

chris
 
samplaire;bt3013 said:
Regarding different textures at different LOD levels. The scenario is there is one texture, 5 LODs but 4 LODs use one bigger part of the texture while the farest LOD uses a different small part of the (same) texture?. Will that be less efficient than using the same part of the texture for each LOD level?
WindWalkr;bt3014 said:
Generally speaking, yes. By using a small part of the texture, you're forcing the game to keep the high-detail version of the texture loaded.

What Chris says is correct. You don't have to worry about the alpha problem with this texture - it doesn't appear to have any alpha, so the mip generation favouring opaque models and thus adding a growing outline around things won't be a factor. (If you were using black/white opacity, you might find your current solution better for this reason). There are a couple of other considerations you might want to take into account, too:

How often do you encounter a scene where the higher resolution copies of the texture are not necessary? For a heavily used track, you will nearly always have the higher resolution copies loaded anyway for the close LODs, so while it would be technically better, there may be little apparent benefit. If the track is used only infrequently (e.g. for rusty sidings, or only in tunnels), then this case may become a lot more significant.

Can you use the liberated texture space for something else, particularly reducing the number of textures required? If you can, this could be very important. I don't think so though looking at the texture - there are other spaces available for this already, and you haven't mentioned having other textures.

Can you use the reduced texture area required to reduce the overall texture size required? I'm not sure if the reduction would be significant enough to make half the texture area removable - and that would be a big remap job too.

How much difference is there between the low resolution copy and the higher resolution copy? It's obviously a different length, but I'm not sure if I see any additional textured details. If you are achieving a lower polygon count in the final LOD that you couldn't achieve using the high-res copy, it may be worth keeping it separate to avoid a rise in your polygon count.
 
Last edited:
I would be grateful for some pointers on the following questions.

For the furthest LODs, is it worth swapping out textures for m.notex materials? For example, a building in the far distance might look ok with a very basic shape and just simple colours for the walls and roof, or is there a cost associated with the new materials?

I'm trying to develop large built up areas on my route at the moment, and becoming very concerned about performance and poly count. I'm wondering about the performance benefits/costs with using comprehensive mesh libraries with lots of asset meshes sharing a few high detail textures? For example, I would like to assemble a 'UK village buildings library', with five or six materials (a texture for the roofs, a few for walls/windows etc and perhaps another for boundaries such as fences/walls). Each asset would probably use one or two materials but would generally be seen with other assets using the same library- one house may have pantiles but another house of essentially the same design may have slates. Another house may have different walls but use the same roof tiles as another. I'm thinking that careful modelling could see a really wide range of buildings from a very few textures. My concern is whether there is an unacceptable cost if, for argument's sake, I use one building from the 'UK village buildings' library in a scene dominated by buildings from (say) a 'UK town buildings' library. Is the entire library loaded each time an asset appears, or is the game selective enough to only load the mesh and textures relevant to the asset being displayed?

R3
 
When loading meshes from another asset via the mesh-table, only the necessary meshes will be loaded. The real cost in this situation is the additional texture resolution required to implement multiple assets. Once that's "paid" (by actually including multiple assets into the scene) you get significant performance benefits in using this technique for low-to-medium-polygon objects.

chris
 
rumour3;bt3023 said:
For example, I would like to assemble a 'UK village buildings library', with five or six materials (a texture for the roofs, a few for walls/windows etc and perhaps another for boundaries such as fences/walls). Each asset would probably use one or two materials but would generally be seen with other assets using the same library- one house may have pantiles but another house of essentially the same design may have slates. Another house may have different walls but use the same roof tiles as another. I'm thinking that careful modelling could see a really wide range of buildings from a very few textures.

In addition to what Chris has already said, be careful that you don't increase the polygon count of the lowest LOD level for each house by having something like separate windows, which would ordinarily be textured on at the lowest level.
 
WindWalkr;bt3014 said:
Generally speaking, yes. By using a small part of the texture, you're forcing the game to keep the high-detail version of the texture loaded.

chris
So, since I use the same setup for my Laurel Line tracks having used Sam's as an example, would it be better to give the lowest LOD mesh a separate texture file instead of including it in the overall one?

Greets,

Jan
 
Back
Top