A geometry has different LOD levels and a mesh per level. You can either generate the meshes and assign them or you can create a Control that handles that based on specific parameters like model type and camera location.
The LOD levels are essentially just index buffers. When you switch to a lower level you reduce triangles by using a smaller (reduced) index buffer. In your case its probably best to just hide the bolts when you get too far. It will be significantly more efficient than rendering them when far away.
Aaah … ok, here was my fault. I always thought a different lod level could be a completely different geometry.
Already had some idea this could be just another index buffer after looking at GeometryBatchFactory.makeLod() but i had not fully understand the method.
Thank you for clarification.
What i have thought about now is to write my own controller which replaces the geometry or hides it completely.
The idea is, the controller stores the original object, removes it from parent node and adds a replacement geometry to the node, having the controller object (storing the old object) assigned again.
Do you think this would be the right aproach?
About hiding an object:
Is there some flag to be used to have a object still attached to the branch but removed from the render queue?
As i understand controllers, they are only executed on objects which are attached to rootNode. Just removing the object would mean it never comes back, if my assumption is right on this point.
Sorry for my lack of knowledge regarding this topic, but this is the first time i use jme3 (my jme2 knowledge is a bit rusty too) and LOD as well as controllers. It takes some time to understand the whole logic behind it.
Just figured it out, Controller works like a charm.
I have created a DistanceLodController which is added to the Node containing all geometries for one item (may be more than one). At DISTANCE_SIMPLIFIED the real geometries are detached from node and simplified boundary geometry is computed (only once and saved to array) and attached to node. At DISTANCE_HIDE all geometries are detached from Node which is left empty.
Great job with jme3, once you get the logic things are really easy … i’m truly impressed.
For all of you interested, here the code for my DistanceLodControl:
public class DistanceLodControl extends AbstractControl
private ArrayList<Geometry> realGeometries;
private ArrayList<Geometry> simplifiedGeometries;
private static final float DISTANCE_SIMPLIFY = 10;
Just a question about this. You say that control’s like these should be done on update() and not render(). But the BillboardControl.java in jme3 today does model rotation on render and not update. Could this create any artifacts or have any performance impact?
Btw, this culling control that dm2222 has created is a good candidate for the jme3 API imo, as it allows complete Node culling at any given distance while still having a longer view frustrum.
But at the same time I guess having many controls for every node around can have a major performance impact.
As a sidenote it strikes me that all Billboard controls for typical grass or distant LODs should share their billboard calculations. As it is now you have to create a BillboardControl for each Node that should be facing the camera, which means a lot of unnecessary calculation. If you could assume that each node used as a billboard has no rotation before, all nodes should simply get the rotation coords to face the camera. I know it wont be 100% precise as their rotation towards the viewer is a bit different based on where they are in your view for them to be facing directly you, but I doubt that would be very noticeable as they just have to face the plane of the camera. It might even look more natural as you are strafing since that wont rotate the billboards as you pass them.