15-05-2023, 10:00 AM
(This post was last modified: 15-05-2023, 10:07 AM by josemendez.)
Just my two cents:
I guess you're hoping to use ObiCloth for a virtual try-on/cloth fitting sort of app. Using MeshColliders for this is fundamentally wrong, for a few reasons:
- MeshColliders are designed for meshes that don't deform: there's a preprocessing step that inserts all mesh triangles into a spatial partitioning structure (a bounding volume hierarchy, or BVH for sort). This allows for fast collision queries after the BVH is built, but every time the mesh has its vertices moved around, the structure needs to be rebuilt from the ground up which negates any performance benefits.
- Concave MeshColliders are a lot less robust than convex ones, the reason being that you can easily tell if a point is inside a convex polytope, but it's extremely expensive to determine if a point is inside a concave one. As a result, convex MeshColliders are "solid" (any object that's completely inside of them is considered to be colliding) but concave ones are "hollow" (any object that's completely inside of them, is considered to not be colliding since it doesn't intersect the collider's surface).
- Continuous collision detection doesn't work, since mesh vertices are essentially "teleported" to a new position every time the mesh changes: there's no velocity information about how the mesh is deforming.
For these reasons, updating MeshColliders so that they match an animated character body is extremely slow -its internal acceleration structure needs to be rebuilt from scratch every frame- and extremely brittle -no continuous collision detection is possible, and objects are only considered to collide against it if they intersect the surface-
There's another option that's better in every way: decomposing your character's body in independent rigid parts (one per bone/joint), and using a distance field collider for each one:
- It's orders of magnitude faster, since there's no need to update collision geometry at runtime
- It's a lot more robust: distance fields are always solid so if any cloth particle gets completely inside of them, it will be projected back outside 100% of the time.
- It's compatible with continuous collision detection, since each body part has its own linear/angular velocity vectors if used with kinematic rigidbodies.
kind regards,
I guess you're hoping to use ObiCloth for a virtual try-on/cloth fitting sort of app. Using MeshColliders for this is fundamentally wrong, for a few reasons:
- MeshColliders are designed for meshes that don't deform: there's a preprocessing step that inserts all mesh triangles into a spatial partitioning structure (a bounding volume hierarchy, or BVH for sort). This allows for fast collision queries after the BVH is built, but every time the mesh has its vertices moved around, the structure needs to be rebuilt from the ground up which negates any performance benefits.
- Concave MeshColliders are a lot less robust than convex ones, the reason being that you can easily tell if a point is inside a convex polytope, but it's extremely expensive to determine if a point is inside a concave one. As a result, convex MeshColliders are "solid" (any object that's completely inside of them is considered to be colliding) but concave ones are "hollow" (any object that's completely inside of them, is considered to not be colliding since it doesn't intersect the collider's surface).
- Continuous collision detection doesn't work, since mesh vertices are essentially "teleported" to a new position every time the mesh changes: there's no velocity information about how the mesh is deforming.
For these reasons, updating MeshColliders so that they match an animated character body is extremely slow -its internal acceleration structure needs to be rebuilt from scratch every frame- and extremely brittle -no continuous collision detection is possible, and objects are only considered to collide against it if they intersect the surface-
There's another option that's better in every way: decomposing your character's body in independent rigid parts (one per bone/joint), and using a distance field collider for each one:
- It's orders of magnitude faster, since there's no need to update collision geometry at runtime
- It's a lot more robust: distance fields are always solid so if any cloth particle gets completely inside of them, it will be projected back outside 100% of the time.
- It's compatible with continuous collision detection, since each body part has its own linear/angular velocity vectors if used with kinematic rigidbodies.
kind regards,