Increase WorldBoundaryShape3D size to 8192x8192 when using Jolt

[Calinou]

• Follow-up to Document WorldBoundaryShape3D having a finite size when using Jolt Physics #101108.

Unlike GodotPhysics, WorldBoundaryShape3D has a finite size in Jolt Physics.

This increases the default size to suit most projects using single-precision builds. As per the Large world coordinates documentation, it's recommended to keep all gameplay within a 8192x8192x8192 area centered around the world origin, so the new default covers that. The precision is halved when going past every power of 2 value, which is why the new default is also a power of 2.

The size isn't currently overridden when using a double-precision build (this could be done using the double feature tag), but from what @mihe told me, Jolt doesn't use double precision in the same ways GodotPhysics does. It's only used for absolute positions, not relative coordinates such as velocity, so it needs further testing to see if huge WorldBoundaryShape3D sizes like 2^32 work correctly in double precision builds.

cc @jrouwe

[jrouwe]

I think this is a risky change. When a rigid body falls onto the world boundary shape, the collision detection algorithm will request the faces of both colliding shapes and then clip them against each other in order to get the contact manifold (of up to 4 contact points). PlaneShape::GetVertices returns vertices mHalfExtent from the origin, so the larger this value, the bigger the chance that you get round off errors during clipping. This could result in a less stable simulation or jittery behavior.

I would prefer the current lower default value.

[mihe]

When a rigid body falls onto the world boundary shape, the collision detection algorithm will request the faces of both colliding shapes and then clip them against each other in order to get the contact manifold

Ah, I was under the impression (from this discussion) that this would largely only become relevant with CharacterVirtual, but I see now that GetSupportingFace is (perhaps obvious in hindsight) called when using ECollectFacesMode::CollectFaces as well, which I guess is also used by the enhanced internal edge removal, if nothing else.

I guess it might also be worth mentioning that the plan/hope is for this limit to not be a project setting eventually, but instead a property on WorldBoundaryShape3D, once we get the ability to add server-specific properties to the physics nodes. That might help to alleviate concerns about people not discovering the project setting, if/when they do run into this limit.

[Calinou]

I made a test project with a few RigidBodies3D laying on a WorldBoundaryShape3D: test-worldboundaryshape3d.zip

Move using WASD and make the shapes jump by pressing Space.

Even if increase the shape size limit to 262144 when using Jolt Physics and move well away from the world origin (e.g. at (-33000, 0, -33000)), it still looks very stable when you make the shapes jump.

Note that regardless of the shape size limit used, the rigid bodies will momentarily penetrate the WorldBoundaryShape3D when landing then move back up slowly. This issue isn't present on GodotPhysics3D. I assume this is due to Jolt using GJK-EPA instead of an exact approach like GodotPhysics3D, but I wonder if there are any mitigations for it (e.g. on the camera side, for first-person characters).

shapes_move_back_up_slowly.mp4

It may be easier to notice the issue when watching in slow motion (right-click the video and choose a playback speed).

[mihe]

Note that regardless of the shape size limit used, the rigid bodies will momentarily penetrate the WorldBoundaryShape3D when landing then move back up slowly. This issue isn't present on GodotPhysics3D. I assume this is due to Jolt using GJK-EPA instead of an exact approach like GodotPhysics3D, but I wonder if there are any mitigations for it (e.g. on the camera side, for first-person characters).

The penetration is something that happens with Godot Physics as well, so long as you're not using CCD. You can just barely see the correction as a quick judder, as opposed to Jolt's slower correction.

That slower correction is (as I understand it) largely due to Jolt's use of Baumgarte stabilization, which makes the contact constraints a bit more "springy" to help with simulation stability. You can lessen this effect by either upping the physics/jolt_physics_3d/simulation/position_steps project setting, at the cost of performance, or by upping the physics/jolt_physics_3d/simulation/baumgarte_stabilization_factor project setting, at the cost of simulation stability.

To prevent most of the penetration in the first place, you might instead want to enable CCD on the bodies, and lower the physics/jolt_physics_3d/simulation/continuous_cd_movement_threshold project setting, since you otherwise won't actually trigger the CCD test at these kinds of low speeds.