Solar system scale "world" with single precision only - proof of concept

Here is my example of full scale Earth-Mars-Pluto travel. Enjoy an Easter drive to Mars and Pluto-Charon! Spot my bad typo
Run with editor open so I could capture the performance stats (top right).

Unity 2018.4.32, Macbook Pro 16" 2020.

 

That's really neat. Can you give an overview of how it works?

What are your plans for this code? Personally I'd love to see it turn into a realistic(ish) space sim for Quest VR.

 

Thanks @JoeStrout. It works by applying an observation and two big ideas in positional computation.

The observation was that digital space represents a field of points with high density around the origin and steadily decreasing density further outward. It follows that calculations located at the origin would be more accurate than those positioned further away because their input positional variables would be less accurate.

The first big idea was if all calculations could be performed at the origin then they would be more accurate.

The second idea was the principle of Position Independence: equations of two or more positional variables form a bounded closure whose result remains valid no matter where you move the equations.

Putting all these together lead to the floating origin method and a number of other techniques. That is continuous floating origin, not the weaker “floating origin” (CFO) you find on the unity wiki and other origin-shifting approaches (e.g. Unreal). Those algorithms have almost none of the benefits of the continuous method.

As to what the plans are, I plan to break the code into smaller portions so people can pick and choose what they want, so one just CFO, intermediate and advanced floating origin, then one that extends it with other techniques, inclusion of LOD and streaming. A book series to go with is also on the cards.

I am thinking also of extending the whole space sim asset which combines everything as I go.

As for VR, I have been wanting to end up with it all implemented as a VR solution, so definitely! So much to do!

 

This is only really a problem with stock engines that have trade offs they make and open world being an edge case they don't factor it in.

For instance Unity's terrain rendering is mostly the same as every other engine custom or otherwise. Query a quad tree to get what nodes to render that are in the frustum. Nodes index into vertex/indice buffers.

Pair that with camera relative rendering like HDRP has, and that's it. No floating anything needed.

Combine that with streaming data from disk directly into memory(no serialization just raw byte loads) and then async compute buffer updates and you can handle infinite space performantly.

Physics is really it's own thing and is also less standardized in how games solve it. A generic approach that fits most would be simulate physics in it's own space and translate every frame. DOTS physics makes this very performant.

It's worth taking the time to research what is the actual good/best solution for stuff like this. Because more and more Unity is getting the tools to solve some of this well. And the surface area where you might need to roll your own to get to a good solution, might be tenable where it once wasn't.

 

Camera relative rendering *IS* Unity's floating origin solution, they just used another name. Also, computer graphics rendering has always been camera relative drawing : so "camera relative rendering" is saying "camera relative camera relative drawing": a meaningless phrase.

Floating origin was one of the outcomes of my 207 PhD. So 20 years of research and development on this subject, including a PhD is not enough time and effort? I should have taken up bricklaying!