Mesh deformed by skeleton doesn't update data properly

[Seubmarine]

Godot version

3.3.2.stable

System information

Windows 10

Issue description

Describe your issue briefly.

The blue collision shape should wrap arround the hand mesh correctlly based on the armature

The MeshInstance.mesh doesn't update the data when the mesh is modified by a rig, so those three things doesn't work:

• using -col on the mesh on export in blender
• Create Trimesh Collision Sibling
• using MeshInstance.mesh data to generate a collision mesh

The generated collision shape is always a mesh that was not modified by the skeleton, so the data is incorrect from what we see in the editor

How do you expect it to work instead?

I expect the mesh data and all the mesh collision creation fonction to have the correct data based on the current pose or a new function that does give the correct data.

Or have a new function in skeleton that can generate collision or atleast give a data of the point.

Why I want it too work that way

I'm creating a shadow of the collosus clone to test how far can godot do things an would need deformable collision mesh in some way and for now I just want to generate a new colllision mesh each frame even if it's not good for performance.
But if having good deformable collision shape is possible I'll prefer that too prevent regenerating a new collision shape each frame.

Steps to reproduce

Two button are used to generate a collision shape but generate it differently, and one button to clear the generated static body.
You can also try using "Create Trimesh Collision Sibling" on the MeshInstance in the editor.

Minimal reproduction project

DeformedMeshBug.zip

[Calinou]

By default, blend shapes run on the GPU, so there's no way to communicate the information back to the CPU.

You can enable Rendering > Quality > Skinning > Force Software Skinning in the Project Settings to make blend shapes run on the CPU, but this has a performance cost when using complex skinned meshes or displaying dozens of skinned meshes at once. However, software skinning is also more reliable on mobile platforms since mobile GPUs often have trouble with hardware skinning.

[mrjustaguy]

@Calinou, what he's asking for isn't rendering related, it's physics related... also this can be closed as it's not a bug, and isn't really doable in real-time applications outside of the simplest of cases.

Trimesh collisions are static, as are all collision shapes in every engine out there., and they cannot deform with armature, not to mention that it is a VERY stupid thing to do, as it is VEERY computationally expensive and as such won't run well in real time applications even on high end hardware. This is NOT a Godot Limitation, every single engine will fail to provide what you ask because the current hardware just isn't fast enough, and consumer Silicon won't ever be that fast (other non-silicon might be, but that's many years away if we go that way, and even more to get to consumers)

What you want to do is make multiple Primitive collisions and place them to get approximately the volume that you want, and attach them to bones. That is how SotC does it, and every other game where such collisions are needed, or even better, they avoid having collisions altogether and just Fake it (however that is error prone and difficult logic so probably not a good idea, even if it's more performant if done right)

[Seubmarine]

@Calinou Well even when forcing software skinning, the mesh data still doesn't change to the visual info, surface_get_arrays() is the same as before and surface_get_blend_shape_arrays() is empty

@mrjustaguy Actually SOTC use multiple equivalent of ConcavePolygonShape matching the original model and move them with the bone, what I'm not sure is if they really deform the shape with weight or just move it relative to the bone, here's.

But even so the data doesn't change in code even when using software skinning or I don't know how to get it, imagine someone making something that can be deformed at runtime with bone and use it as a static body for the environment later, the only way for now would be to apply the deformation to blender and then making a collision with -col or inside the editor.

For now I'll try what SOTC did but only move the collision shape relative to the bone with no weight

[mrjustaguy]

well for that you'll have to export every bone separately and then attach each collision shape to their respective bones, however with the deformations, expect there to be holes as the bones move.

but still, such high poly count concave shapes for physics are a bad idea, and the collision mesh should be simplified.

[lawnjelly]

Agree with @mrjustaguy , this is not expected to work, and is not a bug. If it is something that can't be done already by attaching colliders to bones then it is a feature request and should presumably be a proposal:
https://github.com/godotengine/godot-proposals

[Seubmarine]

Even so the data even after using software skinning isn't updated properly if I were to make a level that used a rig in any way in blender and used -col to generate a collision shape for a static body the generated collider shape won't use what was used for the pose, could be usefull, not for my case but other case may need this to work.

[fire]

I would solve it with physics motors. #28909

[Seubmarine]

You only need to recalculate the collider when you're not close to it and only calculate the part you're the most closed to. Or do something like this at the 1m15 mark, you compute only the needed mesh in the boxe all I would need is the data after it was processed by the gpu(which take time because it has to travel from the gpu to the cpu) or Software skinning (which proceeds the deformation on the cpu) but still doesn't have any way to access the data even if it's processed on the cpu.