Hello,
I have a rough LOD system working but it is very laggy when handling calculations. I was wondering if I was not using vertexbuffers as well as I can.
Here is an example of how I update one when a quad is split:
[java]
VertexBuffer vb = mesh.getBuffer(Type.Position);
Vector3f[] vs = new Vector3f[4096];
vs = Arrays.copyOfRange(asArray(qs),qs.size()-4096, qs.size());
v.addAll(Arrays.asList(vs));
verts = new Vector3f[v.size()];
v.toArray(verts);
vb.updateData(BufferUtils.createFloatBuffer(verts));
[/java]
Here the new points are found and added to a list that holds all the points. If anyone has any improvements they would be much appreciated. Thanks for the time.
Usually LOD is not implemented like this.
Lod levels are not meshes, lod levels represent a different way of connecting vertices in the same mesh.
You can have several lod levels in a JME3 mesh, but a lod level is basically an index buffer.
You can then use a LodControl that will switch levels, according to the distance of the object to the cam.
I see. How can changing the indices of a mesh create more vertices though? Wouldn’t you still have to edit the position buffer?
I could be wrong (and usually am), but I believe most LODs are predetermined and the entire vertex buffer is swapped out.
Example:
I dynamically create a terrain grid that is 30x30 vertices with associated indexes, colors, whatever is needed.
I create another LOD that is 20x20
Another that is 10x10
etc, etc
All stored in their own Buffer
Depending on the distance from the camera, I swap out the entire Buffer. since the buffers are pre-created, there is no lag.
Of course this doesn’t really help if you are using tessellation… but… /shrug
Actually… I see where @nehon is going with this. I guess you really don’t need alternate vertex buffers… just alternate index buffers. The faces are what is rendered. Heh… learn something new every day! Thanks @nehon
@t0neg0d said: Actually... I see where @nehon is going with this. I guess you really don't need alternate vertex buffers.... just alternate index buffers. The faces are what is rendered. Heh... learn something new every day! Thanks @nehonYes at least that how ogre and jme are implementing it. The actual mesh data is the finer detail lod level. Sub levels are just other sets of index buffers that connects "less" vertices. Ogre mesh convert tool has a way to compurte lod levels, and we use that in the SDK (right click on a mesh.xml and choose "Advanced JME binary convert", you'll be prompted to generate lod levels)
At some point we may add something to generate them from any mesh data
1 Like
I was trying to avoid creating multiple levels of detail at startup in favor of creating more vertices when needed. I think I will just try to work out the kinks with my code, thanks for the help.
@okelly4408 said: I was trying to avoid creating multiple levels of detail at startup in favor of creating more vertices when needed. I think I will just try to work out the kinks with my code, thanks for the help.
Have you tried pushing the the buffer creation off to a Future? Running the process in a background thread might fix the issue you are seeing.
Do all the “unreferenced” vertices not get rendered/calculated then?