Debugging

When rendering objects using a camera, it can return useful debug information that you can use to ensure your game is running as smoothly as possible.

The #1 tool to assist with debugging is TetraTerm, which is a terminal application that hooks into your Tetra3D game, visualizes game data quickly and easily, and allows you to do some simple debugging and game state changes.

Camera debug stats

When rendering models through a Camera, Tetra3D will record stats that you can use to optimize and profile your game; they are accessible under Camera.DebugInfo, and can be quickly rendered to the screen using Camera.DrawDebugText().

The debug stat categories are as follows:

TPS
FPS
Total render frame-time
Skinned mesh animation time
Lighting frame-time
Draw calls (current out of total) (batch count)
Rendered triangles (current out of total)
Active Lights (current out of total)

• TPS represents the total average TPS (ticks per second, or logic / update framerate) of the game. Generally, if you're rendering too many things, the FPS might dip, but the TPS would generally stay consistent, and defaults to 60FPS, as Ebitengine dictates.
• FPS represents the total average FPS (frames per second, or framerate) of the game. This stat takes into account anything that could make the game as a whole slow down (i.e. including logic, pathfinding, networking, etc).
• Total render frame time is the amount of time spent rendering the frame, including transforming vertices, skinning meshes, performing any lighting, or running a custom vertex program on a mesh. Basically, this sums up the CPU portion of rendering with Tetra3D. If the main thread were to block in order to send data to the GPU, it would show up here as well.
• Skinned mesh animation time is how much time is spent specifically skinning animated meshes. This can be useful to know, as you might want to avoid skinning meshes if too much time is being spent on this unnecessarily.
• Lighting frame-time is the amount of time spent lighting the triangles that are rendered. If a triangle is not rendered, it is not lit, so more lights and more triangles makes this number rise. You can optimize this by baking lights, using limited lights, enabling distance on point lights, and turning off lights that are too far away.
• Draw calls represents the number of MeshParts rendered at a time, with a MeshPart being a collection of triangles. For each material, there is at least one MeshPart. It represents how many times Tetra3D sends triangle data to the GPU, essentially. Keeping this stat down is of key importance to maintaining a high frame-rate. If you can merge draw calls together (by merging objects and sharing materials, either in your 3D modeler or by using Model.Merge()), or batch them if they need to remain dynamically movable, Tetra3D will be able to send as many triangles as possible together at the same time, thereby keeping draw calls down. The first number is the currently rendered total, while the second is the total that could be rendered at any given time. The batch count is how many draw calls were batched together. Batching draw calls is also good to do if possible.
• Rendered triangles is how many triangles (out of the total) are currently being rendered through the camera. Triangles can be culled if they are facing away and backface culling is on for their material, or if they are outside the view, for example. This is also important to keep down to maintain a steady, high framerate.
• Active lights is how many lights you have active in your scene (out of the total in the scene), shining on various models.

Bounds debugging

You can use Camera.DrawDebugBoundsColored() to draw the shapes for bounds objects onscreen to help debug where they're placed.

TetraTerm

Tetraterm is very useful for debugging projects, particularly the scene hierarchy.