anchor.diff:  FrameBuffers (M) = 2
   FrameBuffers (F) = 2
   FrameBuffers (S) = 2
  -Textures (M) = 7 
  -Textures (F) = 3 
  +Textures (M) = 7
  +Textures (F) = 3
   Textures (S) = 3
   Shaders (M) = 6
   Shaders (F) = 3
  
positive.code: 
  Types of items counted:
  
  *  FrameBuffers: Total number of rendering surfaces used for off-screen rendering and render-to-texture functionality. 
  *  Textures: Total number of distinct textures used in the scene.
  *  Shaders: Total number of shaders used for effects (shading, blur, lighting, glow, etc).
  *  Objects: Total number of objects in the OpenGL pipeline. That is, objects attached to the rootNode and guiNode, etc.
  
negative.code: 
  .  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.
  .  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!
  
  .  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.
  