So we’ve been working on an own Minecraft implementation with a twist, for our end year thesis. I have a terrain that is dynamically generated by a heightmap. I’ve optimized the object count using geometry batching and it’s all working quite fine.
I would like to improve the performance even more with culling of non-viewable elements of the terrain. I read about PVS (Potentially Visible Set) culling and I was wondering if this is supported in JME3 or if there is any alternative to this type of culling.
Hehehe… “Minecraft based game” ^^ I suggest just reorganizing the mesh. You dont need all the vertexes inside a mountain.
Another minecraft clone … cool 
Do you create/render a custom mesh or do you use the Box mesh?
Actually I use boxes for our minecraft clone (http://code.google.com/p/bloxel/) … but I read a lot of “box world tutorials” and I guess the end of the story is a “createMeshFromVolumeData” method with some kind of texture atlas …
Regards
Andreas
normen said:
Hehehe.. "Minecraft based game" ^^ I suggest just reorganizing the mesh. You dont need all the vertexes inside a mountain.
Right ... and you don't need the vertexes behind a big hill ... but here the thinks become a little bit more complex (with my actual knowledge) :D
Well the terrain is not one big mesh, it’s a lot of Box elements joined together with geometry batching.
And I assume that’s a “no” on the PVS culling?
Is there any other way in optimizing it other than culling?
You don’t want to build geometry from boxes… you want to build them from faces. And you only need to add the faces that border a block and a non-block.
I don’t think I’d bother with texture atlases… I think it would needlessly complicate the code and you can probably achieve good enough performance without. Mythruna does not use it and I think it performs pretty well given what I’m throwing at it.
Actual bloxel is using diet666’s approach … chunks are filled with terrain-elements (a internal class for the volume-information) …
a) at “render time” we attach a geometry (based on a box mesh) for each terrain-element in the near area to the scene graph
b) during chunk “filling/update time” we create boxes like in a) for the far area but then we using geometry factory to merge these boxes then at “render time” we a merged geometry per chunk is attached to the scene-graph
our performance is not bad … and we have a quite wide terrain our only problem at the moment is the memory … how can we store the volume data in a efficient way … and how can we create “random” filled chunks (i.e. with perlin noise)
Well, in a 10x10x10 box of blocks… the ‘naive’ approach of just rendering all of the cubes, all of the faces means you are drawing 6000 faces when only 600 are needed.
…and really, building by face has the other advantage in that its easier to batch by texture, easier to apply lighting, lots of stuff is easier.