Help shape the future of physics objects in GLTF

Content creation (3dsMax, Maya, Blender, glTF)
1

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

Motion type

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": "dynamic", "type": "kinematic", or "type": "static"
  • "isKinematic" boolean set to "isKinematic": false or "isKinematic": true

The "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.

The "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 "isKinematic".

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…

1 Like
2

@eoin with whom you interacted on Github is part of the Babylon family being the one who actively worked on making Havok Web a thing.

I think it would be more efficient to keep this part of the conversation on the gltf Github as the various actors are mostly there with the beginning of the chat. The choice should be made by the group. You could nevertheless link the issues here so that other my bring their thoughts for it.

1 Like
3

@sebavan Yes, the goal here is to reach out to the Babylon community and get people to move over to the GitHub repo. You can find issues that need discussion here: Issues · eoineoineoin/glTF_Physics · GitHub

I have been reaching out to a ton of people over the last few months, but I have found that most people are not willing to leave their comfort zone (ex: forums, Discord chats, etc). It’s hard to get the discussion rolling if I open with a request for people to go to GitHub. That’s why I started the discussion without a link to GitHub. The goal isn’t to fragment the discussion.

More links:

1 Like
4

Thanks for the links, anybody will be able to hop in if they are willing to contribute.

5

Quick bump to remind people that I encourage people to get involved with this discussion.