the large scale world is divided up into "regions". each region is a fixed sized space (basically like a big cube), and they are laid out in a giant grid. as-is, the regions are 512x512 meters (or 16384 ~1.25 inch "units").
an idea here is that a player may only see into at-most the 4 nearest regions, and anything beyond this can be saved to disk and unloaded (or reloaded again if it comes back into the visible list).
( edit/add: you don't want to aggressively load/unload though, since a player jumping around near the middle of a region would cause considerable loading/unloading, so a list with maybe 16 regions is better, but with only the nearest 4 being "active", and drive loading/unloading via minimum and maximum distances, say, force-load if distance<192 meters, and unload at between 768 and 1536 meters. likewise, if the engine has "chunks", but the unload radius may be smaller. )
within each region (apart from voxels), objects are sorted according to a dynamically build BSP-like structure.
this tree is rebuilt as objects are added/destroyed or move around.
the advantage of a tree like this is that it allows quickly answering questions like "what is the nearest X" or "is there anything in this particular area of space?", without needing to check against every object in the scene.
say, an object is running or falling, do we really want to check against every object in the scene every tick? typically not.
a tree allows quickly identifying and eliminating the vast majority of objects for which there is no chance of colliding with them.
however, this tree is not directly regarded as part of the object (in the same sense as parent/child relationships), but is more sort of a "behind the scenes" type thing, and as an object moves around, the tree might change around under it, or if it crosses a region boundary might actually jump from one BSP to another.
most entities and similar are otherwise treated as more-or-less a flat list. typically, there are not any explicit parent/child relationships, but some relationships may exist informally (for example, projectiles remember who fired them, AIs/NPCs remember who their current enemies are, ...).
during run-time, each entity may also be assigned an "ID number" used to identify it (like, over the network protocol), but this ID number is not persistent.
note though that there is not actually a single unified list of objects for the entire engine, but rather there may be around 4 of them:
the server-side scene-graph, which basically tracks all world objects (and runs all the AI, physics, ...);
the physics-engine graph, which mostly just deals with objects using fancy physics (otherwise, the physics engine is idle);
the client-side scene-graph, which basically contains whatever entities the server is telling the client about (the locally visible collection of entities, which basically holds information like each objects location/velocity/model/frame/effects/...);
the renderer's "modelstate" list, which mostly keeps track of currently-visible scene objects (this may include things like the instance of an entity's skeletal model, its current bone positions, per-frame vertex/normal and triangle-face arrays, ...).
so, for example, if an entity exists on the client, it may be given a modelstate if it is potentially visible, but may not get a full state until it is determined "actually visible" by the renderer (is uses a special visibility-determination pass, employing various checks to try to determine what is/is-not relevant to the current visible scene), and an entity wandering off-camera may well have its modelstate destroyed (the modelstate graph is thus highly volatile, and in some cases the renderer may destroy it at-will, forcing the client-end logic to rebuild it).
the reason for different lists is that they exist in different parts of the engine and deal with different information.
for example, the server-side entities contain lots of fields that have no relevance to the renderer;
and, the renderer contains lots of fields that have no relevance to AIs or physics;
and, for example, the client-side scene-graph knows a model by its model-name, and largely manages communication with the server, whereas the renderer's modelstate knows it via an instance pointer and internal (model-type specific) vtables (and non-visible objects are never given a modelstate);
well, and also because my engine is mostly broken up into multiple DLLs, and I prefer not to share structures between different libraries.
Edited by cr88192, 04 February 2013 - 03:56 PM.