Revision as of 17:56, 19 February 2014

TS2009sp2 provides a simple tool for monitoring asset performance in Surveyor. Poor-performing assets can negatively affect both the frame rate and the available draw distance. In extreme cases, TS2009 will reduce the draw distance below the user's setting to reduce the risk of crashing due to excess resource consumption.

Displaying Performance Statistics

As of TS2009 SP2, any user may activate a performance statistics display in Surveyor. This display is accurate on a per-frame basis. While the display is active, the user may notice a small overall decrease in frame rate.

To active or deactivate the display, follow these steps:

• Go to the Trainz game menu button in the top left of the screen;
• Select the "Options" menu;
• Change to the "Surveyor Settings" screen;
• Toggle the "Display performance stats" setting as appropriate.

Statistics

In the current version of the tool, the following information is displayed:

Stitched Mesh Statistics

These statistics represent the inputs and outputs of the mesh stitching system, which prepares efficient geometry for submission to the GPU. These numbers relate to the mesh stitching resources only, and do not account for similar types of resource usage in other systems. Larger numbers typically indicate increased system load.

• total buffers - The number of hardware buffers currently in use for the stitched mesh system. There will always be a minimum of one hardware buffer allocated per material. If a material is assigned to a large number of triangles, additional hardware buffers may be allocated to share the load. In "compatibility mode", some asset types may require one buffer per request, rather than stitching multiple requests into a single buffer.
• unprocessed buffers - The number of buffers which require CPU stitching. This number should be zero when idle, and increases while objects are being loaded, unloaded, or are changing Level of Detail (LOD).
• vertices - The total number of hardware vertices present in the stitched mesh system.
• indices - The total number of hardware indices present in the stitched mesh system. This number correlates with the number of triangles being rendered (typically three indices per triangle.)
• materials - The number of distinct materials present in the stitched mesh system.
• total requests - The total number of input requests to the stitched mesh system. This is a general indicator of route density.
• unprocessed requests - The total number of input requests which require CPU stitching. This number should be zero when idle, and increases while objects are being loaded, unloaded, or are changing LOD.
• worst buffer count - The KUID and total buffer count of the single asset which is consuming the largest number of hardware buffers. This does not necessarily indicate a poor performer - it may be that the asset is simply used far more heavily than other assets in the current scene. This is, however, a great place to start looking if performance is suffering.
• worst index count - The KUID and total index count of the single asset which is consuming the largest number of hardware indices. This does not necessarily indicate a poor performer - it may be that the asset is simply used far more heavily than other assets in the current scene. This is, however, a great place to start looking if performance is suffering.

Performance Fixing for End-Users

End Users can do little to resolve the types of performance issue discussed here. Running in "Native Mode" instead of using "Compatibility Mode" can provide a very significant performance boost at the expense of some visual compatibility with older content. Keeping up-to-date with the latest Trainz and content updates can also help make sure that you have the latest performance optimisations.

Performance Fixing for Route Builders

There are hard caps to the 'total buffers', 'vertices' and 'indices' figures above to prevent the system from exhausting all resource space which leads to a game crash. These caps are typically quite generous, however it is possible for specific assets to be constructed in such a way that they rapidly exhaust available resources.

When the usage starts to approach the hard caps, Trainz will attempt to reduce the draw distance in an effort to prevent hitting a hard cap. Hitting the hard cap is considered bad because any further items will not be rendered - this can include large items near the viewer. It is better to reduce the draw distance such that nearby items can be seen and distant items will be culled.

If overall performance is poor, or the if the draw distance is being visibly reduced, the route builder should pay close attention to the 'worst buffer count' and 'worst index count' statistics. In the majority of cases, one of these statistics will directly indicate the cause of the problem. It is worth noting that several assets can contribute to poor performance in a given scene - after identifying and removing the worst performer, the next-worst performer will be revealed. Route builders should remove or reduce the usage of the worst performers from the route, or substitute them for alternative better-performing assets.

Note that the performance statistics relate to the objects currently in view. Moving to another location on the route, changing the viewing angle, or adjusting the draw distance may affect the results provided by this tool.

Performance Fixing for Asset Builders

When creating content, the Surveyor performance statistics display can be useful for testing the efficiency of your model.

Test Methodology

Simply load up a blank baseboard, place a large number of copies of one item of your content scattered around the baseboard, and watch the performance numbers. The Surveyor "Replace Assets" command can be useful to perform like-for-like comparisons of your content against similar existing items.

When testing performance, you should generally not place a large number of objects at a single location, as this is an unrealistic test and skews the results. Distribute your objects around the scene.

It is best to test your object in relatively large numbers, with no other changes to the blank baseboard - no terrain editing; no terrain painting; no other scenery or splines.

A blank baseboard has some performance costs for terrain rendering. Be sure to note those numbers as a baseline before you start adding your own test objects.

Test Results

If your test object does not show up in the statistics, it is not being handled by the mesh stitching system. For high-detail or animated object, this is expected behavior. For medium-to-low detail static objects, this suggests a performance problem that should be resolved. It is worth noting that the low LOD of an object may be stitched while the higher-detailed LODs are not stitched. This will be accurately reflected in the statistics.

The material count for your object (whether singularly, or in large quantities) should be low, preferably 1-2 total. If the material count is overly large, consider revising your material setup in your modeling tool.

For efficient low-polygon objects, all numbers should stay relatively low even when large amounts of the content are placed on the baseboard.

For efficient high-polygon objects with LOD, you should see a relatively low material and buffer count, and higher vertex and index counts. As you approach your content, the vertex and index counts will rise rapidly - moving away from your content, the vertex and index counts should drop substantially. A single object at highest LOD may have the same impact on the numbers as hundreds or thousands of objects at the lowest LOD.

It is worth noting that the hardware vertex count may be significantly higher than what you might expect from looking at the vertex count inside of your modeling tool. This is due to the modeling tools representing any single point in 3D space as a single vertex, whereas the hardware may need to separate different smoothing groups and materials into separate vertices.

In all cases, the number of hardware buffers should stay low - roughly one buffer per ten thousand vertices. It is best to measure this after you have placed a medium-to-large number of your test object onto the route. If you are seeing significantly higher buffer numbers than this, your object is likely to cause performance problems when used in quantity.

See Also

Mesh Stitching