| 123456789101112131415161718192021222324252627282930313233343536373839404142434445 |
- <!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]--><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta name="generator" content="Asciidoctor 1.5.4"><title>Optimizing Your Game Using Statistics</title><link rel="stylesheet" href="./asciidoctor.css">
- <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.5.0/css/font-awesome.min.css">
- <link rel="stylesheet" href="./coderay-asciidoctor.css"><link rel="stylesheet" href="https://cdn.jsdelivr.net/docsearch.js/2/docsearch.min.css"><link rel="stylesheet" href="/home/travis/build/jMonkeyEngine/wiki/build/asciidoc/html5/jme3/advanced/twemoji-awesome.css"></head><body class="article toc2 toc-left"><div id="header"><div id="toolbar"><a href="https://github.com/jMonkeyEngine/wiki/edit/master/src/docs/asciidoc/jme3/advanced/statsview.adoc"><i class="fa fa-pencil-square" aria-hidden="true"></i></a><a href="https://github.com/jMonkeyEngine/wiki/new/master/src/docs/asciidoc/jme3/advanced/"><i class="fa fa-plus-square" aria-hidden="true"></i></a><input dir="auto" style="position: relative; vertical-align: top;" spellcheck="false" autocomplete="off" class="searchbox__input aa-input" id="doc-search" name="search" placeholder="Search in the doc" required="required" type="search"></div><h1>Optimizing Your Game Using Statistics</h1><div class="details"><span class="author" id="author"></span><br><span id="revnumber">version ,</span> <span id="revdate">2016/03/17 20:48</span></div><div id="toc" class="toc2"><div id="toctitle">Table of Contents</div><ul class="sectlevel1"><li><a href="#on-off">On/Off</a></li><li><a href="#terminology">Terminology</a></li><li><a href="#how-to-interpret-the-fps-when-optimizing">How to Interpret the FPS when Optimizing</a></li><li><a href="#how-to-interpret-the-statistics">How to Interpret The Statistics</a></li></ul></div></div><div id="content"><div id="preamble"><div class="sectionbody"><div class="paragraph"><p>When you create a SimpleApplication, you see the default StatsView and FpsView in the left corner.
- The StatsView displays object statistics that are used during development, for example for debugging and optimization.
- Below the StatsView is the FpsView that displays the frames that jMonkeyEngine can render per second.</p></div>
- <div class="paragraph"><p>The main use case of these statistics is to find out why the application may be running slow and where to start fixing the performance.</p></div>
- <div class="paragraph"><p>The StatsView + FpsView look like this example:</p></div>
- <div class="listingblock"><div class="content"><pre class="CodeRay highlight"><code>FrameBuffers (M) = 2
- FrameBuffers (F) = 2
- FrameBuffers (S) = 2
- Textures (M) = 7
- Textures (F) = 3
- Textures (S) = 3
- Shaders (M) = 6
- Shaders (F) = 3
- Shaders (S) = 4
- Objects = 24
- Uniforms = 31
- Triangles = 582
- Vertices = 1148
- Frames per Second: 30</code></pre></div></div></div></div>
- <div class="sect1"><h2 id="on-off">On/Off</h2><div class="sectionbody"><div class="paragraph"><p>You switch the StatsView on an off in the simpleInitApp() method by setting a boolean:</p></div>
- <div class="listingblock"><div class="content"><pre class="CodeRay highlight"><code data-lang="java">setDisplayFps(<span class="predefined-constant">false</span>); <span class="comment">// to hide the FPS</span>
- setDisplayStatView(<span class="predefined-constant">false</span>); <span class="comment">// to hide the statistics</span></code></pre></div></div></div></div>
- <div class="sect1"><h2 id="terminology">Terminology</h2><div class="sectionbody"><div class="paragraph"><p>Types of items counted:</p></div>
- <div class="ulist"><ul><li><p>FrameBuffers: Total number of rendering surfaces used for off-screen rendering and render-to-texture functionality.</p></li><li><p>Textures: Total number of distinct textures used in the scene.</p></li><li><p>Shaders: Total number of shaders used for effects (shading, blur, lighting, glow, etc).</p></li><li><p>Objects: Total number of objects in the OpenGL pipeline. That is, objects attached to the rootNode and guiNode, etc.</p></li><li><p>Uniforms: Total number of shader uniforms. Uniforms are predefined variables used as parameters in shader calculations, containing data such as matrices, vectors, time, and colors.</p></li><li><p>Triangles: Total number of triangles (faces) of the meshes of all objects.</p></li><li><p>Vertices: Total number of vertices (corner points) of the meshes of all the objects.</p></li></ul></div>
- <div class="paragraph"><p>Types of statistics:</p></div>
- <div class="ulist"><ul><li><p><strong>(M) = Memory</strong> – Number of items currently in OpenGL memory.</p></li><li><p>*(F) = Frame * – Number of items used by current frame (visible).</p></li><li><p><strong>(S) = Switches</strong> – Number of items that were state switched in the last frame.</p></li></ul></div>
- <div class="paragraph"><p>The StatsView does not include any Physics statistics.</p></div></div></div>
- <div class="sect1"><h2 id="how-to-interpret-the-fps-when-optimizing">How to Interpret the FPS when Optimizing</h2><div class="sectionbody"><div class="paragraph"><p>The FPS (frames per second) shows you how fast jME runs the update loop. If the FPS values goes below 30, the game slows down and runs jerky, which makes the game either frustrating or impossible to play. You need either decrease the number of operations in the update loop, or decrease memory usage (object count).</p></div>
- <div class="paragraph"><p>If your application grows more and more sluggish, deactivate or decrease one feature set at a time: Deactivate drop shadows, physics, anti-aliasing… Try fewer light sources, fewer NPCs, fewer samples in spheres (i.e. less smooth spheres). Temporarily replace the scene (or parts of it) with a simpler test scene to check whether the scene has to many triangles, etc.</p></div>
- <div class="paragraph"><p>Keep an eye on FPS and the StatsView and find out which element has the biggest impact on performance. This is where you start optimizing.</p></div></div></div>
- <div class="sect1"><h2 id="how-to-interpret-the-statistics">How to Interpret The Statistics</h2><div class="sectionbody"><div class="admonitionblock important"><table><tr><td class="icon"><i class="fa icon-important" title="Important"></i></td><td class="content"><div class="paragraph"><p>To interpret the numbers correctly, consider that the 14 lines of text themselves already count as 14 objects with 914 vertices. You need to subtract these values from the totals for smaller performance experiments.</p></div></td></tr></table></div>
- <div class="paragraph"><p>What do you want to avoid?</p></div>
- <div class="olist arabic"><ol class="arabic"><li><p>FrameBuffers: If you don’t use any post-processing effects (FilterPostProcessor), this count should be zero. The more effects you use, the more FrameBuffers are in use. If this value is high while others are normal, and your game is sluggish, you can speed up the application by using fewer post-processing effects.</p></li><li><p>The Object Count (Batch Count) is a very important value that indicates how many geometries were rendered in the last frame. In general, if you keep the object count around 100-200, your game will be fast and responsive. If the count is permanently higher, hand-code rules that detach remote objects, or optimize a complex multi-material scene using: <code>GeometryBatchFactory.optimize(complexNode, true);</code> or a <a href="../../jme3/advanced/texture_atlas.html">Texture Atlas</a>.</p></li><li><p>Triangle Counts. If your game is sluggish and triangle (polygon) count is high, then you are rendering too many, too detailed meshes. Tell your graphic designers to create models with lower polygon counts, or use a <a href="../../jme3/advanced/level_of_detail.html">Level of Detail</a> (LOD) optimization. The limit is around 100'000 vertices for a scene, considering that the slowest currently used graphic cards cannot handle anything beyond that.</p></li><li><p>Are any counts constantly increasing right before the game slows down or runs out of memory? Check whether you are accidentally adding objects in a loop, instead of only once.</p></li><li><p>Verify that the numbers are plausible. If you think you generated a test scene out of “a few” boxes, but the StatsView shows ten thousands of triangles, then you probably have extra objects out of sight somewhere (due to barely visible materials, overlapping with other objects, scaled too big or too small to see, etc).</p><div class="ulist"><ul><li><p>Example: In a test scene made up of boxes, you’d expect a vertex:triangle:object ratio of 8:12:1.</p></li><li><p>Terrains, models and spheres have higher counts, depending on their size and <a href="../../jme3/advanced/level_of_detail.html">Level of Detail</a> (LOD). A high-poly model looks pretty in Blender, but you must find a lower-poly, low-LOD compromise if you want several large objects in one scene!</p></li></ul></div></li><li><p>If S (objects being switched) are high compared to F (objects used), then you use or generate too many different Materials (etc). You are unnecessarily forcing jME to re-load and re-bind objects (= Switches), which is bad for performance. Also if you have many transparent materials in your scene, this results in more switches, and you should use fewer transparent materials.</p></li><li><p>If the M values (objects in memory) are high compared to F (objects used), that means a lot more GL objects are kept in memory than are actually used. This can happen in large scenes with many materials. Consider breaking the scene up and detaching objects while they are out of sight, so the built-in culling can optimize the scene.</p></li></ol></div>
- <div class="paragraph"><p>What goal are you trying to achieve in general?</p></div>
- <div class="olist arabic"><ol class="arabic"><li><p>The values for (M) and (F) should be within the same order of magnitude. This means your code only loads objects that it actually needs, and that the hardware can actually handle.</p></li><li><p>It’s okay if Switches (S) are lower than Used in Current Frame (F).</p></li><li><p>The FPS should be 30 or more on the slowest hardware that you target.</p></li><li><p>10'000-50'000 vertices is a typical average value for a scene.</p></li></ol></div>
- <hr>
- <div class="paragraph"><p>See also:</p></div>
- <div class="ulist"><ul><li><p><a href="https://hub.jmonkeyengine.org/t/good-triangles-count/22843">What’s a good triangle count?</a> Forum discussion</p></li><li><p><a href="../../jme3/advanced/level_of_detail.html">Level of Detail</a></p></li></ul></div></div></div></div><div id="footer"><div id="footer-text">Version <br>Last updated 2019-12-20 23:30:51 +00:00</div></div><script type="text/javascript" src="https://cdn.jsdelivr.net/docsearch.js/2/docsearch.min.js"></script><script>docsearch({
- apiKey: 'a736b6d93de805e26ec2f49b55013fbd',
- indexName: 'jmonkeyengine',
- inputSelector: '#doc-search',
- debug: false // Set debug to true if you want to inspect the dropdown
- });</script></body></html>
|