[Solved] A question of scale

I’m having a bit of a problem understanding a thing about floats, physics and scale.

So I had read on here that 1 unit of physics = 1 meter. Image heightmap question - #6 by normen

I had also read that floats are generally fine until you start getting into some higher numbers like 32,000: The shaking objects at very far distance from origin problem (revisited) - #4 by pspeed

Which got me to thinking about the issue of scale with objects since 32,000 at 1 meter per unit works out to a measly 32km.
Am I wrong in this thinking?
Is the way to handle this to apply physics to only 32km away from the player in any direction but scale things differently for graphics (eg. 1 unit = 2 meters or some such)?
Or just hang it all and scale even the physics differently (eg. 1 unit in physics and gui = 1 km)?

These always start as a simple question… but then if I were to ask you questions in return I think we’d rapidly find that physics is not the biggest problem.

How big is your world?

How do you plan to divide that up? (Since based on your question, it’s clearly too big for normal “load everything” approaches.)

How do you plan to break up the physics simulation for a whole huge universe/world so that it doesn’t require a super computer to run it?

I mean, the easy answer: use a physics engine that uses double instead of float… and/or recompile bullet to use double instead of float.

But I imagine you maybe haven’t thought about those other questions and they may lead to a much simpler physics question in the end.

So I’ve broken my “space” down into cubes that load depending on where the player is. So like if you’re in say zone 1, 1, 1 then zones 0,0,0 through 2,2,2 are loaded as a cube around the player. I haven’t settled on a zone size yet (I was think about 1000 so each zone is a cubic km.

I had already jumped at the issue of what I want to do is far FAR too large anyways so took inspiration from @normen 's infinite zoom class and just load stuff in nearby zones instead of all thing all the time.

My understanding of the physics engine is albeit a bit limited but I was thinking to handle physics in the same way that I handled loaded space. In chunks chunks. But in this case the area that the physics would play in covers a 3 by 3 by 3 collection of zones instead.

The reason I wanted to know the limits and should I be scaling is just so I don’t make plans that are intrinsically ridiculous.

Through the experimentation I’ve gone through so far I don’t see a way to “reset” physics locations to a certain location. So if your physics object has moved say 20km you go “Ok you. Get back to 0,0,0” and just continue the physics simulation. I’ve been able to make my graphics object stay at 0,0,0 but the physics objects move invisibly behind the scenes.

You are already loading and unloading zones so that means your game objects must be storing their own position… as doubles. (and velocity and acceleration)

When you load a physics “zone” just do the physics in local space and adjust back to world space before applying them to the game objects.

So physics will always be 0,0,0 based around the player’s zone, basically.

Hmmm. Currently I use the position of the physics object to translate the visible graphics. So if the physics object moves say 0,0,1 then the world moves 0,0,-1 leaving the ship centered.

Is there some function to restart/reload physics so it’s “recentered”? I think maybe this is where I’m confused… And probably, as you said, the real question that I was seeking.

If it were me, the physics would control the position of the game object.

The game object would control the position of the visuals.

The game objects are the only thing with a real “world position”. Everything else is relative to its own needs. The visuals may have different relativity needs than the physics does.

I think no matter what, you will have to figure out how to load and unload physics spaces, etc. if you want to simulate a big world/universe/galaxy/whatever.

Breaking up “space” is a non-trivial problem.

Ah ok. That’s somewhat what I thought might be the case or I was missing something (like normal). Thanks!

I always use bitshifting for making zones. It makes life so much simpler.

I’m somewhat sure that’s what I’m doing essentially.

If the world was 1D and if the player was in zone position 2 (bolded) like so

1, 2, 3, 4

when the reach the edge of 2 then everything shifts.

2, 3, 4, 5

Yep. And if the size of each cube was 2n the local translation would be x << bits and vice versa. The bits represent the amount of bits it takes to represent your grid size. I.e 4 bits for 16. 5 bits for 32 (2n!). Cheap and convenient.

So. If you told me your grid size was 16 and it was the 5th box along, i could do xCoord = 5 << 4; or if you said your x coord was 2232 i could say cellNo = x >> 4;