I am using JME3 for robotic simulation visualizations and i am in need of some point cloud visualization. i am receiving the point cloud from a 3d laser scanner and have been trying to find the best way to visualize the data in real time. My first approach was to simply add each 3d point as a vertex in a mesh and display it as point sprites. this worked well for speed, but not very well for trying to visualize what the scan is actually seeing. My next approach was to use a TerrainQuad. This approach gave me very good solid surfaces for my visuals, but does not allow for overhangs. My final approach i am working on now involves a simple voxel implementation, this gives me good solid surfaces and great visuals, but i am running into speed issues in displaying so many voxels at once since each box was a node in itself. I am now looking into using BatchNodes, but the batch process takes a little to much time for me to be running that with the addition of each new scan. I can easily display 400,000 boxes in real time once they are batched, but the batch process itself does not allow this to be my final answer. Does anyone have any suggestions for displaying a dynamic world where new points would be being added and removed at a very high rate. I can easily display 400,000 boxes in real time once they are batched, but the batch process itself does not allow this to be my final answer.
Whatever you do, you will be manipulating meshes directly. I wouldn’t go through the “node per box” route. Also, you probably want to treat it more like a box world in only rendering visible faces, etc… Presuming you are doing the voxels on a grid.
Beyond that, I suggest partitioning the world in some way to minimize what has to be regenerated every time.
Batch only like 1k together in multiple parts. Update the changed parts.
Alternaticly use point mesh with very large points, and use a custom shader that does a perspective correction on a rendered surface in it.
You could try to find out why the batching process is taking too long.
E.g. how the number of voxels affects batching - is it O(n²) or better?
Or profile the thing and see what the tight inner loop is.
For processes that take minutes or longer, I use “shotgun debugging”: run the code, click on “suspend”, inspect the stack. Resume and repeat a few times - that’s the “shotgun” part of the technique. See what stack frames come up most of the time, that’s the ones that get called too often.
You should look at the cubes project for inspiration.
@toolforger said: You could try to find out why the batching process is taking too long.E.g. how the number of voxels affects batching - is it O(n²) or better?
Or profile the thing and see what the tight inner loop is.
For processes that take minutes or longer, I use “shotgun debugging”: run the code, click on “suspend”, inspect the stack. Resume and repeat a few times - that’s the “shotgun” part of the technique. See what stack frames come up most of the time, that’s the ones that get called too often.
Rather than manual random sampling why not just use the profiler built into the SDK/netbeans?
I don’t know whether the netbeans profile records stack traces. If it doesn’t (most profilers don’t unless you explicitly request it and accept the performance hit), then shotgun profiling will give you better clues about why that function was called so often.
at the moment the best approach that is working for me is pre batching 400,000 geometrys in a SimpleBatchNode and using those as needed. this takes about 10 seconds to do the initial batch, witch is acceptable, but I would prefer a way to batch/ create geometrys on the fly so i do not have a limit on my node count. Another idea on how to remove the geometry limit is once i start getting close to the end of my geometry que, i start a thread that batches another couple hundred thousand new geometrys to use.