Continuation of 'Any Plans for Supporting Large Worlds'

[angrypenguin]

They’re binary numbers, not decimal. Even with that example, that’s 1mm precision, which would be plenty for many games and sims.

[neginfinity]

@Max-om

after 999 meters you get 3 decimal digits. Are your game third person. Even if you use HDRP with local camera space rendering I cant see how physics and transforms can be smooth at 8km

The numbers are binary, and “decimal” is an approximation. Also, IT is 6 to 9 decimal digits and not three, and at 999 meters you’d get at least millimeter precision, the actual would be sub-millimeter. (IIRC 1/(2^23) from 1km will give you 0.1192 mm)

At 8192 meters from origin, you’d have 1 millimeter precision (0.9766…), and that will give you a cube with with 16 kilometer edge (because it is +/- from origin). Which is 256 square kilometers. Witcher 3 is smaller than that.

[Max-om]

@neginfinity

The numbers are binary, and “decimal” is an approximation. Also, IT is 6 to 9 decimal digits and not three, and at 999 meters you’d get at least millimeter precision, the actual would be sub-millimeter. (IIRC 1/(2^23) from 1km will give you 0.1192 mm)

At 8192 meters from origin, you’d have 1 millimeter precision (0.9766…), and that will give you a cube with with 16 kilometer edge (because it is +/- from origin). Which is 256 square kilometers. Witcher 3 is smaller than that.

At 999 you get sub millimeter. At > 1000 you get millimeter (You stil get sub millimeter but without any sort of precision, thus jitter)

[stonstad]

@ShilohGames

Both of those needed a stacked camera to eliminate the flicker in the cockpit. Allspace included a VR option, and the VR cockpit jittered a lot without the stacked camera solution. With a stacked camera and the VR cockpit at the origin, there was no jitter at all.

With Disputed Space, I ran into a movement problem at one point caused by precision. I wrote my own movement controller for all of the ships, so I could get the kind of movement I wanted for that game. When I ran into a precision issue with that movement system, I rewrote some of my movement code. Basically I re-ordered the math operation so less precision would be lost. After I did that, the movement was fine even at really large distances.

@ShilohGames

I would suggest placing the ship at the origin and moving everything else around relative to that ship. That way, your humanoid animations can be run near the scene origin.

I appreciate your insight. Something that I thought was insurmountable now appears like a solvable task. Thank you!

Did you encounter any challenges moving rigid bodies? I’m thinking I have to enumerate all RBs and use MovePosition on each instead of changing a parent transform position… I’m testing this now to compare results.

*Edited. Don’t use MovePosition – that interpolates between frames.

[stonstad]

@DragonCoder

Calculate the relative difference of the two players respective origins and add that offset when you transfer across network to transpose a position from the world in one game instance to the other.

Thank you!

[ShilohGames]

@Max-om

after 999 meters you get 3 decimal digits. Are your game third person. Even if you use HDRP with local camera space rendering I cant see how physics and transforms can be smooth at 8km

Floating point has significantly more precision than you are assuming. Here is a link about single precision floating point:
https://en.wikipedia.org/wiki/Single-precision_floating-point_format

The game I am working on currently with an 8x8km map is 3rd person. At the edge of the land area in my map, I should have precision of about 1mm.

Both of the first person 3D space games I have on Steam use stacked cameras. In those, the space ship flies around in the scene, but the cockpit stays at the origin.

[ShilohGames]

@stonstad

Did you encounter any challenges moving rigid bodies? I’m thinking I have to enumerate all RBs and use MovePosition on each instead of changing a parent transform position… I’m testing this now to compare results.

Neither of my 3D space games used rigid bodies and physics to move around. I wrote a class for handling the ship movement, and the ship movement code directly adjusted the transforms for the ships.

The only time I used physics in those space games was with the asteroid field in Disputed Space. The asteroids could bounce off each other using physics. There probably was some jitter in the asteroid movement at large distances, but it was not noticeable to the player, because the player was usually focused on ships and lasers.

[Max-om]

@ShilohGames

Floating point has significantly more precision than you are assuming. Here is a link about single precision floating point:
https://en.wikipedia.org/wiki/Single-precision_floating-point_format

The game I am working on currently with an 8x8km map is 3rd person. At the edge of the land area in my map, I should have precision of about 1mm.

Both of the first person 3D space games I have on Steam use stacked cameras. In those, the space ship flies around in the scene, but the cockpit stays at the origin.

1mm precision jitter as hell. At least for my first person VR game. Might work for less precise applications

[bluescrn]

URP needs camera-relative rendering badly.

If you have a player in a moving vehicle, with a detailed dashboard, or worse, a helmet-like mesh around the camera (even smaller details, even closer) , you can run into rendering ‘wobble’ at under 2000 units from the origin.

I had an initial attempt to hack the feature into URP based on the HDRP implementation, but ran into some issues (particularly around editor rendering of selection highlights/outlines, and a fair bit of shadow-related debugging still to do) and haven’t revisited it yet.

May have to give it another try soon though, as a ‘floating origin’ by actually shifting the entire world during gameplay is a huge pain in other ways, some resolvable, some maybe not (e.g. not being able to use world-space particles/trails)

But URP is still changing too rapidly with Unity updates to make heavily-edited versions of it practical. (I’m working on projects in 2021.3, and there’e enough pain ahead updating them to 2022.2 even with unmodified URP packages… custom shaders and render features rendered incompatible, including un-updated asset store packages…)

[lmbarns]

Several years ago I had to make a VR prototype for cars that drove around a city, and generated content based on your gps position, and moved the content 1:1 with real movement to not puke using a hardware harness with gyro, accelerometer, high end gps, cellular board for internet, etc. streaming to the headset.

I never could figure out why it’d start jittering towards the end, only right now I realize we drove several miles from origin in RL in the same scene throughout the demo and that must have been the issue.

[Max-om]

@bluescrn

URP needs camera-relative rendering badly.

If you have a player in a moving vehicle, with a detailed dashboard, or worse, a helmet-like mesh around the camera (even smaller details, even closer) , you can run into rendering ‘wobble’ at under 2000 units from the origin.

I had an initial attempt to hack the feature into URP based on the HDRP implementation, but ran into some issues (particularly around editor rendering of selection highlights/outlines, and a fair bit of shadow-related debugging still to do) and haven’t revisited it yet.

May have to give it another try soon though, as a ‘floating origin’ by actually shifting the entire world during gameplay is a huge pain in other ways, some resolvable, some maybe not (e.g. not being able to use world-space particles/trails)

But URP is still changing too rapidly with Unity updates to make heavily-edited versions of it practical. (I’m working on projects in 2021.3, and there’e enough pain ahead updating them to 2022.2 even with unmodified URP packages… custom shaders and render features rendered incompatible, including un-updated asset store packages…)

It’s typically unity that one of the pipelines get a useful feature and not the other. Though if you move transforms with physics you still will end up with jitter.

[Max-om]

Anyone tried world streamer 2? It could possibly help at least for non multiplayer games

[neginfinity]

@ShilohGames

Neither of my 3D space games used rigid bodies and physics to move around. I wrote a class for handling the ship movement, and the ship movement code directly adjusted the transforms for the ships.

Bullet physics supports double precision, but in the end it is kinda too small as for a space game, double precision will limit you to solar system scale.

For a space game without trickery you’ll need quad precision floats. 16 bytes per float.
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format

You can forget about acceleration (as even CPU has no instructions for those), but that’ll give you 5900 times distance of observable universe, with 1 millimeter precision at the edges.

In the end, however, that’ll be a waste, and it’ll be easier to use sectors and simulation bubbles. As in a real world scenario you rarely ever need to calculate forces and interactions between objects positioned thousands of kilometers apart.

[ShilohGames]

@Max-om

1mm precision jitter as hell. At least for my first person VR game. Might work for less precise applications

I agree that first person VR is much more sensitive to jitter. In a VR game with a cockpit, that jitter is very easy to see. In a 3rd person camera non-VR game, 1mm precision does not cause noticeable jitter.

[Max-om]

@ShilohGames

I agree that first person VR is much more sensitive to jitter. In a VR game with a cockpit, that jitter is very easy to see. In a 3rd person camera non-VR game, 1mm precision does not cause noticeable jitter.

You don’t need a cockpit even, you can just look at your hands or items in the world.

[Ruberta]

It possible on Unity now. Look at this 1:1 scale world with physics. Zoom in and out really smooth.

Earth 2 Version 1 3D Earth Tech Demo (watch in 4K)

And yes, Earth2 use Unity. They’re hiring too. https://earth2.io/virtual-world

[AcidArrow]

@Ruberta

It possible on Unity now. Look at this 1:1 scale world with physics. Zoom in and out really smooth too.

https://www.youtube.com/watch?v=5oo1SSZKjrI

The point though when using game engines is not if it’s possible, it’s if it’s easily possible and which engine allows you to get to where you want better and faster.

Otherwise, sure, you could circumvent and re-write most of Unity’s systems and have it do things that aren’t easy now, but then, why are you using Unity?

[Max-om]

@AcidArrow

The point though when using game engines is not if it’s possible, it’s if it’s easily possible and which engine allows you to get to where you want better and faster.

Otherwise, sure, you could circumvent and re-write most of Unity’s systems and have it do things that aren’t easy now, but then, why are you using Unity?

Totally agree, workflow is always forgotten in these discussions which is interesting. Same in the nantine/lumen thread.

I have gone close to insane trying to get performant lightmapping for example. Just the fact that you still in 2020 LTS need to manually assign bake tags to meshes to get them spacially grouped on the lightmap is insane.

[ippdev]

@Max-om

Totally agree, workflow is always forgotten in these discussions which is interesting. Same in the nantine/lumen thread.

I have gone close to insane trying to get performant lightmapping for example. Just the fact that you still in 2020 LTS need to manually assign bake tags to meshes to get them spacially grouped on the lightmap is insane.

How would you program the procedural laying out of lightmaps so they were performant and fit everybody’s use case?

[ippdev]

@AcidArrow

The point though when using game engines is not if it’s possible, it’s if it’s easily possible and which engine allows you to get to where you want better and faster.

Otherwise, sure, you could circumvent and re-write most of Unity’s systems and have it do things that aren’t easy now, but then, why are you using Unity?

I use Unity because it allows me to do things the engine was not specifically written to do.