Infinit World - I need some inspiration

Hi folks,



I need some inspiration :smiley:



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 :wink:



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:


  1. hold the “world” in a internal data structure (a List of TerrainElement’s)
  2. 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.)
  1. 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
  1. if the player manipulates the scene (add, remove boxes) I update the internal data structure and update the terrain



    This is working fine but …


  2. 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 ?!
  3. if I run into the world … the level in front of my player poping up :frowning:
  4. for “infinity world” I need other ideas … with this solution I can’t render big world … please help :smiley:
  • 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 :smiley:



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:


  1. 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
  2. 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.
  3. 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.
  4. 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.