I'm attempting to represent a procedurally generated world in a scene graph, specifically in the Jmonkey engine (Jme3). To make this managable I have broken up the world into smaller chunks. Each chunk consists of a triangle mesh of the relevant piece of terrain. (A Geometry object holding the mesh and the relevant texture.)

I can't find any information however on which way is best to represent these within a scene graph, specifically how to deal with the coordinates of the map & camera.

One way of doing it would be to simply add these pieces on their world coordinate (which could get extremely large) detaching any nodes that are not within range of the camera and moving the camera trough this theoretically-infinite space. This would be very convenient but can the scene graph deal with the currently rendered scene having very large coordinates? The translations on each piece could easily go into the millions or more "distance units" on the graph's axis.

Another method that comes to mind is converting the world coordinates to a smaller local space and move the terrain that is being rendered to stay close to the origin of the scene graph. Essentially moving the world around the camera.Possibly moving the whole structure along with the camera 1 chunk in the opposite direction to keep it centred whenever a chunk border is crossed. However this seems like it could also have a large impact on performance.

Which of these options, or possibly a completely different one, would be preferable to represent the world in terms of CPU/GPU usage?


2 Answers 2


You can easily have coordinates going into the millions on units with an int. You can go all the way up to 2,147,483,647 units in the positive or negative direction. Procedurally generated worlds are not actually infinite. They're just very very big. If you think that 2 billion isn't enough, use a long to store your chunk coordinates, then you can go up to 9.223372e+18 units. So, if your units were meters it would take a character 974.9 years to reach the bounds of your world traveling at the speed of light.

The scene graph can deal with longs no problem. You still want to limit the bounds of your scene to only the chunks within the area around your camera.

It's worth noting that using a float will make you loose accuracy at large distances, which can cause some funky issues. However, you can still make pretty large worlds with floats. But if you can stick with integer values (which I assume you can, since you're choosing the chunk size), do it.

See this question for a similar issue.

  • \$\begingroup\$ Ah thanks. I'm aware of the limitations of each data type, it's good to know that I can go with the easiest option for this rendering. In any case, even if a single distance unit is only.. 10 cm or something similar in the game world an int will easily store enough for a massive world. \$\endgroup\$
    – Feone
    Apr 11, 2013 at 12:42
  • \$\begingroup\$ You're unlikely to be able to do all your calculations in int's though. Make sure you use camera local space to avoid floating point issues ;) also, spatially partition to reduce culling load. \$\endgroup\$
    – Matt D
    Sep 2, 2013 at 2:11

One solution would be to move the center of your scene, which would require to move back your chunk once you change the center.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .