Hello,
Many of you are aware that if you have objects that start to get 5000,10000,20000,40000+ distance away from each other, it renders with a bit of a jitter to simulate it. Far away this jitter is not terrible, but close up when you’re trying to aim at a target, it ruins the game completely.
It is okay to have an enemy 2,000,000 units away, but the player cannot be.
I believe that the standard way of doing this is anytime the player is offset 5000 in any direction from 0,0,0 then you make the x,y,z the ‘shifted origin’ and add it to the true origin.
This shifted origin, in theory, then is immediately subtracted from the position of all known gameobjects and entities game. I have a weird feeling this may bust some things currently undergoing collision, but I am not sure.
When spawning new enemies, they need to be spawned in a new way: True origin space, or relative to player space.
Cross link in case of comments getting good in either: Best practices to refactor 32bit space into 64bit space? 5000m limitations of super massive space games. I'd like both a GameObject and DOTS/ECS solution. Is my simple solution correct? : Unity3D
There are only two solutions to this, no, make that three. Damn, nobody expects the spanish inquisition. 
- Recentering as described.
- Keeping the player centered, make everything else move in the inverse direction (this is bad for performance if there are many objects to move).
- Treat new areas as separate scenes with a loading screen. Ingame these could be portals or activating some kind of hyperdrive.
Usually you‘d use 1 and make it so that the recentering only occurs in safe situations, ie when the player enters the atmosphere of a planet or enters a portal.
Oh, there‘s a fourth one: scale everything down.
In any way, you‘d first have to be able to get to that 2 mio units away location. This isn‘t normally happening as it would take ages in most games. Even space games are cheating because you can get into orbit of a planet but not travel between planets seemlessly, ie without activating a hyperdrive of some kind which is essentially a loading screen. And if player can stop at any time you‘d just drop him in a bubble of space with nearby planets being billboards scaled accordingly to distance but you couldn‘t actually travel there with regular sublightspeed drive.
Thank you Codesmile for affirmation confirmation. I will continue to do #1 and then sell it on the asset store called like ‘64bit+ Shifter’ for Iike 9.99 if they ever let me sell anything ever… I have already scaled stuff down by 1/100, and still a singlezone of a small planet of Mars with moons Phobos and Deimos triggers the jitter. I considered being a lazy butt and not having full sized systems but even small planets are too big for a one zone, so I need a solution.
Star Citizen, Kerbal, and other big space games all have to rewrite game internals, StarCitizen runs on a 64 bit engine.
This is a common problem everyone encounters. My software engineering skills normally writes code beyond industry acceptable professionalism. So I guess I could put my back into this one, do it right for ENTITIES/GAMEOBJECTS together, throw in some spawn/networking adjustments, thoroughly debug ‘shifts’ during collision… And then no one with 10 bucks will encounter this issue ever again.
Okay, I know my next job for the next estimated 2-3 days.
Thank you again. I look forward to improving Unity as I improve my code base as well. I should be doing youtube how to videos n stuff.
,Jim
Wuuut, do you have Mars “to scale” in your app? 
Okay I read the reddit thread. Pretty hefty.
So, Star Citizen had a dev budget of i don’t know how many gazillions. Kerbal on the other hand was a very slow moving game with very little moving entities so you could fake a lot.
Anyway, what you could try to go for 64-bit is to handle all transforms internally as double values and only apply them to the Transform component every frame. That could reduce jitter but would be a serious undertaking.
I also find the “two cameras” approach workable but I would rather say you need “two worlds”. That is, one local space where everything is in that’s maybe 5000 units in diameter. Everything beyond that gets shifted to the other (outer) world that uses a different scale, so what is 5000 units away and is still big enough to be seen (ie planets) would then be in a different world at position 5 or so but scaled accordingly. Not sure if it’s possible to make this seemless but you really only need this for gigantic moon-sized objects, everything else isn’t seen anymore at this distance and probably doesn’t need to be computed either.
The inner world is your local bubble of space where everything stays close to the origin and gets shifted when leaving a cell.
Just an idea, not sure if it’ll work and what issues could occur or how to implement it.