Mesh stitching
From TrainzOnline
(Difference between revisions)
m |
|||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Mesh stitching]] is | + | [[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. | + | 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 [[ | + | 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 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= | ||
| − | + | 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 and [[trainzmesh file]] format. Meshes in [[LM.txt file]] format are not candidates for stitching. |
| − | * Meshes with | + | * 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 | + | * 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 | + | * 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, | + | 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 | + | * 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 | + | * 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 | + | :* 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: | ||
| − | + | =See Also= | |
| + | [[Runtime_Performance_Statistics]] | ||
| − | + | [[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.
- 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 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.
