So I want to create 1:1 procedurally generated space with real scale planets(physical interactions between celestial bodies don’t matter.) For now I decided to focus on one solar system. And as expected I ran into graphical issues. This probably happens due to 32 bit floating point precision. Here are the solutions that I’ve heard about while researching this topic
World partition
Large World Coordinates
Origin shifting
Starting with the world partition. I tried it and I’m still encountering graphical issues.
That probably happens because world partitioning doesn’t actually solve floating point precision issues. I just hoped that maybe it’ll do the origin rebase automatically
Next up is Large World Coordinates. This may solve issues to some point but not on a space scale. I’m not sure but it seems that even 64 bit precision is not enough for a solar system.
And finally origin shifting. This is my personal preference but I’ve heard that this may cause issues with multiplayer games. My game is single player but I’m still not sure if it’s the best choice(and just in case maybe one day I’ll want to implement co-op). Either way I don’t really know how to use it. I can’t find button that enables it. The only button I found is Enable Multiplayer World Origin Rebasing and it doesn’t seem to change anything.
I found a way to rebase world origin. It is done by using Set World Origin Location function. However this is not a solution because world origin function accepts only 32 bit integers as input. So it’s efficient but just as Large World Coordinates only until some point. I’m out of ideas.
You cannot calculate pie to infinity. And thefore you cannot render to infinity.
Rebasing is the way to go though. If done properly it allows you apparently infinte movement.
The problem you come against is the engine’s hard limits on the original object placements.
Somehow somewhere you need that original transform. That original transform can only have a number as large as the tuple setup of the transform accepts.
One possibly way to achieve faux infinity would be to read data from images, such as that rebasing process looks at the image to determine positions within the limits, before placing them relative to the local position.
Another way to look at it is to provide Text strings with no earhtly mathematical limits that are read off an excel sheet and parsed by a custom system that deals with interpreting the string into a number the engine is capable of working with.
Naturally, reading a string of pie to the 9999 character is going to hang your sistem quite a bit - so we go again to the original point:
1:1 is impossible and will always be so because infinity is infinite.
I understand what you mean by not being able render infinity but I don’t understand your suggestions. What data should be read from images? And from what images?
Could be any data.
An image is just a way to store data. You have bites of data within the color channels which can be used to store whatever you care to, in just any way you imagine.
In a more practical fashion, I was actually thinking of it as a storage of 3d map data, where in 2d you see placement which is solved to a location on x/y and alpha color channel that solves your Z.
The only reason for it is that you just read files and get placemetn of things that can be represented so as to not store all of it in ram.
Image writing is slow. Reading is fast. That’s why it is a viable candidate to do crazy things with.
