|
|
@@ -87,12 +87,12 @@ To interpret the numbers correctly, consider that the 14 lines of text themselve
|
|
|
What do you want to avoid?
|
|
|
|
|
|
. 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.
|
|
|
-. 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: `GeometryBatchFactory.optimize(complexNode, true);` or a <<jme3/advanced/texture_atlas#,Texture Atlas>>.
|
|
|
-. 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 <<jme3/advanced/level_of_detail#,Level of Detail>> (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.
|
|
|
+. 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: `GeometryBatchFactory.optimize(complexNode, true);` or a xref:jme3tools/optimize/texture_atlas.adoc[Texture Atlas].
|
|
|
+. 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 xref:scene/control/level_of_detail.adoc[Level of Detail] (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.
|
|
|
. 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.
|
|
|
. 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).
|
|
|
** Example: In a test scene made up of boxes, you'd expect a vertex:triangle:object ratio of 8:12:1.
|
|
|
-** Terrains, models and spheres have higher counts, depending on their size and <<jme3/advanced/level_of_detail#,Level of Detail>> (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!
|
|
|
+** Terrains, models and spheres have higher counts, depending on their size and xref:scene/control/level_of_detail.adoc[Level of Detail] (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!
|
|
|
|
|
|
. 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.
|
|
|
. 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.
|
|
|
@@ -107,4 +107,3 @@ What goal are you trying to achieve in general?
|
|
|
See also:
|
|
|
|
|
|
* link:https://hub.jmonkeyengine.org/t/good-triangles-count/22843[What's a good triangle count?] Forum discussion
|
|
|
-* <<jme3/advanced/level_of_detail#,Level of Detail>>
|
mitm001