| 123456789101112131415161718192021222324252627282930 |
- <!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"><meta name="keywords" content="performance"><title>Optimization reference</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/intermediate/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/intermediate/optimization.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/intermediate/"><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>Optimization reference</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="#maintain-low-geometry-count">Maintain low Geometry count</a></li><li><a href="#avoid-creating-new-objects">Avoid creating new objects</a></li><li><a href="#avoid-large-objects-in-physics">Avoid large objects in physics</a></li><li><a href="#check-the-statistics">Check the Statistics</a></li></ul></div></div><div id="content"><div id="preamble"><div class="sectionbody"><div class="paragraph"><p>This page is intended as a reference collection of optimization tricks that can be used to speed up JME3 applications.</p></div></div></div>
- <div class="sect1"><h2 id="maintain-low-geometry-count">Maintain low Geometry count</h2><div class="sectionbody"><div class="paragraph"><p>The more Geometry objects are added to the scene, the harder it gets to handle them in a speedy fashion.
- The reason for this is that a render command must be done for every object, potentially creating a bottleneck between the CPU and the graphics card.</p></div>
- <div class="paragraph"><p><strong>Possible optimization techniques</strong></p></div>
- <div class="ulist"><ul><li><p>Use GeometryBatchFactory.optimize(node) to merge the meshes of the geometries contained in the given node into fewer batches, each based on common Materials used.<br>
- You can optimize nodes using the SceneComposer in the SDK as well: Right-click a node and select “Optimize Geometry.</p></li></ul></div>
- <div class="paragraph"><p><strong>Side-effects</strong></p></div>
- <div class="ulist"><ul><li><p>Using GeometryBatchFactory merges individual Geometries into a single mesh. Thereby it becomes hard to apply specific Materials or to remove a single Geometry. Therefore it should be used for static Geometry only that does not require frequent changes or individual materials/texturing.</p></li><li><p>Using a <a href="../../jme3/advanced/texture_atlas.html">Texture Atlas</a> provides limited individual texturing of batched geometries.</p></li><li><p>Using the still experimental BatchNode allows batching Geometry while keeping the single Geometry objects movable separately (similar to animation, the buffer gets updated per Geometry position).</p></li></ul></div></div></div>
- <div class="sect1"><h2 id="avoid-creating-new-objects">Avoid creating new objects</h2><div class="sectionbody"><div class="paragraph"><p>Different Java implementations use different garbage collection algorithms, so depending on the platforms you target, different advice applies.</p></div>
- <div class="paragraph"><p>The major variants are Oracle’s JRE, old (pre-Gingerbread) Androids, and newer (Gingerbread or later) Androids.</p></div>
- <div class="paragraph"><p>Oracle’s JRE is a copying collector. This means that it does not need to do any work for objects that have become unreachable, it just keeps copying live objects to new memory areas and recycles the now-unused area as a whole.
- Older objects are copied less often, so the garbage collection overhead is roughly proportional to the rate at which your code creates new objects that survive for, say, more than a minute.</p></div>
- <div class="paragraph"><p>Gingerbread and newer Androids use a garbage collector that does some optimization tricks with local variables, but you should avoid creating and forgetting lots of objects in the scene graph.</p></div>
- <div class="paragraph"><p>Older Androids use a very naive garbage collector that needs to do real work for every object, both during creation and during collection. Creating local variables can build up a heap of work, particularly if the function is called often.</p></div>
- <div class="paragraph"><p>To avoid creating a temporary object, use <em>local methods</em> to overwrite the contents of an existing object instead of creating a new temporary object for the result.</p></div>
- <div class="paragraph"><p>E.g. when you use math operations like <code>vectorA.mult(vectorB);</code>, they create new objects for the result.</p></div>
- <div class="paragraph"><p>Check your math operations for opportunities to use the <em>local</em> version of the math operations, e.g. <code>vectorA.multLocal(vectorB)</code>. Local methods store the result in vectorA and do not create a new object.</p></div></div></div>
- <div class="sect1"><h2 id="avoid-large-objects-in-physics">Avoid large objects in physics</h2><div class="sectionbody"><div class="paragraph"><p>To offload much computation to the less CPU intense physics broadphase collision check, avoid having large meshes that cover e.g. the whole map of your level. Instead, separate the collision shapes into multiple smaller chunks. Obviously, don’t exaggerate the chunking, because having excessive amounts of physics objects similarly cause performance problems.</p></div></div></div>
- <div class="sect1"><h2 id="check-the-statistics">Check the Statistics</h2><div class="sectionbody"><div class="paragraph"><p>SimpleApplication displays a HUD with statistics. Use <code>app.setDisplayStatView(true);</code> to activate it, and false to deactivate it.
- The StatsView counts Objects,Uniforms,Triangles,Vertices are in the scene, and it counts how many FrameBuffers, Textures, or Shaders:</p></div>
- <div class="ulist"><ul><li><p>… were switched in the last frame (S)</p></li><li><p>… were used during the last frame (F)</p></li><li><p>… exist in OpenGL memory (M)</p></li></ul></div>
- <div class="paragraph"><p>For example, <code>Textures (M)</code> tells you how many textures are currently in OpenGL memory.</p></div>
- <div class="paragraph"><p>Generally jME3 is well optimized and optimizes these things correctly. Read <a href="../../jme3/advanced/statsview.html">statsview</a> to learn the details about how to interpret the statistics, how to tell whether your values are off, or whether they point out a problem.</p></div></div></div></div><div id="footer"><div id="footer-text">Version <br>Last updated 2019-12-22 21:29:50 +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>
|