So I made a script that changes the world bound in runtime but that doesn’t work (it changes the world bound in the entityDebugger but the actual world bound is still the same and objects still not collide after the passing the original world bound that I set in the inspector).
Is there an actual solution or do I just set the world bound to 9999999999?
The world bounds are set once when physics world is created. They cannot be changed later.
The way to deal with large/infinite worlds currently is to “shift” the world when your character gets close to the bounds of the world.
The bounds would be larger than the origin shift and a good place to shift the origin would be around 5,000 meters if using 1 unit = 1 meter scaling as this is inside where floating point will visually degrade. Then as above poster says, shift your world back each time.
Heads up:
Current tooltip says: “The Havok broadphase uses quantized AABBs, which requires that the world has explicit maximum extents.”
Next version of the Havok plugin will:
50,000 Units is well past float accuracy depending on unit scale. For example in Unity, if it’s 1 meter, then 10k Units will easily see things jitter regardless of physics engine used because it can’t render it stable enough.
Therefore it’s logical that these Units aren’t meters, or if they are, they still won’t be useful and you should be shifting much sooner, depending on the definition of unit.
You are right that if rendering operates in global space (vs local camera space) rendering is very bad much closer than 50,000. I don’t know much about the unity rendering pipeline and I don’t know if it works in global or camera local space.
To get to my claim about stable simulation, I just wanted to say that Havok in next release will internally operate with more than single precision at key points in the pipeline and it will provide stable simulation up to 50.000.
Rendering may cause need for world shifting much sooner than those 50k.
The built-in pipeline operates in world space. So going far from origin will create noticeable jiggles and z fighting between close polygons. HDRP on the other hand bypasses the world and does it directly in frustum space, so there is far less jiggles far away.
I’ve made a few games with origin shifting and it depends mostly on your “gameplay scale”, for example in an FPS game you’ll want to have smaller range of shifts, while in a 3rd person spaceship game you might do it much bigger. And the limit is primarily there to mitigate already mentioned rendering problems (noticeable jiggles and z-fighting), rather than physics precision problems (which I’ve never encountered).
ECS also makes origin shifting much more efficient. But I am still not sure if Havok is keeping some cached structures and if you move a lot of static colliders if that is going to have a “hidden from view” hit on performance (like it does with PhysX)
World shifting data directly in ECS will definitely case cache clearing in the Havok because on the first physics step after the shifting it will treat each body as independently teleport-ed.
If people start hitting perf bottlenecks with shifting things in ECS we may work on offering Havok api for shifting things without clearing caches.
I am curious what was the number of shifted bodies and what was roughly the perf overhead in PhysX?
I did some experimentation around rendering limitations with different renderers and different settings and here is what I found.
Neither Universal rendering pipeline nor High definition rendering pipeline work with entities when things are far away from origin. Gif below shows URP but its same for HDRP
(Game view at 10k away from origin)
On the other hand if you try HDRP in the scene with gameObjects only, and scene is (500k, 50k, 500k) away from origin rendering works like a charm (no physics included in gif below).
My assumption is that Hybrid Renderer package, which is necessary for entities to be rendered, is breaking both URP and HDRP even at 10k away from origin.
So conclusion is that stable Havok simulation far away from origin (mentioned as incoming feature in previous posts) is useful only for simulating multiplayer game on the server where clients work in a player’s local space. Outside of that use case rendering is limitation and world shift is definitely needed.
can you guys give me some ideas on how to shift the world? What do you usually do to achieve that?
@Conspiracy If you have N entities at position p1 to pn you can shift by moving every entity by the center of total mass. That brings the center of mass into the origin.
E.g. Simplified as single digits, but it works literally the same in 3D: position 1,2,3 => average (2) => 1-2=-1,2-2=0,3-2=1 => you are close to the origin from all points.
If you need to shift really huge worlds (large difference between floating point values you sum and divide or many entities), you will need to consider how to numerically stable calculate the average. In such scenarios it is usually better to do an integer based shift instead of an accurate floating point based one (e.g. median shift) as in the end all you want to do is get “closer to the origin” and not necessarily “be centered around the origin”.
World shift is usually done to ‘center’ the camera around origin. Reason for that is to reduce floating point inaccuracies in simulation. All in all you need to do in that case is to subtract some vector (e.g. current camera or character position) from the position of all other bodies and camera.