Mesh stitching
(→Limitations) |
m |
||
Line 1: | Line 1: | ||
− | [[Mesh stitching]] is | + | [[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. |
=Performance= | =Performance= | ||
Line 14: | Line 14: | ||
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. | 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. | ||
− | * [[Mesh stitching]] is only applicable to meshes in the | + | * [[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 animation skeletons are excluded from mesh stitching. |
Revision as of 14:15, 10 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 |
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 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.
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.
- 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 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.)
- 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.
- TBD: Other restrictions which prevent mesh stitching.
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.
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.
TBD: How are attachment points affected?
TBD: Script control of stitched meshes.
See Also
Runtime_Performance_Statistics