Hello Babylon.js community! There is currently an ongoing effort to standardize how physics objects are represented in GLTF files. The more people participate in the development of these standards, and the wider the experience across game engines, the better we can ensure that the standard we end up with is as good as it can be. I would like to get both Babylon.js users and engine devs engaged in this discussion.
To start off the discussion, I’ll bring up the type of motion of a physics body. Babylon.js has this documentation page: Physics V2 core concepts | Babylon.js Documentation
There are three kinds of motion type (
PhysicsMotionType) a body can have.
Static bodies are bodies which never move.
Dynamic bodies, on the other hand, are bodies which can move. …
The final motion type is animated
In the GLTF discussion, there are two competing ideas for how to define motion:
"type"string enum set to
"type": "kinematic", or
"isKinematic"boolean set to
"type" string enum is a close match for Babylon.js’s motion types. It also works very well with Godot, Unreal, Defold, Bevy XPBD, Bevy Rapier, Hyperfy, Jolt, and more. It also has the advantage of being immediately clear what each type is.
"isKinematic" boolean is a close match for how Unity works. When set to false, the body’s motion is dynamic. With
"isKinematic", you cannot define static bodies, instead static objects need to be bare collider shapes, and there is no way to group together static colliders.
I am one of the active members of OMI group. We are working on interoperable standards, particularly with glTF, focused on providing the best data exchange portability between engines. We have our own physics extensions. Microsoft also has their own, being developed by Eoin. We have been working on converging the specs, but there are some key issues that block us from moving forward until we get wider participation. OMI is pushing for
"type", while Microsoft is pushing for
And to be clear, this is not the only issue that needs resolving. Another issue is with the definition of capsules and cylinders. OMI uses a height and a radius, but Microsoft uses a height and two radiuses for top and bottom, which allows defining a cone shape or other tapered shape. The problem is, basically no engines have that feature, so it’s not very interoperable…