javagl
commented
1 year ago Going one step further (and I know, this is a long shot): I think that splitting the geometry definition and its usage could make sense. There already are proposals for "defining geometric objects", and this is related to a comment that I left on one of these proposals.
The current proposal adds the extension object to a node. There may be a mesh attached to that node. And the extension object itself defines the collider. The collider may be again a mesh, or one of the special collider types (like shere).
For example, the following node renders a mesh:0, and uses a mesh:1 as its collider:
"nodes" : [
{
"mesh" : 0,
...
"extensions" : {
"MSFT_physics" : {
"collider" : {
...
"convex" : {
"mesh" : 1
}
}
}
},
},The mesh:1 can be imagined as an approximation of the rendered mesh. This approximation is supposed to be used for the collision detection. In this case, it is a convex hull, but for other meshes, it may be an even simpler representation, like a sphere.
(The fact that the convex refers to a mesh raises the question: How to ensure that this mesh actually is a convex hull, and not a "real", arbitrarily-shaped, complex mesh?)
Pulling out the definition of "geometric objects" would allow to define the same things that are currently supported via the colliders, but regardless of their intended usage. These "geometric objects" could then be a special "incarnation" of meshes, so to speak.
Meshes could then be defined as such "geometric objects", roughly like this:
meshes: {
extensions {
TODO_geometric_object {
sphere: {
radius: 123
}
}
}
}These "geometric/parametric meshes" could then be used for rendering and as "collider meshes" - roughly like this:
meshes: [
/* 0 : The high-detail mesh that will be rendered, as a standard glTF mesh */
/* 1 : A convex hull of mesh 0 (may also be a standard glTF mesh) */
/* 3 : A geometric object, e.g. a sphere, defined as above */
]
nodes : [
// A node that renders the high-res mesh and uses
// the convex hull as its collider
{
mesh : 0,
...
collider : { mesh : 1 }
}
// A node that renders the high-res mesh and uses
// the sphere as its collider
{
mesh : 0,
...
collider : { mesh : 2 }
}
// A node that renders the sphere (!) and also uses
// the sphere as its collider
{
mesh : 2,
...
collider : { mesh : 2 }
}
]
eoineoineoin
bhouston
aaronfranke
aidinabedi
I think that an extension that just specifies collision bodies would be useful outside of KHR_rigid_bodies (which is what I would name this proposal.)
I think that KHR_collisions can be useful for a lot of different things. Just as VR controller hits, mouse clicks on objects, and touches on objects. I also think they can be useful in KHR_behavior for detecting overlaps between objects.
I do not think we need the trigger part of this KHR_rigid_bodies, instead KHR_behavior will have overlap detection and it can act on that. I suggest not having it in trigger in this extension because it doesn't really do anything here by itself. Instead it is use using KHR_collision to trigger events.