@SebHillaire Thanks for the response!
Well, I have no need for small planets, I want them big. My point was just that I didn’t understand how they can be big, without rebasing, without losing precision either on surface or in space. Actually, anywhere. And I still don’t really understand it. If I have an Earth-sized planet without supporting rebasing; in the best case, my planet must be at world 0,0,0, meaning that a rock on the surface of the planet must be placed on ±6.371.000.000 units, which is a lot more than 2^32. The entire surface will be deformed and stuff would be bouncing around. As far as I understand, when using floats, if the number is high, then fewer decimals will be available. Which means that any math relative to the planet center will lose a lot of precision.
I am doing this math myself using doubles now, which keeps the precision, and then convert it to vectors basically relative to the player instead of the planet center, and then converting it to float. This works perfectly, because a rock on the surface will always have a translation of less than 400.000 units relative to world origin when it’s within 400.000 units of me. But if I can’t rebase the world origin, this approach is completely useless.
And what if I want to fly to the moon? That’s another 40.000.000.000 units.That should obviously be split up in some way, but with rebasing it’s actually possible.
Rebasing really needs to be supported for this atmosphere to be usable as an actual atmosphere. Without rebasing, this component is just **either **a Sky seen from a small area of the ground, or an Atmosphere on a planet you can’t orbit.
As for the flickering:
I do everything in C++. At every tick, I check if the player has moved more than 400.000 units, simply by checking if any of x/y/z of actorLocation is more than 400.000. If it is, I say
world->SetNewWorldOrigin(actorLocation + oldOrigin);
When doing this, the SkyAtmosphere teleports negative that direction. Or rather, everything else moves based on the rebased location, and the atmosphere stays still. That’s the issue, because it doesn’t support rebasing.
So to counter-act this, I am physically moving the atmosphere component the same amount.
I am using the
, so in the same tick as I rebase the world, I say
, where this offset is its previous translation plus the vector difference between the old origin and the new origin. Or something like that.
The atmosphere appears to be flickering because I’m moving extremely fast, and I update actorLocation of the atmosphere every time I move more than 400.000 units, which can be several times a second (less than once per tick) when moving this fast.
Mathematically, I’m updating the actorLocation of the atmosphere correctly, so it shouldn’t be flickering. It should be moved to the correct location every time. But because these are extreme distances, the atmosphere is translated to approximately what I calculate, because of floating points having such low precision at these values.
Again, I think rebasing is the only thing that will make this work.