Frictional Game Wiki

<h1>Graphics Debug</h1> <div class="level1"> <p> Debugging the graphic performance of a level is vital to understand which parts are causing the bottleneck. It can also be used to find bugged/incorrect meshes or entities. </p> <p> Start Depth.exe in Dev mode and then press F1 to bring up the Debug Toolbar. The two groups that are important are the "Debug texts" and "Graphics Debug". </p> <p> <img src="/lib/exe/fetch.php?w=292&h=618&tok=49f158&media=hpl3:engine:debug_menu.png" class="media" alt="" width="292" height="618" /> </p> </div> <h2>Debug texts</h2> <div class="level2"> <p> The important checkboxes here are Show FPS, Show Memory Usage and Show Render Info. These will tell you how costly </p> <p> the rendering of the scene is. </p> </div> <h3>Show FPS</h3> <div class="level3"> <p> Shows how fast the level is running. </p> <ul> <li class="level1"> <b>FrameTime</b>: Shows how long it takes to render a frame, this is the most important info.</li> <li class="level2"> <b>FPS</b>: 1000 / FrameTime. It is what you usually see when talking about performance. It is easier to grasp but not as useful as FrameTime.</li> </ul> </div> <h3>Show Memory Usage</h3> <div class="level3"> <ul> <li class="level1"> <b>Renderer Memory Usage</b>: The amount of VRAM used by the renderer. This contains frame buffers, shadows, terrain and post-effects. It is greatly affected by the resolution of the window.</li> <li class="level2"> <b>Texture Memory Usage</b>: The texture memory used by the level. This contains all the textures used for the materials of the objects. Texture memory is reduced by a lot with just a few changes in the config file.</li> <li class="level2"> <b>Vertex Memory Usage</b>: The amount of VRAM used by meshes and decals. The imporant difference between Vertex and Texture memory is that Vertex memory can't be reduced by changing a setting. It takes up as much space on a good and a bad computer.</li> <li class="level2"> <b>Total Memory Usage</b>: The sum of the above memory usage.</li> </ul> </div> <h3>Show Rendering Info</h3> <div class="level3"> <ul> <li class="level1"> <b>Draw Calls</b>: The number of objects rendered in the current scene.</li> <li class="level2"> <b>Rendered Triangles / Vertices</b>: The total number of triangles and vertices rendered per frame.</li> <li class="level2"> <b>Queries</b>: A special draw call used to check if an object is occluded. It is more expensive than a draw call.</li> </ul> </div> <h2>Graphics Debug</h2> <div class="level2"> <p> To be able to find which parts of the scene that takes up the most performance you can use these special render modes. </p> </div> <h3>Previous Frame Occlusion</h3> <div class="level3"> <p> Pauses the occlusion culling and renders the scene with the occlusion culling from before the checkbox was ticked. This is used to see how effective the occlusion culling is in the specific scene. After activating this you can press F7 to fly around and look at the scene from another angle to see where the culling fails. Activating this will disable rendering of translucent objects since they can be unstable. </p> <p> <img src="/lib/exe/fetch.php?w=2560&h=720&tok=799489&media=hpl3:engine:occlusion_preview.png" class="media" alt="" width="2560" height="720" /> </p> <p> In the image to the left you can see what the player can see. It looks like only a few walls, some lockers and a door is rendered. On the right the camera has been moved back and it is now possible to see all the objects that get rendered this frame. There are a lot more than what it looks like in the left picture. </p> </div> <h3>GBuffer</h3> <div class="level3"> <p> Shows what the frame buffers look like. These are then used by the lights to shade the scene. It can be used to check if a model has incorrect textures or normals. </p> <p> <img src="/lib/exe/fetch.php?w=1280&h=720&tok=1c66da&media=hpl3:engine:g_buffer.png" class="media" alt="" width="1280" height="720" /> </p> </div> <h3>Light Complexity</h3> <div class="level3"> <p> Light complexity shows how expensive the lighting of a scene is. It creates a heatmap on the screen to show how much power each light takes. Overdraw of light is not very expensive, it is about twice as expensive as a translucent object. When the light has a shadow map it becomes much more expensive. The complexity of a shadow casting light is based on how many draw calls and triangles are required to generate the shadow map. </p> <p> <img src="/lib/exe/fetch.php?w=1280&h=360&tok=fae2bf&media=hpl3:engine:light_complexity.png" class="media" alt="" width="1280" height="360" /> </p> <p> The red areas on the right image is not good. There seem to be multiple large (in screen space) shadow casting lights in this scene. </p> <p> <img src="/lib/exe/fetch.php?w=640&h=360&tok=d3bc6a&media=hpl3:engine:light_complexity_no_shadows.png" class="media" alt="" width="640" height="360" /> </p> <p> To test if most of the complexity comes from shadows you can toggle the "Draw Shadows" checkbox on the Debug Menu. Here is what the scene complexity looks like without shadows. </p> </div> <h3>Overdraw</h3> <div class="level3"> <p> Creates a heatmap that shows how much translucent overdraw each pixel receives. Overdraw is how many times a pixel gets rendered to. The goal should be that no part of the screen is red. It does not matter that much if only a small part is. </p> <ul> <li class="level1"> Green: 0-16</li> <li class="level2"> Yellow: 16-32</li> <li class="level2"> Red: 32-48+</li> </ul> <p> <img src="/lib/exe/fetch.php?w=1280&h=360&tok=517cd1&media=hpl3:engine:translucent_overdraw.png" class="media" alt="" width="1280" height="360" /> </p> <p> On the left you can see the scene rendered normally. The fog particles are barely visible here. On the right the pixel overdraw is rendered. The red areas show that more than 32 translucent planes are rendered, which is not good. </p> </div>