Performance

This document discusses performance from a content creation perspective. It seeks to enumerate the major factors which reduce game frame rate and reference the major strategies in avoiding problems.

Performance Concerns

There are a number of discreet metrics which should be considered when evaluating performance:

• The time taken to render each frame. This is inversely proportional to frame rate, and is a more useful metric.
• Timing variations between frames. Longer frames may cause visible hitches. Both longer and shorter frames can cause mis-predictions which are nearly as bad.
• Latency between basic user input (such as a camera movement) and the result appearing on-screen.
• Latency between complex user input (such as a database search, moving a spline, or placing a new locomotive) and the result being finalized.
• Loading time when entering a session, or when teleporting from place to place in a session.

The Low Level

In order to render a single frame, Trainz must perform the following steps in order:

1. Perform a single frame update for all frame-locked game threads. The important threads from a content creation perspective are the Game Main Thread and the PhysX Thread. Most other threads are not frame-locked, or are not likely to hurt frame performance.

2. Process GPU buffer uploads, culling, and sorting.

3. Render the shadow buffer (if enabled).

4. Render the reflection buffer (if enabled).

5. Render the main scene.

6. Vsync and display the result.

Several of these steps are overlapped between frames; for example once the game threads have completed one frame and passed the frame to the renderer, they may start on the next frame. This overlap reduces frame time but does not reduce simple input latency.

Because these steps are performed sequentially, a stall at any stage will delay the entire frame. To reach a steady 60fps, the entire process must complete within 16ms with no exceptions.

Game Main Thread

Per-frame Costs

Per-frame costs are those that are paid for every rendered frame in normal operation. This specifically refers to CPU costs, and includes:

• Train Physics.
• Playing of animations.
• Scene edits for visibility changes or LOD changes.
• Script overheads.

One-off Costs

One-off costs are those that are paid in response to a specific trigger. These might occur semi-frequently but do not occur every frame or on a fixed timer. This specifically refers to CPU costs, and includes:

• Updating signals.
• Render Origin updates.
• One-off script actions.

Loading

Loading occurs both on module startup and also while streaming. Related costs include:

• Object initialization during tile streaming.
• Loading texture data to the GPU.
• Loading meshes to the GPU.

PhysX Thread

The PhysX thread is responsible for simulating the PhysX scene, which is used for physical effect simulation with the exception of Train Physics. This thread is responsible for:

• Editing the PhysX scene as objects are streamed in and out.
• Testing for PhysX collisions. In Trainz, this mainly amounts to PFX-vs-scenery collision testing.
• Updating the PFX motion in general.
• Render Origin updates.

GPU

This includes both performance costs on the GPU itself, and driver overheads involved with loading commands and data to the GPU:

• Loading texture data to the GPU.
• Loading mesh data to the GPU.
• Submitting draw calls to the GPU.
• Vertex shading (and Geometry shading, etc.)
• Fragment shading.

Settings

TBD.

Profiling

TBD.

• Trainz Profiler
• Event Profiler
• Pause
• In-game performance stats
• Asset Preview