Collider Shape Proposal

[PMZeroSkyline]

Hello!

Could you consider adding MeshShape and ConvexHullShape, and removing Collider.geometry in favor of Collider.shape? I found that replacing geometry.node and geometry.convexHull with the corresponding shapes would better support inheritance."

[aaronfranke]

This is how OMI's physics extensions work.

Collider nodes reference shapes always, and do not reference other nodes for their meshes: https://github.com/omigroup/gltf-extensions/blob/main/extensions/2.0/OMI_physics_body/README.collider.md#shape

For shapes, MeshShape (concave "trimesh" shape) and ConvexHullShape ("convex" hull shape) are available:
https://github.com/omigroup/gltf-extensions/tree/main/extensions/2.0/OMI_physics_shape#shape-types

[eoineoineoin]

Agree that it would be slightly easier to write an importer, and, in fact, the extension originally did have this organization (removed in 24e219f).

However, there were a number of issues with that approach; some fields were being redundantly specified between the mesh shapes and glTF nodes, which already had that information. There were also other users of the shapes extension with no need for those meshes, so the current structure is just more considerate of the rest of the glTF ecosystem.

Yes, it does mean a small amount of extra complexity when loading physics data, but overall, I think the additional flexibility outweighs that.

[aaronfranke]

@eoineoineoin I wouldn't say that the glTF node's "mesh" property is redundant. They're separate things. With the current construct of KHR_physics_rigid_bodies, it isn't possible to have a mesh-based shape without a visible mesh, at least as far as I can tell. I consider this a flaw, as the collision geometry and the visuals should be able to be independently controlled.

[eoineoineoin]

@eoineoineoin I wouldn't say that the glTF node's "mesh" property is redundant. They're separate things. With the current construct of KHR_physics_rigid_bodies, it isn't possible to have a mesh-based shape without a visible mesh, at least as far as I can tell. I consider this a flaw, as the collision geometry and the visuals should be able to be independently controlled.

I don't know where you got this impression, but this is completely false. There's no requirement that there's any relationship between the mesh geometry used for collision detection and for rendering; both can be controlled independently.

[aaronfranke]

@eoineoineoin That's great to hear, but I don't understand how. With the current KHR_physics_rigid_bodies, how would one make a mesh-based collider shape without showing that mesh visually in the scene?

[eoineoineoin]

@eoineoineoin That's great to hear, but I don't understand how. With the current KHR_physics_rigid_bodies, how would one make a mesh-based collider shape without showing that mesh visually in the scene?

glTF does not just display every mesh in the file. In glTF, you have to declare which meshes you wish to render. So, in order to not display a mesh, you simply don't declare that the mesh should be rendered.

{
	"asset":{
		"generator":"Khronos glTF Blender I/O v4.3.47",
		"version":"2.0"
	},
	"extensionsUsed":[ "KHR_physics_rigid_bodies" ],
	"scene":0,
	"scenes":[
		{
			"name":"Scene",
			"nodes":[ 0 ]
		}
	],
	"nodes":[
		{
			"extensions":{
				"KHR_physics_rigid_bodies":{
					"collider":{
						"geometry":{ "node":1 }
					}
				}
			},
			"name":"CubeWithACollisionMeshButNoRenderMesh"
		},
		{
			"mesh":0,
			"name":"physicsMeshDataNode"
		}
	],
	...