KHR_physics_rigid_bodies Draft Proposal

[eoineoineoin]

Obsoletes #2257 - lot of iteration and discussion since initial pull request.

Known Implementations

Blender importer/exporter
Babylon.js importer
Godot importer

Sample Assets

https://github.com/eoineoineoin/glTF_Physics/tree/master/samples

[aaronfranke]

I see that this was removed from KHR_collision_shapes. Why? What are the intended users of KHR_collision_shapes that are not KHR_physics_rigid_bodies?

In OMI_physics_gravity, I am making use of convex hulls, as it is one of the allowed shape types when the type of gravity is set to shaped gravity. It seems weird to put the definition of this inside of KHR_physics_rigid_bodies when it makes more sense to use KHR_collision_shapes.

Aside from KHR_physics_rigid_bodies and OMI_physics_gravity, which extensions need the collision shape types box, sphere, capsule, cylinder, and concave mesh, but not convex hull? Basically every physics system ever supports them. If an implementation does not support convex hulls for some reason, what use does it have for boxes and spheres, which are also convex objects? Or is the concern that people may misuse convex hulls somehow?

[eoineoineoin]

KHR_collision_shapes is deliberately separated from KHR_physics_rigid_bodies to enable the geometries to be used by any number of future extensions, not necessarily limited to the domain of rigid body simulation. For example, node selection or 3D UI components, etc.

There was a concern that for these simpler use-cases, writing or importing code to generate convex hulls would be prohibitively complex. I agree that convex hulls are a necessity for rigid body simulation, which is why this property was moved to this extension. In addition, this configuration enables the rigid body specification to describe convex hulls of future shape types such as signed distance fields.

[aaronfranke]

This needs clarification. With the latest update where "geometry" references a node with a mesh on it, there are two nodes associated with a shape: the node a shape is defined on, and a node referenced by it. The language of "associated with" is too ambiguous.

[j9liu]

Hey @eoineoineoin! I was trying to reference the KHR_implicit_shapes extension schema, but it looks like it's not included in this PR (despite this commit message). Did you shift the changes to a separate PR that I missed?

[aaronfranke]

@j9liu #2370

[javagl]

Minor: Table formatting broken

[aaronfranke]

This diagram is incomplete, it shows node -> geometry -> shape, but it excludes how physics nodes can have mesh-based geometry by pointing to another node (node -> geometry -> node -> mesh), which, by the way, is a construction I am against, since node -> geometry -> mesh would be much better.

[Igor-dvr]

Is this extension going to be ratified this year?
I see there is similar OMI proposal. Do we have a consensus on the specs?
What do we need to move forward?

[eoineoineoin]

Is this extension going to be ratified this year? I see there is similar OMI proposal. Do we have a consensus on the specs? What do we need to move forward?

Yes, the plan is to ratify this extension. I can't speak for the OMI group directly, but the OMI physics spec started life as a very Godot-specific extension; over time, they've taken concepts from this extension and incorporated them so the two now have significant overlap. I believe they're maintaining their extension to perform some experiments, though don't know any details.

In terms of moving forward, any assistance you might provide reviewing the documentation, clarifying wording, etc. would be helpful. Even better, if you were to make an implementation importer/exporter, that would help validate any tricky parts with specific software.

[Shinmera]

I've been using this extension for well over a year now to export from blender into my own engine. It works really well for my needs!

[Igor-dvr]

The extension should support global gravity? Or support can be added as a separate extension.

It would be nice to see deformable body extension too.

[aaronfranke]

@Igor-dvr For gravity, take a look at this extension: https://github.com/omigroup/gltf-extensions/tree/main/extensions/2.0/OMI_physics_gravity (may be "rebased" on top of KHR physics later).

For OMI_physics_body vs KHR_physics_rigid_bodies, the OMI extension continues to exist for 2 reasons:

• It contains the currently preferred structure as determined by the consensus of OMI group, which is similar to this extension, but different in a few important ways (I can elaborate if needed) including things we'd like to see change in KHR physics. OMI can point to our extension and say "we think it should be done this way".

• It provides a stable base for us to build on for other extensions such as vehicles, which will likely end up being "rebased" onto KHR physics in the future, after the spec becomes frozen and ratified. Both OMI and KHR physics have evolved with breaking changes, even over the last year, so for now it's beneficial to keep this as an "internal dependency".

[Derpius]

I'm planning on supporting this extension in a game engine I'm working on (rather than creating another competing standard...), so I thought I'd comment some of the concerns/suggestions I have with the structure

Re. the comments on moving collision geometry to exclusively use the shapes extension, I appreciate that it may not be exactly what the extension is designed for. It doesn't seem too much of a stretch to extend it to cover convex hulls, but concave meshes (deformed or otherwise) feel less of a fit

⬆️ Splitting out convex hulls as a new shape type would let you reference a position buffer directly, without any redundant vertex data or indices

[Derpius]

This allows multiple limits on the same axis on the same joint, which is not something that I'm aware of in any existing physics engines. There are two interpretations I can think of:

• Each limit on an axis is combined such that overlapping limits are merged, and non-overlapping limits are preserved
  • Multiple limit ranges are not supported by (at minimum) PhysX, but in theory make sense if you directly move or rotate one of the bodies such that it's in the second limit (or have sufficient damping)
• All limits on an axis are combined regardless of whether they overlap or not, such that the resulting limit is [min(mins...), max(maxs...)]

The latter seems more sensible to me, but the behaviour should be clarified in the spec either way.

For integrating with physics engines, I think ideally it wouldn't be possible to define multiple potentially conflicting limits for a given axis. This could look something like:

{
  "limits": {
    "linearX": { ... },
    "linearY": { ... },
    "angularX": null
  }
}

Not particularly elegant, but avoids this edge case altogether. If size is a concern, the limits could be made another root-level object referenced by index from those properties

[Derpius]

I think additional clarification would be useful here, that the presence of nodes requires that both geometry and collisionFilter are omitted from the trigger. It's obvious from the JSON schema below, but the readme for the spec leaves it ambiguous

[Derpius]

I have a few concerns with this approach:

• There are two very different ways in which collision geometry is specified: via shapes and via nodes
• Convex/concave meshes are referenced via the visual mesh of a node, when in most if not all cases separate lower fidelity collision meshes are used (if meshes are used at all), which isn't used for rendering
• Referencing the node requires applying skeletal deformation and morph targets per the spec, something which would otherwise only be done* as part of the rendering pipeline

*Or at least, I'm not aware of any existing usage of this outside of Blender. For games, as above you would most likely be using a lower fidelity collision mesh made of several independent solids (implicit shapes, convexes or otherwise). These would then be parented to the bone nodes, ensuring alignment with the visual mesh

If this is must-have functionality, then going through the shape object would let you separate out types for convex-hull, mesh and deformed-mesh, making it easier to explicitly not support deformed meshes rather than importing assets half-broken. The latter would preferably also not reference a node, but the skeleton and weights directly (to avoid rendering collision meshes)

[Derpius]

nit: This is redundant for most shape types. Moving mesh colliders to new shape types (per my other comment) would allow removing this flag from the geometry, instead adding it to only the shape types where it matters

In fact, that completely removes the need for the geometry object to exist (which is nice, given shape and geometry are not the most distinct names)