Hi folks,
I need some inspiration 
Currently we (I and some friends) working on a another version of minecraft called BLOXEL: http://code.google.com/p/bloxel/.
Simple thinks are done, i.e. create a little plattform, put a player (first person) in the world, add new bloxel, remove existing bloxels, load, save etc.
But now we are thinking about a algorithm/datastructure for real big worlds ā¦ with mountains, canyons etc.
Is there a ābest practiceā for this?
I guess to put tausends of new Box()'s into the rootNode + physicsSpace will end in a none-playable game 
Any help would be cool
Regards
Andreas
Yeah, just adding lots of boxes with textures and physics will make your system go on its knees. Theres been lots of threads about āboxworldsā already. Basically you should combine the meshes to bigger geometries, apply physics only where you expect collision, use culling based on the view direction etc.
Hmmm ā¦ I found nothing interesting here ā¦ I tried this:
- hold the āworldā in a internal data structure (a List of TerrainElementās)
- if player moved a distance X (from last Terrain update)
- then Iām searching for all TerrainElementās around the player (I used BoundingBox.contains for each Element ā¦)
- I got a list of elements which must be real in the renderer (physics should work etc.)
- so ā¦ put some all elements from the list as ārealā Geometries in a special box-node (child of the rootnode)
- this update I do in 2 steps:
a) remove all current boxes (from last update)
b) add all new boxes
- if the player manipulates the scene (add, remove boxes) I update the internal data structure and update the terrain
This is working fine but ā¦
- I have a bad performance if players āevent horizonā is greater then 10 units (Worstcase: the user is in a hole under earth then 10x10x10 = 1000 Gemo) - I remove and attach many objects - there must be a better way to do this ?!
- if I run into the world ā¦ the level in front of my player poping up
- for āinfinity worldā I need other ideas ā¦ with this solution I canāt render big world ā¦ please help
- I think about a 2 level rendering ā¦ the boxes in the āevent horizonā can be removed/added by the user
- How can I render a āTerrainā behind the event-horizon until the end of the level/wold (this can not changed by the user)
Regards
Andreas
It seems that some of our planned features are also planned features for terraMonkey 
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:terrain#planned_features
Planned Features:
- jMonkeyPlatform terrain editor
- Support for up to 16 splat textures.
- Hydraulic erosion and procedural texture generation
- Streaming terrain (ie. āinfiniteā terrain)
- Holes: caves, cliffs
The last two we will have in our bloxel-game. Is there something to read/know/ideas to distribute code to jme3?
Regards
Andreas
http://code.google.com/p/bloxel/
See the ācontributors manualā under the āInstructionsā menu.
Isnāt there something called Hardware Instancing for this kind of mass-same-object-rendering situation?
If you want top performance in a mutable, cube-block-based environment you probably need to do something like the following:
- Create a data structure that efficiently supports large blocks of contiguous values - probably an octree or similar. This will mean that large volumes of space / earth need minimal storage and you only store the detail that you need
- Pre-load large blocks from this data structure into your graphics card for rendering (e.g. 161616 == the bottom 4 levels of the Octree?) and draw these repeatedly.
- Youāll need to track whether there are any changes to each āblockā so that you can update the geometry etc. on the graphics card on demand.
- Youāll also probably want to do pre-processing within these blocks so that you donāt need to upload geometry or draw all the interior faces etc. again the octree will help you here.