Mesh stitching

From TrainzOnline
(Difference between revisions)
Jump to: navigation, search
 
m
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Mesh stitching]] is an TS2009 rendering optimization that is automatically applied to many types of static meshes. It allows multiple smaller objects to be uploaded to the GPU as a single object, reducing per-object overheads that would otherwise apply.
+
[[Mesh stitching]] is a rendering optimization that is automatically applied to many types of static [[mesh]]es. It allows multiple smaller objects to be uploaded to the GPU as a single object, reducing per-object overheads that would otherwise apply.
  
 
=Performance=
 
=Performance=
Modern GPUs have a per-material setup cost which results in a cost of roughly 300 polygons for any render chunk, regardless of whether that chunk is 1 polygon or 300. For chunks with significantly higher polygon count, this overhead is negligible, however when dealing with large numbers of small objects the overhead can quickly become far more expensive than the actual polygon rendering. [[Mesh stitching]] provides a mechanism, transparent to the content creator, of batching large numbers of small chunks into a single render call.
+
Modern GPUs have a per-material setup cost which results in a cost of roughly 300 polygons for any render chunk, regardless of whether that chunk is 1 polygon or 300. For chunks with significantly higher polygon count, this overhead is negligible, however when dealing with large numbers of small objects the overhead can quickly become far more expensive than the actual polygon rendering. Mesh stitching provides a mechanism, transparent to the content creator, of batching large numbers of small chunks into a single render call.
  
In order for this technique to work, the chunks must all share the same material type. This is typically true when the same asset is placed repeatedly (for example, track, or trees in a forest) but can also occur through the use of a [[Mesh library]].
+
In order for this technique to work, the chunks must all share the same material type. This is typically true when the same asset is placed repeatedly (for example, track, or trees in a forest) but can also occur through the use of a [[mesh library]].
  
[[Mesh stitching]] causes the provided mesh(es) to be broken into their component chunks, and then each chunk is stitched against other chunks in the scene which share the same material.
+
Mesh stitching causes the provided mesh(es) to be broken into their component [[render chunk]]s, and then each chunk is stitched against other chunks in the scene which share the same material.
 +
 
 +
Specific [[Level of Detail]] techniques apply to stitched meshes.
  
  
 
=Suitability=
 
=Suitability=
TS2009 automatically determines whether a given object is a suitable candidate for [[Mesh stitching]]. There is no user mechanism for specifically enabling or disabling mesh stitching on a specific object, however there are various specific cases which are not supported by [[Mesh stitching]] and should be avoided where possible to allow maximum performance.
+
Trainz automatically determines whether a given object is a suitable candidate for mesh stitching. There is no user mechanism for specifically enabling or disabling mesh stitching on a specific object, however there are various specific cases which are not supported by mesh stitching and should be avoided where possible to allow maximum performance. Certain decisions are made at the per-asset level. Certain decisions are made at the per-mesh level.
  
* [[Mesh stitching]] is only applicable to meshes in the .IM file format. Meshes in .PM or .LM format are not candidates for stitching.  
+
* Mesh stitching is only applicable to meshes in the [[IM file]] format and [[trainzmesh file]] format. Meshes in [[LM.txt file]] format are not candidates for stitching.  
  
* Meshes with animation skeletons are excluded from mesh stitching.
+
* Meshes with animations applied are excluded from mesh stitching.
  
 
* Meshes which are attached to a mesh which is not stitched, are typically not stitched.
 
* Meshes which are attached to a mesh which is not stitched, are typically not stitched.
  
* Certain asset types are excluded from stitching because they are expected to move frequently. [[KIND Traincar]] and [[KIND Interior]] are examples of this (TBD: full list here.)
+
* Certain asset types are excluded from stitching because they are expected to move frequently. [[KIND Traincar]] and [[KIND Interior]] are examples of this.
  
* Meshes which have very high polygon counts are typically excluded from mesh stitching, as the cost of stitching is roughly proportional to the number of triangles and the benefit of stitching falls as the triangle count approaches the maximum hardware buffer size.
+
* Meshes which have very high polygon counts are typically excluded from mesh stitching, as the cost of stitching is roughly proportional to the number of [[vertex buffer|vertices]] and the benefit of stitching falls as the vertex count approaches the maximum buffer size.
  
 
* TBD: Other restrictions which prevent mesh stitching.
 
* TBD: Other restrictions which prevent mesh stitching.
 +
 +
 +
In the event that stitching is not enabled for a given mesh, [[hardware instancing]] may be employed instead.
  
  
 
=Limitations=
 
=Limitations=
  
Although for many purposes, [[mesh stitching]] is a huge win, there are a few potential downsides to the this approach.
+
Although for many purposes, mesh stitching is a huge win, there are a few potential downsides to the this approach.
  
* There is a higher cost, both in terms of actual cpu time and in terms of latency, to modifying a stitched mesh in any way. Even a simple change, for example rotation or positioning, will require the mesh to be restitched. Meshes which are modified frequently are not good candidates for [[mesh stitching]], however it is not always possible for the game to detect that a mesh will be used in this manner. Care should be taken to avoid unnecessary modifications to meshes.
+
* There is a higher cost, both in terms of actual cpu time and in terms of latency, to modifying a stitched mesh in any way. Even a simple change, for example rotation or positioning, will require the mesh to be restitched. Meshes which are modified frequently are not good candidates for mesh stitching, however it is not always possible for the game to detect that a mesh will be used in this manner. Care should be taken to avoid unnecessary modifications to meshes.
  
* Since [[mesh stitching]] determines whether materials are shared at load time, it is not possible to use effects which would require the material to be manipulated at runtime where [[mesh stitching]] is active. This means that certain material-manipulating effects are now considered obsolete:
+
* Since mesh stitching determines whether materials are shared at load time, it is not possible to use effects which would require the material to be manipulated at runtime where mesh stitching is active. This means that certain material-manipulating effects are now considered obsolete:
  
:* Texture replacement must be performed via an texture-replacement effect in the mesh-table, so that the game is aware that the materials will be dynamically modified and is not suitable for [[mesh stitching]]. Texture replacement via script without using a texture-replacement effect will not function.
+
:* Texture replacement must be performed by a texture-replacement effect in the mesh-table, so that the game is aware that the materials will be dynamically modified and is not suitable for mesh stitching. Texture replacement via script without using a texture-replacement effect will not function.
  
 
:* Changes to material lighting parameters from script will not function. The material should be configured correctly in Max so that the final configuration is available to the game at load time.
 
:* Changes to material lighting parameters from script will not function. The material should be configured correctly in Max so that the final configuration is available to the game at load time.
Line 41: Line 46:
  
  
TBD: How are attachment points affected?
+
=See Also=
 +
[[Runtime_Performance_Statistics]]
  
TBD: Script control of stitched meshes.
+
[[Category:TBD]]

Latest revision as of 11:20, 16 October 2017

Mesh stitching is a rendering optimization that is automatically applied to many types of static meshes. It allows multiple smaller objects to be uploaded to the GPU as a single object, reducing per-object overheads that would otherwise apply.

Contents

[edit] Performance

Modern GPUs have a per-material setup cost which results in a cost of roughly 300 polygons for any render chunk, regardless of whether that chunk is 1 polygon or 300. For chunks with significantly higher polygon count, this overhead is negligible, however when dealing with large numbers of small objects the overhead can quickly become far more expensive than the actual polygon rendering. Mesh stitching provides a mechanism, transparent to the content creator, of batching large numbers of small chunks into a single render call.

In order for this technique to work, the chunks must all share the same material type. This is typically true when the same asset is placed repeatedly (for example, track, or trees in a forest) but can also occur through the use of a mesh library.

Mesh stitching causes the provided mesh(es) to be broken into their component render chunks, and then each chunk is stitched against other chunks in the scene which share the same material.

Specific Level of Detail techniques apply to stitched meshes.


[edit] Suitability

Trainz automatically determines whether a given object is a suitable candidate for mesh stitching. There is no user mechanism for specifically enabling or disabling mesh stitching on a specific object, however there are various specific cases which are not supported by mesh stitching and should be avoided where possible to allow maximum performance. Certain decisions are made at the per-asset level. Certain decisions are made at the per-mesh level.

  • Meshes with animations applied are excluded from mesh stitching.
  • Meshes which are attached to a mesh which is not stitched, are typically not stitched.
  • Certain asset types are excluded from stitching because they are expected to move frequently. KIND Traincar and KIND Interior are examples of this.
  • Meshes which have very high polygon counts are typically excluded from mesh stitching, as the cost of stitching is roughly proportional to the number of vertices and the benefit of stitching falls as the vertex count approaches the maximum buffer size.
  • TBD: Other restrictions which prevent mesh stitching.


In the event that stitching is not enabled for a given mesh, hardware instancing may be employed instead.


[edit] Limitations

Although for many purposes, mesh stitching is a huge win, there are a few potential downsides to the this approach.

  • There is a higher cost, both in terms of actual cpu time and in terms of latency, to modifying a stitched mesh in any way. Even a simple change, for example rotation or positioning, will require the mesh to be restitched. Meshes which are modified frequently are not good candidates for mesh stitching, however it is not always possible for the game to detect that a mesh will be used in this manner. Care should be taken to avoid unnecessary modifications to meshes.
  • Since mesh stitching determines whether materials are shared at load time, it is not possible to use effects which would require the material to be manipulated at runtime where mesh stitching is active. This means that certain material-manipulating effects are now considered obsolete:
  • Texture replacement must be performed by a texture-replacement effect in the mesh-table, so that the game is aware that the materials will be dynamically modified and is not suitable for mesh stitching. Texture replacement via script without using a texture-replacement effect will not function.
  • Changes to material lighting parameters from script will not function. The material should be configured correctly in Max so that the final configuration is available to the game at load time.

[edit] Metrics

The Runtime Performance Statistics display in Surveyor can be used to analyse the performance of the stitched mesh system. This is useful for testing entire scenes as well as accurately gathering data on single objects. Unlike counters in external tools, the statistics display provides a measure of how content is actually performing on your hardware.


[edit] See Also

Runtime_Performance_Statistics

Personal tools