Super Large Worlds

Super Large Worlds

About practically infinite worlds with chunks.
There's also a forum topic about this: http://discourse.urho3d.io/t/question-super-large-worlds/1870

The game "Space Engineers" had an Update that added practically infinite huge procedural generated worlds and they wrote about how they did that: http://blog.marekrosa.org/2014/12/space-engineers-super-large-worlds_17.html
Basically they have dynamic clusters/chunks with a variable size to group close things together and calculate physics with the cluster center as the world center to avoid floating point issues with stuff far away from the 0-position (world center).

I had a similar idea about realizing that with Urho3D (or other node based engines like Ogre), I haven't tested the idea yet though:

The game world can be divided into chunks. Each chunk could have the same size to make calculations easier. For example 1km x 1km (x 1km) depending on what should be simulated, how big the view distance can be, ...
If vertical chunk size/separation is needed depends on if the world is more 3D-ish like a space game or if everything is always "close" to a flat ground/plane.

Each chunk has its own scene node (Urho3D::Node) to group everything in there together. When the player moves through the world (he doesn't have to belong to a chunk scene node) the chunk he currently is in is moved to the 0-position of the world and other displayed chunks accordingly. So that with a chunk size of 1km x 1km the player is always between position 0,0,0 and 1000,1000,1000 if you let units equal to meters (or -500,-500,-500 and 500,500,500 if your chunks are centered or whatever).
To get a decent viewing distance the chunks around the currently centered chunk are generated/loaded as well and chunks further away unloaded to safe ressources. When the player visits a different chunk, all chunks and the player are moved and chunks loaded/unloaded/generated as needed. Practically the whole game world is shifted to keep the player and active/loaded objects near the center.
If there are important things going on like machines that should still do stuff when being far away in unloaded chunks that calculation should logically be independent from the player centered chunk loading system. They could for example be always loaded but be in a invisible and separate world/scene, physics could still be being calculated though.

To handle chunk and object positions the chunk object could have its offset as an integer that would be multiplied by the chunk size to get the real world position. With a chunk size of 1km x 1km x 1km and 32-bit integers the possible world size would be 4,294,967,296,000 meters (to the power of three). With 64-bit integer it would be 18,446,744,073,709,551,616,000 meters, that are ~1,949,822,387 light years...
Using the world position should be avoided though. Instead the chunk offset + the position of the object inside the chunk should be used. Moving objects would logically dynamically change the parent chunk (and node if loaded) and their position relative to the chunk when moving across chunk borders.

Voxel and terrain systems/engines do also use chunks to unload chunks for away or display them in lower detail. The chunk size of "Minecraft" for example is 16m x 16m (no idea about their chunk height though, the height values are 0m to 255m but I'm not sure if the chunks are vertically separated as well and are 16m x 16m x 16m or 16m x 256m x 16m).