Convex decomposition leads to inaccurate shape for simple meshes

[BlenderSleuth]

Godot version: 05a0a68c72cc16c443301398ab93e8d838401ac0

OS/device including version: Windows 10 x86_64

Issue description: Using the old quickhull method, when using the Mesh->Create Convex Collision Sibling, a simple scaled cube mesh would produce a perfect convex hull collision shape. Now, with the new convex decomposition, the same simple cube mesh produces an inaccurate shape: This issue is not that much of a problem for this example (only a small difference), but for more complex convex shapes it becomes a major problem.

Steps to reproduce: Import this gltf file to a godot project: cube.zip Use Mesh->Create Convex Collision Sibling(s) See that the collision shape does not line up with the mesh instance (use wireframe mode for a better look)

Minimal reproduction project: test.zip

[jitspoe]

I'm having the same problem when importing gltf meshes that have "convcolonly" on them. In 3.1, these would import correctly. In 3.2, the import alters the vertex positions slightly.

3.1: Point values are exactly the same as they are in Blender.

3.2:

Notice how the top and bottom are broken into triangles instead of being flat, and the point values are slightly off. Example: y of 0 becomes 0.094 and 0.047 (strangely halfway between 0.094 and 0.0).

Here is the glb file I'm importing. The visual mesh and collision should line up exactly:

building_construction_beams_vertical_3m.zip

[akien-mga]

I checked and the regression is fairly old, as it's already present in https://downloads.tuxfamily.org/godotengine/3.2/alpha0-unofficial/ (a34b77e271da5f3d550acfac1e5557f2467c6266).

Edit: Well that's expected, and it should even be older than 05a0a68 as per the OP.

[akien-mga]

This is likely caused by 5823b5d77d47339c3c981953ca8178e7ef14b6df, CC @reduz.

[Calinou]

I guess we should have separate import flags for the old (QuickHull-based) and new (VHACD-based) convex collision shape creation. -convcolsingleonly and -convcolmultipleonly? It's getting pretty complex at this point :slightly_frowning_face:

[jitspoe]

Nah, the algorithm should be fixed to not create bad collision with simple shapes.

[Calinou]

@jitspoe Unfortunately, VHACD is basically unmaintained and there are no alternatives we know of. This is why I think it's better to stick to QuickHull when you only need a single collision shape.

Maybe we can switch to QuickHull automatically if only one shape is generated by VHACD (and discard the VHACD-generated shape)? This would be slower, but this would avoid adding yet another import flag.

[akien-mga]

Unfortunately, VHACD is basically unmaintained and there are no alternatives we know of.

Well that doesn't mean that we can't fix VHACD ourselves :)

[jitspoe]

So it seems VHACD is for massive, complex models. Would it make sense to just have it kick in on > 200 verts or something, otherwise use the quick one we used previously? Or maybe you explicitly pick which one you want to use from the mesh menu and importing meshes with -convcolonly uses the old quick hull method (since, if you're explicitly making convex collision meshes in blender, you have probably already simplified them) and the other collision options that used to make triangle meshes instead use VHACD?

[Calinou]

Or maybe you explicitly pick which one you want to use from the mesh menu

This is now the case since Godot 3.2.1. You can now choose between creating a single convex collision shape using QuickHull or multiple convex collision shapes using VHACD.

This issue is about automated convex shape creation using import flags, so it's a different problem.

[jitspoe]

Ah, so all that remains is to make the "convcol*" mesh tags use the QuickHull and other ones use VHACD? Seems like that would be better than using triangle collision and would let people explicitly choose without adding new mesh name tags, but maybe there's an argument for still supporting triangle mesh collision?

[Calinou]

@jitspoe The other mesh tags such as -col and -colonly create trimesh collision shapes, which are slower than VHACD-generated convex shapes but more accurate. There are plenty of valid use cases for them (e.g. level geometry), so these shouldn't go away :slightly_smiling_face:

VHACD is most suited to models whose collision can't be represented by a single convex shape, but are still small enough to have accurate collisions with a handful of shapes. Handmade triangle mesh geometry will still be more accurate, even if you use the Decimate modifier in Blender or something like that.

[jitspoe]

Sort of related: I noticed that the non-VHACD method for creating a convex collision shape adds duplicate vertices: https://github.com/godotengine/godot/issues/41522

[jitspoe]

I just did a test with a simple mesh and the VHACD "simplified" collision actually generated MORE complex collision than using the mesh directly. Still in favor of using the non-VHACD collision for -convcolonly objects. (left: Direct from mesh, 36 verts. Right, VHACD, 64 verts)

boss_robot_head_collision.zip

[fire]

@lyuma had trouble with generate convex decomposition a few days ago.

[jitspoe]

Using vanilla Godot for a game jam and tried to generate collision and forgot how bad this was... should really just go back to the old QuickHull method by default in my opinion with a separate -convcoldecomponly or -convcolsimplifiedonly or something for the simplifying algorithm. It just seems too broken to be of any use right now, at least for what I've tried it for.