You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main advantage of doing it this way is that it is trans-format, and should work equally for all formats, regardless of howe or whether they specify physics.
However, this does not play nice with model authorship tools which work with the raw formats, like blender GLB export or USD.
GLTF
On the GLTF side, there are generally two competing but compatible conventions, and I think we should support both.
The easiest win is to make sure that all 3 types of physics definition are supported for the GLB case. When we add the USDZ handler, we should also plug it into the physics engine via the existing extension.
Secondarily, we should think about supporting more than just concave and convex physics -- for example, some developers want to use animated box physics attached to an animated rig, for fast animated physics. I'm looking for feedback on what would work best for folks.
Finally, whatever we implement should be documented.
The text was updated successfully, but these errors were encountered:
Background
Webaverse uses PhysX for physics, and technically supports all collider types supported by Physx.
Currently two types are exposed as configurable
metaversefile
physics
component settings, implemented in thetotum
glb
type handler: https://github.com/webaverse/totum/blob/main/type_templates/glb.jsThe main advantage of doing it this way is that it is trans-format, and should work equally for all formats, regardless of howe or whether they specify physics.
However, this does not play nice with model authorship tools which work with the raw formats, like blender GLB export or USD.
GLTF
On the GLTF side, there are generally two competing but compatible conventions, and I think we should support both.
OMI_collider
: Add OMI_collider omigroup/gltf-extensions#63We can and should support both, with a heirarchy of:
physics
Which is roughly in order of "how inconvenient was it/how far out of the way did the user have to go to do the override".
USD
USD support landed in THREE.js r144: https://threejs.org/examples/?q=usdz#webgl_loader_usdz
And there is already a physics solution for USD: https://graphics.pixar.com/usd/release/wp_rigid_body_physics.html
There seems to be less choice here, and USD is a more entrenched format (being used as the foundation of Pixar, NVidia, and Omniverse work), so we should just follow suit and implement the extension along with the loader.
Task
The easiest win is to make sure that all 3 types of physics definition are supported for the GLB case. When we add the USDZ handler, we should also plug it into the physics engine via the existing extension.
Secondarily, we should think about supporting more than just concave and convex physics -- for example, some developers want to use animated box physics attached to an animated rig, for fast animated physics. I'm looking for feedback on what would work best for folks.
Finally, whatever we implement should be documented.
The text was updated successfully, but these errors were encountered: