Level of Detail

Revision as of 21:28, 10 July 2013

Level of Detail (LOD) refers to a technique where several variants of an object are created, ranging from "high quality and high performance cost" through to "low quality and low performance cost". Each variant should look as close to possible as identical with the exception that overall object quality is lost as you go down the scale. These variants are then packaged together as a single asset with instructions to the game engine to use the most appropriate variant based on how far the object is zoomed out on the screen. When the player is close to the object, the "high detail LOD" variant will be displayed, showing the object in its full glory. As the player moves away from the object, the game can swap from the detailed version to the lower-detail-but-faster-to-render variant since the player is too far away to see the details anyway.

TBD: Image of several LOD meshes seen from close up, then the same meshes shown at the appropriate LOD ranges.

LOD in Textures

All textures are subject to LOD, and the process is simple and automatic. Each texture already has a number of Mip Maps which are automatically generated by Content Manager. The highest map is used whenever one texel represents one or more pixels on the screen. Once the object is far enough away that one pixel represents two texels, a half-size map is used, and so on. This is handled transparently by the GPU with no action required on the part of the content creator.

In cases where no visible object is currently using the higher mip level(s), they may be fully unloaded to conserve RAM. When an object again nears the player, the higher mip levels will be reloaded.

Benefits

• Higher GPU performance because the active texture maps are smaller.
• Lower RAM usage.
• Avoids moire effects on noisy textures.
• Don't have to load the full-detail version of all textures immediately, but can bring them level-by-level as the player approaches an object.

Disadvantages

• Can blur texture details to some extent (mitigated by higher Anisotropy settings on the GPU.)
• 33% increased ram usage for a fully-loaded texture.
• User can sometimes see objects up-close which have not yet loaded their high-detail textures.

Gotchas

• Since a single copy of the texture is shared between all relevant objects in the scene, having a single object at close range prevents unloading the higher texture mips, even if all other objects are distant. The GPU will still render using the appropriate mip levels, but the game will be forced to keep the high-detail mips loaded in this case.
• Since the selection of texture LOD depends on the texel-to-pixel ratio on display, it is possible for a single mesh to use different mip levels simultaneously. To some extent, this is deliberate- distant parts of the mesh may be at lower detail than closer parts of the mesh- but it's also possible for a content creator to worsen this effect by scaling the texture differently on different parts of the mesh. For example, if a 2048x2048 texture is stretched over the entirety of a distant object, then typically the game could select a 256x256 or lower version of the map for rendering. However, if the object also includes a black band around its circumference that is mapped from a single texel of that 2048x2048 texture, then you suddenly have a case where that one texel is mapped to a large number of pixels, requiring the texture to be loaded at highest detail. The game applies some logic to attempt to mitigate such cases, but the content creator should avoid such significant variations in mapping scale where possible. This problem can also occur as the result of reusing portions of the same texture at different scales for different LODs- it is often an automatic response to think that a small portion of a large texture can be set aside for the LOD meshes, however in doing so you are forcing the texture to be kept at full detail rather than degrade naturally.

LOD in Meshes

Mesh-based LOD is a more hands-on technique, and is what is usually referred to by the unqualified term "Level of Detail" since texture LOD is mostly automatic. There are several mesh LOD schemes currently employed in Trainz depending on the type of asset being used. All methods boil down to selecting one quality variant from a small list provided by the content creator. The creator will typically build the highest-detail mesh first- still ensuring the number of polygons is not overkill for the object being created- then create successively smaller mesh variants, each one typically dropping to 20-50% of the polygon count of the previous variant.

When creating LOD variants, there are a few things to keep in mind:

• The content creator's aim is to ensure that each LOD variant looks like the immediately higher variant. They should ideally also look like the highest-level variant, but it's inevitable that some detail will be lost and it's more important to minimise each transition than to minimise the overall appearance change.
• The human eye will pick up on silhouette and shading changes much more than changes to the internal detail of the object. Try to avoid changing the silhouette more than necessary.
• If you take a flattish object made by many small polygons which are nearly but not quite in a plane, and replace that with a single plane, the angle of light from your object will change. This will often result in the variant darkening or lightening as compared to its higher-quality sibling. The normal map can be used to neutralise this effect by ensuring that the lower-detail variants still maintain the appropriate surface normals, even though the geometry lacks the appropriate polygons.

A simple LOD mesh example is illustrated here with and without a normal map.

Spline LOD

Spline-based assets (track, hedges, fences, power lines, etc.) use a specialised form of LOD selection which works by subdividing the spline stretch (the space between two user-editable spline vertices) into a number of repeats which are then further subdivided as necessary. This process is controlled by the asset's "track-lod-tree" container, which accounts for numerous input variables such as the distance from the observer, the curve angle of the spline, season, random variation, and so on.

The component meshes are sourced from the asset's "mesh-table" container, but the selection technique does not use the "lod-level" or "mesh-season" tags.

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.

LOD on Static Scenery Objects

LOD on static scenery objects is by far the simplest technique and has the lowest performance cost. The asset's "mesh-table" container is populated with all the necessary mesh variants, each configured to display correctly (such that they would normally all appear simultaneously and interpenetrate.) A small number of extra tags are then added to the asset's config.txt file to control the mesh visibility for LOD purposes:

• The "mesh-detail-level-count" tag is added to the asset's config.txt file to specify how many LOD variants should exist.
• The "lod-level" tag is added to each variant's "mesh-table" container entry. This ensures that the variant mesh will only be displayed when the object is at the specified LOD level.

Note that this approach deliberately does not provide any mechanism for controlling the distances at which various LOD levels are selected. The content creator should also avoid measuring the distances at which the changes occur in the game. This is because the LOD selection is not defined in terms of fixed distances, but rather varies depending on the version of the game in use, user detail settings, game performance, and so on. Instead, the content creator should set the game to high detail settings, create the high LOD at a reasonable quality bar, and then attempt to reduce the detail as much as possible over the course of 2-4 LODs. The lowest LOD should be in the 5-100 polygon range (lower is obviously better.)

Categories