# Optimization reference

This page is intended as a reference collection of optimization tricks that can be used to speed up JME3 applications.

## Maintain low Geometry count

The more Geometry objects are added to the scene, the harder it gets to handle them in a speedy fashion. The reson for this is, that for every object a render command must be done, here is a bottleneck betwenn the CPU and the Graficcard. Possible optimization techniques

- Use GeometryBatchFactory.optimize(node) to merge the meshes of the geometries contained in the given node into fewer batches (based on common Material used).

Side-effects

- 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.
- Using Texture atlases might be a way to provide a limited individual texturing.

## Avoid creating new objects

When you use math operations like vectorA.mult(vectorB); new objects are created that have to be garbage collected when you don't use them anymore. Check your math operations for opportunities to use the local version of the math operations, e.g. vectorA.multLocal(vectorB). This way the result is stored in vectorA and no new object needs to be created.

## Check the Statistics

SimpleApplication displays a HUD with statistics. Use `app.setDisplayStatView(true);` to activate it, and false to deactivate it. It counts how many FrameBuffers, Textures, or Shaders…

- … were switched in the last frame (S)
- … were used during the last frame (F)
- … exist in memory (M)

Example:

- Textures (M) = how many textures are currently in the OpenGL driver
- Textures(F) = how many textures were used in the last frame
- Textures(S) = how many texture switches were done in the last frame.

Genereally jME3 is well optimized and optimizes these things correctly. The normal state is that the (S/F/M) values should be in the same order of magnitude; (S) values can be lower than (F).

- If the (S) values are significantly higher than the (F) values, that means there are a lot of extra switches happening which can cause a performance loss. Switches happen for instance if you have many transparent materials in your scene. In that case this tells you that you should use fewer transparent materials.
- If the (M) values are much higher than the (F) values, that means a lot more GL objects are in memory than are actually used. This can happen in rare cases, such as extremely large scenes (> 2000 wu). In this case, you should can optimize performance by identifying spatials to cull or detach.
- The Object Count (Batch Count) is a very important value that indicates how many geometries were rendered in the last frame. In general, try to keep the object count around 100-200 to keep your game fast and responsive. If the count is permanently higher, optimize your scene via GeometryBatchFactory or other means.
- Same for Triangle Counts. If your game runs sluggishly and triangle count is high, then you are rendering too many too detailed meshes.
- 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.

performance

view online version