KHR_physics_rigid_bodies Draft Proposal #2424
Conversation
| "extensions": { | ||
| "KHR_collision_shapes" : { | ||
| "shapes": [ | ||
| { | ||
| "mesh": { "mesh": 0 }, | ||
| "type": "mesh", | ||
| "extensions": { | ||
| "KHR_physics_rigid_bodies": { | ||
| "convexHull": true |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
|
||
| Alternatively, a geometry can be specified by supplying the `node` parameter. In this scenario, the geometry should be determined by the `mesh` properties on the referenced `node`, including any child nodes. Implementations should include any mesh deformation due to use of the `skin` or `weights` properties on the `node` or the referenced `meshes`. A `geometry` object may refer to the same `node` that the `geometry` object is attached to, or it may reference any other `node`, including nodes which are not in the scene hierarchy. | ||
|
|
||
| Collision shapes are parameterized in local space of the `node` they are associated with. If a shape is required to have an offset from the local space of the node the shape is associated with (for example a sphere _not_ centered at local origin or a rotated box,) a child node should be added with the desired offset applied, and the shape properties added to that child. |
There was a problem hiding this comment.
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.
|
Hey @eoineoineoin! I was trying to reference the |
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