Level of Detail - Revision history

Darkrose289: /* LOD in Textures */ Added wikipedia links to mipmap, texel, texture streaming, and anisotropy

2025-12-28T18:17:09Z

LOD in Textures: Added wikipedia links to mipmap, texel, texture streaming, and anisotropy

← Older revision		Revision as of 18:17, 28 December 2025
Line 5:		Line 5:
	== LOD in Textures ==		== 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.		All textures are subject to LOD, and the process is simple and automatic. Each texture already has a number of [[wikipedia:Mipmap\|mipmaps]] which are automatically generated by [[Content Manager]]. The highest mipmap is used whenever one texture element ([[wikipedia:texel\|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 mipmap 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.		In cases where no visible object is currently using the higher mipmap level(s), they may be fully unloaded to conserve RAM. When an object again nears the player, the higher mipmap levels will be reloaded. This process is known as [[wikipedia:Texture_streaming\|texture streaming]] and may be disabled in the game settings.

	=== Benefits ===		=== Benefits ===
Line 17:		Line 17:

	=== 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 [[wikipedia:anisotropy\|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. (Texture streaming only.)		* 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 mipmaps, even if all other objects are distant. The GPU will still render using the appropriate mipmap levels, but the game will be forced to keep the high-detail mipmaps 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.		* 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 mipmap 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 ==

Windwalkr at 03:24, 16 October 2017

2017-10-16T03:24:28Z

← Older revision		Revision as of 03:24, 16 October 2017
Line 42:		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.

Windwalkr at 02:07, 16 October 2017

2017-10-16T02:07:28Z

Windwalkr at 02:49, 26 July 2015

2015-07-26T02:49:32Z

← Older revision		Revision as of 02:49, 26 July 2015
Line 57:		Line 57:
	Question: What LOD scheme should attachments to a traincar use?		Question: What LOD scheme should attachments to a traincar use?

	~~Answer (by WindWalkr):~~ This is very situational. You can't currently benefit from mesh stitching if you're attached to a traincar, so my generalised recommendations would be:		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.
	* ~~Your choice of [[LM.txt file]] or [["mesh-table" container\|mesh-table LOD]] where the detail needs to be high enough that LOD is relevant.~~		* For T:ANE (4.1) all traincar meshes should be LM files.

	For T:ANE (4.1) all traincar meshes should be LM files.

Windwalkr at 02:48, 26 July 2015

2015-07-26T02:48:09Z

← Older revision		Revision as of 02:48, 26 July 2015
Line 63:		Line 63:
	* Your choice of [[LM.txt file]] or [["mesh-table" container\|mesh-table LOD]] where the detail needs to be high enough that LOD is relevant.		* Your choice of [[LM.txt file]] or [["mesh-table" container\|mesh-table LOD]] where the detail needs to be high enough that LOD is relevant.

	For T:ANE (4.1) ~~the maximum size of an attachment not using LOD must~~ be ~~less than 300 polygons (triangles)~~.		For T:ANE (4.1) all traincar meshes should be LM files.

Pcas1986: Added note about 300 poly limit on attachments.

2015-07-25T06:25:24Z

Added note about 300 poly limit on attachments.

← Older revision		Revision as of 06:25, 25 July 2015
Line 61:		Line 61:
	* 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.
	* Your choice of LM or mesh-table LOD where the detail needs to be high enough that LOD is relevant.		* Your choice of [[LM.txt file]] or [["mesh-table" container\|mesh-table LOD]] where the detail needs to be high enough that LOD is relevant.

			For T:ANE (4.1) the maximum size of an attachment not using LOD must be less than 300 polygons (triangles).


	=== LOD on Static Scenery Objects ===		=== LOD on Static Scenery Objects ===

Pcas1986 at 07:07, 2 June 2015

2015-06-02T07:07:51Z

← Older revision		Revision as of 07:07, 2 June 2015
Line 53:		Line 53:
	[[LM.txt file]]s 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.		[[LM.txt file]]s 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 Attachments to Traincars		==== LOD on Attachments to Traincars====

	Question: What LOD scheme should attachments to a traincar use?		Question: What LOD scheme should attachments to a traincar use?

	Answer (by ~~WindWalker~~): This is very situational. You can't currently benefit from mesh stitching if you're attached to a traincar, so my generalised recommendations would be:		Answer (by WindWalkr): This is very situational. You can't currently benefit from mesh stitching if you're attached to a traincar, so my 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.

Pcas1986: /* LOD on Moving or Animated Objects */ - additional information on attachments

2015-06-02T07:05:41Z

LOD on Moving or Animated Objects: - additional information on attachments

← Older revision		Revision as of 07:05, 2 June 2015
Line 52:		Line 52:

	[[LM.txt file]]s 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.		[[LM.txt file]]s 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 Attachments to Traincars

			Question: What LOD scheme should attachments to a traincar use?

			Answer (by WindWalker): This is very situational. You can't currently benefit from mesh stitching if you're attached to a traincar, so my 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.
			* Your choice of LM or mesh-table LOD where the detail needs to be high enough that LOD is relevant.

	=== LOD on Static Scenery Objects ===		=== LOD on Static Scenery Objects ===

Pcas1986: Rework of section on relevant WiKi pages, blog articles and threads. Some thread entries removed as they are covered by blog articles. Section on poly counts for LOD levels needs reviewing and is likely covered elsewhere?

2015-02-24T04:17:38Z

Rework of section on relevant WiKi pages, blog articles and threads. Some thread entries removed as they are covered by blog articles. Section on poly counts for LOD levels needs reviewing and is likely covered elsewhere?

← Older revision		Revision as of 04:17, 24 February 2015
Line 69:		Line 69:


	== ~~LOD Hints~~ and ~~Discussions~~ ==		== Related WiKi pages, Developer Blog Articles and Useful Trainz Forum Threads ==

	Implementing LOD has given some difficulties to both experienced and inexperienced content creators. Until this page, or associated pages, can be improved to provide finite advice, it is worthwhile scanning the Trainz forums to find additional hints and advice. The following threads and WiKi ~~pages have a significant amount of information on LOD and are worth reading:~~		===WiKi Pages===

	[~~http://forums~~.~~auran.com/trainz/showthread.php?98425-Level-of-Detail-how-useful-is-it&p=1109691#post1109691\|Examples of static and spline object config entries]~~		*[[Modeling_Guidelines]] - Provides a framework for considering performance when creating new models.

	[~~http:~~/~~/forums.auran.com/trainz/showthread.php?98425~~-Level-of-Detail~~-how-useful-is-it/page15&highlight=level+detail\|"Level~~ of ~~Detail how useful is~~ it"]		*[[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.

	[~~http:~~/~~/forums.auran.com/trainz/showthread.php?106099-Who~~-is~~-re-uploading-my-old-~~content-to-~~the-DLS\|"Who is re uploading my old content to the DLS"]~~		*[[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.

	[[~~HowTo/Make_your_first_Trainz_Asset~~]] - ~~tutorial~~ for ~~mesh~~-~~based LODs~~.		*[[Mesh_stitching]] - All about mesh stitching.

			*[[Modeling_Scenery]] - Guidance for creating scenery assets.



			===Trainz Developer Blog Articles===

			*[http://forums.auran.com/trainz/entry.php?884-Introduction-to-LOD\| Introduction to LOD]

			*[http://forums.auran.com/trainz/entry.php?890-Using-LOD-effectively\| Using LOD Effectively]


			===Trainz Forum Threads of Interest===
			Note that information in threads maybe be superseded by blog articles and specialist WiKi pages.

			*[http://forums.auran.com/trainz/showthread.php?117698-Scenery-lod&p=1371024#post1371024\| Scenery LOD (Feb 2015)]

	~~[[HowTo/Understand Level of Detail in Trainz]]~~

	== Categories ==		== Categories ==

Pcas1986 at 09:51, 10 June 2014

2014-06-10T09:51:37Z

← Older revision		Revision as of 09:51, 10 June 2014
Line 71:		Line 71:
	== LOD Hints and Discussions ==		== LOD Hints and Discussions ==

	Implementing LOD has given some difficulties to both experienced and inexperienced content creators. Until this page, or associated pages, can be improved to provide finite advice, it is worthwhile scanning the Trainz forums to find additional hints and advice. The following threads have a significant amount of information on LOD and are worth reading:		Implementing LOD has given some difficulties to both experienced and inexperienced content creators. Until this page, or associated pages, can be improved to provide finite advice, it is worthwhile scanning the Trainz forums to find additional hints and advice. The following threads and WiKi pages have a significant amount of information on LOD and are worth reading:

	[http://forums.auran.com/trainz/showthread.php?98425-Level-of-Detail-how-useful-is-it&p=1109691#post1109691\|Examples of static and spline object config entries]		[http://forums.auran.com/trainz/showthread.php?98425-Level-of-Detail-how-useful-is-it&p=1109691#post1109691\|Examples of static and spline object config entries]

← Older revision		Revision as of 02:07, 16 October 2017
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 ~~RAM~~ usage.		* 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 45:		Line 46:
	* 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 ~~that~~ the base mesh would imply (additional animation costs, attachment costs, scripting costs, physics costs, etc.)		* 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 [[~~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.		[[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 93:		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.