Feature Request - Update Collider Mesh with Joint Rig Deformations

This is hopefully the most correct forum to post this request.

Title pretty much sums it up, although to make things easier or more achievable, ignoring any weighted information regarding joint rig deformations to the mesh.

If joint-weighting information is ignored, there would be much less calculations required.

By updating the shape of the mesh collider of an object, only with the base-level information applied by joint-rig deformations, this might not be so performance-intensive.

Also possibly limiting the mesh-collider deformation to meshes of 2k polygons or less, this could also help to make the scenario much more achievable.

These limitations would not be applicable for all joint-rigged objects. And yet the idea and potentials could be really cool for a variety of use-case scenarios.

Obviously there is a lot of work being done to make the new hdrp/universal pipeline systems properly integrated... the shader graph, the visual effects graph ... possibly there isn't the time or attention to be implementing this new feature currently, and if so, not a problem. Although if possible, then yay.

 

This isn't really an easy technical problem to solve. Even Flex, nvidia's own solution, handles things like softbodies by voxelizing the mesh into particles, and even that has a lot of accuracy problems.

 

I've checked it, and physx supports deformable meshes.
https://gameworksdocs.nvidia.com/PhysX/4.0/documentation/PhysXGuide/Manual/Geometry.html

So this could be done. Yes, there will be heaps of problems.

 

Two such problems is that the mesh has to be convex and has a vertex limit of 255, the former of which is the reason they use particle voxelization for softbodies, iirc.

 

cheers for the interesting article link.

searching for links on how users have achieved this with Unity, usually shows that coding, addressing and updating the MeshRenderer is pretty essential.

perhaps if a joint-based rig deformation to a mesh is currently now possible, as it is, then the visual result of that must be based on some kind of geometry.

and so that geometry could be applied to the mesh collider.

if the geometry data is not actually 3d, when calculating the visual result of joint-based rig deformation, then possibly the visual results could be ray-traced realtime to gain a simple yet cohesive outline of the position of the changed mesh boundaries in 3d space.

 

Where does the article say any of this?

You seem to be looking at "Convex meshes" part. Deformable is further down below.

---------------

They didn't achieve it.

It is not about updating mesh renderer, it is about integrating custom collision query into physics system, which is hidden from you behind a rather thick wall. This is something you don't exactly do.

This doesn't make any sense to me.

It doesn't work this way. You use colliders to get them into physics system. Colliders use optimized data structures because otherwise testing for collisions will be SLOW.

The reason why there are no deformable mesh colliders, normally, is because deformable geometry does not really work with structures such as AABB trees well. The tree would need to be rebuilt, and that is not necessarily fast. Which is why people don't do that.

 

possibly the issue regarding deformable geometry, and realtime rebuilding of the optimised mesh collider, is what could be addressed, if this potential feature were made available.

a related post regarding blend-shapes updating the mesh collider is here ...

they use a BakeMesh() command and then assign that to sharedMesh via dot notation.

 

It will "sorta" work, it will be very slow, and deformed mesh during movement will either launch objects into stratosphere or get them stuck within its geometry. Also, inertial tensor is likely to be invalid.

@Murgilod
Bullet engine has this:

This approach does not use voxels.

 

cheers for the intelligent and informed replies.

cool video btw, even though it's a different game engine, the potential for new and engaging gameplays is enormous... next-level Mario Kart or some such.

 

Mario Cart does not use this kind of physics. In fact, it is highly likely that in any situation that involves high speed, this thing will become horribly unstable.