Great article. I was thinking about these problems years ago, while working on a game engine I never got too far with (long before Ogre existed). My idea at the time was pretty similar to that, except I was planning on having much larger nodes, but use integers for the geometry, instead of float. At one millimeter resolution, a 32-bit int spans more than 4000 kilometers. 2000 if you want to avoid overflow issues at the edges. Or 1000 kilometers if you're really paranoid.
So, my nodes were going to be potentially huge.
The world coordinates (floating point, for rendering purposes) were going to track the player by periodic steps, just like in that paper. But the idea I was working on was to batch the transformations needed... Say you're walking at 1 km per hour going East, and that there are roughly 1 million polygons to recalculate. So, I plan on recalculating 1000 polygons per frame, compute where I might be in 1000 frames at the current speed, and by the time I get there, all 1,000,000 polys' new world coordinates are calculated, and I just switch to the new world data and and place the center of the world there. Only objects that have moved will need to be recalculated on that last frame, and so, perhaps the batching should be planned for 999 frames, instead, and leave the last one for only moving things.
Another thing I struggled with was physics consideration. Physics often need previous frame data, which would be missing at the moment of a switch. The solution would be to make moving object transformations twice, on two consecutive frames, then switch to the new world coord system.
Speaking of the devil, physics suffers the same precision problem as graphics, with floating point. Even more so. So, my plan was to do physics computations based on local coordinates, where position is represented in integers, at a smaller scale, say 1024'ths of a mm. A "binarymetric micron", if I'm allowed to coin a term
One final problem with physics is that while speed is relative, acceleration isn't. Some kind of Absolute Stationary Frame of Reference is needed, if nodes are allowed to move, accelerate or rotate. This was important to me because the game I was dreaming of was a future world with planets, space stations and ships. If you're in a rotating space station, sitting at a cafe, looking out the window at the Earth, sipping capuccino, and suddenly you decide to spin a top on the table, you should see the top's axis remain parallel to... the universe I suppose..., rather than remain at the same position relative to the table. This would be true on Earth as well, but less noticeable, since you rarely find a top that can stay spinning for 24 hours. With a large, heavy pendulum you can veryfy it switches directions of swinging full circle at each 24-hour period.
This might sound like minutiae, but it isn't: If you put a station on polar orbit around the Earth, with the axis of its rotation pointing towards the Sun, it would be incorrect for its axis to remain aligned to the Sun throughout the year. The axis of rotation will remain aligned to whatever star it points to in the very far distance, ignoring the seasons.
So, while positions and velocities are relative, and we can move and rotate our world coordinates to match any stationary or moving frame of reference of convenience, the laws of inertia require that we compute accelerations, centrifugal forces and gyroscopic effects relative to some universal frame of reference that is both: positionally and rotationally stationary.
I'm just rambling, when I should be coding...
