Level of Detail
m |
m |
||
(2 intermediate revisions by one user not shown) | |||
Line 7: | Line 7: | ||
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. | 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. | + | 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. This process is known as [[texture streaming]] and may be disabled in the game settings. |
=== Benefits === | === Benefits === | ||
* Higher GPU performance because the active texture maps are smaller. | * Higher GPU performance because the active texture maps are smaller. | ||
− | * Lower | + | * Or alternatively, higher graphical quality for equivalent performance. |
+ | * Lower VRAM usage. (Texture streaming only.) | ||
* Avoids moire effects on noisy textures. | * 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. | + | * 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. (Texture streaming only.) |
=== Disadvantages === | === Disadvantages === | ||
− | * Can blur texture details to some extent (mitigated by higher Anisotropy settings on the GPU | + | * Can blur texture details to some extent (mitigated by higher Anisotropy settings on the GPU). |
* 33% increased ram usage for a fully-loaded texture. | * 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. | + | * User can sometimes see objects up-close which have not yet loaded their high-detail textures. (Texture streaming only.) |
=== Gotchas === | === 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 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. | + | * 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 large 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 == | == LOD in Meshes == | ||
Line 41: | Line 42: | ||
=== LOD on Moving or Animated Objects === | === 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: | + | This technique mainly applies to [[KIND Traincar]] and [[KIND Bogey]] assets, however all types of [[animation|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 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 typically high-polygon. | ||
* They are often comprised of several components using [[Attachment Points]]. | * They are often comprised of several components using [[Attachment Points]]. | ||
− | * They typically have a higher performance cost | + | * They typically have a higher performance cost than 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. | 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. | + | This style of LOD explicitly supports animation and attachment points, including providing controls to hide attachments and disable animation in lower-detail variants. |
− | [[LM.txt file]]s are a drop-in replacement for the regular [[ | + | [[LM.txt file]]s are a drop-in replacement for the regular [[trainzmesh file]]s. In cases where this form of LOD is acceptable, you can simply replace the "xxx.trainzmesh" 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.trainzmesh" files. |
==== LOD on Attachments to Traincars==== | ==== LOD on Attachments to Traincars==== | ||
Line 57: | Line 58: | ||
Question: What LOD scheme should attachments to a traincar use? | Question: What LOD scheme should attachments to a traincar use? | ||
− | + | This is very situational. You can't currently benefit from mesh stitching if you're attached to a traincar, so a generalised recommendations would be: | |
* Avoid attachments for low-detail (sub-500-polygon) meshes which can simply be built into the parent mesh. | * Avoid attachments for low-detail (sub-500-polygon) meshes which can simply be built into the parent mesh. | ||
* Try to use the attachment-point culling facilities in LM to get rid of physically-small-but-detailed meshes as quickly as possible. | * Try to use the attachment-point culling facilities in LM to get rid of physically-small-but-detailed meshes as quickly as possible. | ||
− | * | + | * For T:ANE (4.1) all traincar meshes should be LM files. |
− | + | ||
− | For T:ANE (4.1) all traincar meshes should be LM files. | + | |
Line 95: | Line 94: | ||
*[[Modeling_Scenery]] - Guidance for creating scenery assets. | *[[Modeling_Scenery]] - Guidance for creating scenery assets. | ||
+ | |||
+ | *[[Advanced LOD Techniques]] - Suggestions for improving your use of LOD. | ||
Latest revision as of 13:24, 16 October 2017
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.
This tutorial gives a good step by step guide to making mesh-based LODs.
Contents |
[edit] 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. This process is known as texture streaming and may be disabled in the game settings.
[edit] Benefits
- Higher GPU performance because the active texture maps are smaller.
- Or alternatively, higher graphical quality for equivalent performance.
- Lower VRAM usage. (Texture streaming only.)
- 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. (Texture streaming only.)
[edit] 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. (Texture streaming only.)
[edit] 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 large 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.
[edit] 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.
[edit] 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.
[edit] 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 than 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 and disable animation in lower-detail variants.
LM.txt files are a drop-in replacement for the regular trainzmesh files. In cases where this form of LOD is acceptable, you can simply replace the "xxx.trainzmesh" 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.trainzmesh" files.
[edit] LOD on Attachments to Traincars
Question: What LOD scheme should attachments to a traincar use?
This is very situational. You can't currently benefit from mesh stitching if you're attached to a traincar, so a generalised recommendations would be:
- Avoid attachments for low-detail (sub-500-polygon) meshes which can simply be built into the parent mesh.
- Try to use the attachment-point culling facilities in LM to get rid of physically-small-but-detailed meshes as quickly as possible.
- For T:ANE (4.1) all traincar meshes should be LM files.
[edit] 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.)
[edit] Poly Counts for LOD Levels
(This is a work in progress and will be updated when additional information is available)
Poly counts for the lowest LOD mesh should be minimal consistent with the size of the mesh on screen. Warnings such as the following may be issued for meshes with inappropriate poly counts.
- Warning: The low-detail meshes total more than 500 polygons. This may have a negative impact on performance.
[edit] Related WiKi pages, Developer Blog Articles and Useful Trainz Forum Threads
[edit] WiKi Pages
- Modeling_Guidelines - Provides a framework for considering performance when creating new models.
- HowTo/Make_your_first_Trainz_Asset - A step by step tutorial that will teach you how to create a 3D model, create the Level of Detail (lower resolution) versions of the model, and import it into Trainz.
- HowTo/Understand Level of Detail in Trainz - Sets out to explain in layman's terms why Level of Detail (LOD) is the most important tool a content creator has in order to make their assets both look good and perform well in-game.
- Mesh_stitching - All about mesh stitching.
- Modeling_Scenery - Guidance for creating scenery assets.
- Advanced LOD Techniques - Suggestions for improving your use of LOD.
[edit] Trainz Developer Blog Articles
[edit] Trainz Forum Threads of Interest
Note that information in threads maybe be superseded by blog articles and specialist WiKi pages.