64-bit Coordinate System

How large will large be? Will it truly be 2^32 times larger than the current world or will there be some limitations

1 Like

Interested in size as well

1 Like

Hi. I’m VERY interested in this! I have a 64 bit procedural voxel planet library ( Planet with noise based shading - YouTube ) that I’ve been working on. It does LOD, Threading, Chunking, large planetary terrain and surface to space transition, all at runtime from just functions. However, I’m stuck on Direct X because there is no engine that really can do large coordinates well. I think I can even do the streaming collision for it since I have it in my old non-voxel code. However it would be nice to have the animation and all the other cool things that a real engine provides. Mind if I ask what’s the current status on this? Thanks.

1 Like

Is this Twitter post accurate?

While waiting for UE5 large world coordinates (LWC), I decided to move an entire galaxy instead of moving my character when I’m traveling in outer space. (Testing Framerates at Up to 1.44 Billion Km Per Hour [Atlantica Galaxy] - YouTube)
The only time that my character is not at or close to the original world origin (0, 0, 0) is when I’m in close proximity to a planet, moon, asteroid, or space station.
I’ve seen a lot of success with this illusion, but only in the planetary system close to the world origin. I convert vector floats into doubles and do my math in doubles, then cast my doubles back into float vectors. I’m pretty sure I’m losing a lot of precision because I have trouble trying to land on planets, at speeds less than 70 km/sec, in systems far away from the world origin. For now it’ll have to do until LWC are made available.
Another sacrifice I had to make is multiplayer features. My game has to be single player now that I’m moving the entire galaxy to give the illusion of the character moving.

2 Likes

If you store discrete/integer offsets for the galaxy’s current illusory position, you can network those offsets as components of player position, and subtract them locally for each client, rather than replicating the galaxy’s position.

In other words: Replicate the illusion, not the individual object positions.

1 Like

I was planning on storing the offsets of the galaxy’s position for each player to create that illusion for multiplayer features. I just wasn’t sure if it was going to work or not.

Aaaaand… Released! :smiley:

2 Likes

So how far from origin can we go in multiplayer now before precision issues like jittering etc happen? Can anyone test? UE5 just keeps getting better and better!

From a very quick and simple test it seems that i can move an object and still have stable physics at around 4 194 km from 0! - giving us a solid 8 000 km cube of playable space

But right after that point the objects just dissapear when clicking Play.
Rendering is also not completely fine still at that distance but that was never the problem as client side you could just use origin shifting for visuals.
The current new limit is a very big improvement in comparison to what was possible before but honestly i was thinking they could squeeze out even more than that since the jump to double precision is quite a big one.
Maybe they can improve even more with time but I’m not complaining, this is still a huge win.

■■■■, just shy of being an Earth sized volume, need 12,800km for that.

Some more testing also shows that at this distance it also gets hard to move things smoothly with logic, even tho physics seems to handle things just fine.
Maybe the Blueprint / Transform interaction part is not yet completely upgraded

Even more testing shows some promising results.
I just drove past the limit using Physics and Add Force.
If there is no trickery happening behind the scenes then I can say the physics should no longer be a problem…


Yes, that is kilometers.
After 46 746 272 km rendering gave up :smiley:

4 Likes

I just found out about Large World Coordinates!!!
Thank you Epic Games!!! This is absolutely incredible!

Perfect landing!

UE 5.0 Launched so I decided to see if they improved it even more already.

The answear?
HELL YES

At this point this is pure madness as i went beyond ridiculous distances (5 353 097 920 512 km) and the physics were still moving smoothly and rendering didn’t want to give up too!
Of course it didn’t look right but I was holding the button hoping to see it go black but it didn’t!

Although I have noticed eventually that the collision detection is not quite on point as you can see below:


I suspect it doesn’t have to be the physics side at fault here as I have seen meshes move at these distances, and i have also seen the boxes collide where there was supposed to be empty space so that leads me to believe that it is most likely the object/collider positioning giving up/ loosing precision.
The editor gave up with providing the real coordinates a long time ago so no wonder that could happen.

That would be the current state of LWC for those interested.
From what i read it is supposed to be even better once 5.1 hits where the engine WORLD_MAX variable will be set to a huge number and can change as development continues and features get more stable.

Might make another update once it gets even better :slight_smile:

2 Likes

As someone who has made their own 64bit coordinate rendering engine, I want to share my findings and explain to a few who ‘don’t see the value’ why it’s a big deal.

OpenGL and C++ all have 64bit types, and physics engines work the same, if not better, with the native data size. There is no limit on the desktop. The only reason engines hold back is to support older mobile devices with 32bit processors.

64Bit coordinates: Create Universe sized simulations right now to the nanoparticle level in a single scene, without any trickery. Currently games have to employ workarounds like shifting the entire scene to center around Zero, which causes glitches (Rust here’s looking at you).
You’ll see most “Big” games are only the size of islands, bigger ones have loading screens.

With 64bit coordinates the devs don’t have to worry and can just stream in assets at the right location without complex math or networking workarounds.

64bit processors perform better with 64bit data types. When they use 32bits they use a “Shim” driver that emulates 64bit, which takes a little extra time from the CPU. On Windows this is called WOW64.

The only current limitation we have is the Depth buffer, which supports only 32bits. It’s crazy, because it’s just just short of being able to render the earth at scale with no artifacts. A 34bit depth buffer would solve so many visual artifacts. Obviously the screen is small in pixel count, so a 64bit view matrix is overkill, but the other matrixes are very nice to have.

Uploading 64bit coords to OpenGL is easy. There are native 64bit OpenGL types, but you can also store all your transforms locally in 64bit, and multiply by a 32bit view transform matrix as the final step and render a 64bit world just fine, with negligible performance impact.

Unreal finally adding LWC is amazing. It means huge universe size games are going to spring forth with fewer glitches and fake loading screens.

64Bit also means very small sizes. Simulating quantum physics at 1:1 scale is now possible, making UnReal very attractive for scientists.

A 64bit number can comfortable contain the size of the known Universe, and comfortable define a single particle within that universe all at 1:1 scale.

3 Likes

That’s not entirely true. The graphics cards are still faster with 32-bit floating point – most of them are half speed when using 64-bit, at least for the geometry processing bits. If you’re raster bound, then presumably you’re not using 64-bit-per-component pixels, but the geometry compute cost can be hidden/pipelined. But the GPU memory usage, and bus transfer size, still matters, and can be quite measurable.

In general, the sweet spot is being able to express positions in 64 bits, but subtracting the coordinate frames of the two objects (“actor” and “camera” for example) and doing rendering in that subtracted, local, space, using 32-bit integers. Which, btw, still gives you better resolution than you can ever see a difference in screen space.

Using 64 bits for intersection testing and spin and inertia tensors and other physics simulation quantities does help with stability, though! Keeping all your physics bodies in 64 bits is reasonable, because it’s typically tiny in size, compared to graphics. The ODE physics library has always had the strength that you could define whether you wanted 32-bit or 64-bit floats when compiling, and it was stable AND fast in 64-bit mode even on PCs 20 years ago.

This hasn’t been strictly true for at least 20 years. Touching less data means dirtying fewer cache lines means running faster. Some CPUs have problems doing math on certain size data (especially the RISC ones,) but x64 is great at almost all data sizes. And packing data into SIMD registers will make processing faster, and smaller types allows you to pack more data into a single register.

2 Likes

Was 64 bit float point coordinate system implemented in the end?

UE5 uses 64-bit coordinates.