questions about world origin shifting

I’m currently evaluating UE4 for a game project, and while there’s a great deal I like the look of, the idea of using float32’s for positions is the biggest problem I see. I’m worried about whether that will make the engine unsuitable. I’ve always used 64 bit integers as fixed point positions for very large worlds; that allows high spacial precision over huge areas (literally lightyears!) with no numeric instability issues, because they are fixed point. One subtracts the WS object position from the WS camera position and creates a float on the fly for sending positions to the graphics API. No origin offseting is needed. I’m dubious about this idea of floats as positions :(.

I don’t need visibility of remote actors beyond about 30 km from a camera position, but I absolutely do need actors to exist and be actively simulated at great distances from any origin point. The maximum distance between actors might be on the order of 500km.

I’m worried about this description from the docs pages:

If ALL actors are given the same origin, then I’m going to have numeric instability issues. Consider two actors A and B which are 500km apart. If the origin is set near A, then B’s positions will be 500km from the origin, if all actors indeed get the same origin. Floats have 23 bits of mantissa, so that’s almost 6 centimeters of positional error per mantissa LSB! Given that some float CPU ops often have several bits of precision loss, I could be looking at several tens of centimeters of positional error. I’m not sure that’s going to work.

In short, I don’t see how level streaming and a position offset system will solve the large world problem for me. I see how it solves the problem of streaming in content if you don’t care about simulating distant actors. But… I hope I’m just missing something. I’ve done a lot of web searching, and read this, but mostly what’s talked about is streaming in lower LODs of static meshes, which isn’t my worry.

Anyone know or have experience about this? If the above is a problem, are there any workarounds, such as running physics in multiple batches with the origin set by hand for each batch? That seems awkward, but is it possible?

As a potentially promising sign, I found this: Set World Origin. So I figure, if I can spacially partition the actors into non-interacting subsets, each with the world origin temporary set to the geometric centroid of the subset, perhaps this can work out? I’d need to disable the game’s automatic origin setting. I can probably track the “actual” positions myself with a 64 bit integer to avoid precision loss.

One piece of the puzzle I’m missing is: can the world origin be set to several different values within a single frame? Or is it something that for whatever reason must remain the same for the duration of a frame?

I’ll attempt some local experiments, but if anyone has done this for real, that’d be great to hear too! Real world experience trumps “hold mah beer!” style API gazing :P.

I think I may be wondering the same thing as you but for different reasons. I am making a 3d Space Shoot’em up that has combinations of vertical scrolling, side scrolling and 3rd person (Like that of Star Fox series) but I want trajectories calculated out for the ships path as if it was traveling super fast building up speed over time , and as ship approaches a 500km wide asteroid the gravity would increase and change accordingly as it flies through tunneled caverns to center to destroy a base. Enemies will fly onto screen in relative speed to spaceship for game play but I would like to render real-time gravity along a specific path plotted through solar system and render that 500km asteroid in realistic relative size to distance while ship is traveling light years in minutes passing planets or through asteroid fields. When ship is flying through tunnels to get to center of asteroid I would like appropriate gravity calculated for location of ship as it gets closer to the center of asteroid while the asteroid is spinning slowly. For game simplicity Once inside the asteroid the level would be rendered and play as if asteroid was only rotating on a single axis. Hope this makes sense? Anyways, trying to think of a way to shrink objects to calculate smaller numbers for larger calculations when only 3d location is needed, no geometry just single point calculations to calculate relative size. Then in game those smaller numbers would be output to accurately render the size of planets in the background and gradually increase and decrease the size realistically relative to the size of the ship in the foreground (but planet/asteroid/whatever would actually be a smaller object closer in background but how do I calculate how large an object “should appear” for example if the camera is 5000km away from surface of a sphere 5000km in size and my “proxy” (Smaller Symbolic Planet) is .05km (5000cm) in size what should its distance be from the camera to simulate proper visual size tin game engine? I would make the planet render as an Opaque Unlit Object with a few textures with opacity masks which would then be panned over texture UV seperately to simulate cloud animations or planet surface. Level would smoothly transition from deep space, to orbit, to sky over plabet surface to massivve caverns or tunnels going to center of planet. Really hope this makes sense cause i’m having a hard time explaining this in text. If this does not make sense i could probably explain in drawings.