Add a Shape3D resource that creates the collision from a Mesh

[XenokNyx]

Describe the project you are working on

A 3D game with modular pieces for building.

Describe the problem or limitation you are having in your project

Right now the easiest way to create collisions for a mesh is using MeshInstance3D -> Mesh -> Create Trimesh Static Body, but the created shape has no reference to the used mesh, so if the mesh is modified the shape will not update itself, having to remove the previous shape and creating a new one with "Create Trimesh Static Body" manually to update the collisions.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adding a Shape 3D that references the mesh and updates its collision automatically when the mesh is modified would make it easier and less tedious to work with 3D nodes.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Add a Mesh Shape 3D resource that create the collision directly from the mesh.

it could also be implemented with a new collision node that has a mesh parameter instead a shape and internally creates the shape from the mesh.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can be worked with a few lines of code but it will be used very often.

Is there a reason why this should be core and not an add-on in the asset library?

It would make working with shape more intuitive.

[Calinou]

This approach sounds interesting, but I'm not sure how much usability would improve in practice. You'd still have to create the StaticBody and CollisionShape by hand, then also specify the mesh resource by hand (which isn't directly accessible if importing a 3D scene without saving meshes to files). For most complex 3D projects, you won't be using just OBJ meshes that are directly accessible as-is.

If this is implemented, I recommend also integrating a mesh simplification property: https://github.com/godotengine/godot-proposals/issues/3603

[XenokNyx]

@Calinou A new option could be added to the mesh menu similar to "Create Trimesh Static Body" that use this MeshShape3D instead of the concave / convex shape (or even replace it since it would do a very similar thing), and with that it would be as useful as those options but with the benefit that you only have to do it once instead of every time the mesh is edited.

[fire]

@aaronfranke Does this disrupt our collision strategy?

[aaronfranke]

@fire No.

It can be worked with a few lines of code but it will be used very often.

I disagree. This feature would be used rarely. It's unusual for a mesh collider to need continual updates from the mesh. Most games will use trimesh colliders as static level geometry.

I think that this shouldn't be an engine feature, it should be an add-on in the asset library.

[XenokNyx]

@aaronfranke When a project is finished it is true that collision not usually need to be updated but when developing the only way to update the collision of a mesh is through the menu of MeshInstance3D and it becomes very tedious when testing a mesh that is being modified and I think is done often.

[SlugFiller]

Since the request mentions "tedious" and "manually", I'm getting that the desire is to save steps in the editor, not actually have the collision shape change in runtime. Am I getting this right?

I think this illuminates a more core issue with Godot's design. The engine and editor largely share functionality, and there's no "bake" phase during export. As a result, most baked resources, like collision shape triangulation, has to either be done through a manual action in the editor, or during the game's init.

So, what this might actually need is a way to run actions automatically during export.

Something like listening to changes from the Mesh only makes sense if you're actually expecting the Mesh to change at runtime.

[Hiiamwilliam]

I agree that updating the generated collision shape is annoying, but the associated PR implementation doesn't feel right. It creates two new CollisionShape Resources that have a Mesh property. However, the Mesh itself is just another Resource and doesn't have functionalities from VisualInstance3D and GeometryInstance3D, like render layer, visibility range, etc.

So I think the PR should be updated to clarify that it's supposed to be used during prototyping, as the "final product" doesn't work like a feature-complete MeshInstance3D mesh.

Either that, or work on an alternative, as I also agree this proposal seems to be doable via plugin. It could be a custom Node that inherits from MeshInstance that manages a single StaticBody with a single CollisionShape. Then, it's a matter of using the Mesh Resource.changed signal to recreate the CollisionShape.

[XenokNyx]

Since the request mentions "tedious" and "manually", I'm getting that the desire is to save steps in the editor, not actually have the collision shape change in runtime. Am I getting this right?

Yes

So, what this might actually need is a way to run actions automatically during export.

I think adding a bake phase for the collisions would add a lot of time to exporting, specially in large project. While listening to the mesh changes at runtime is not the best it should not add any cost if the Mesh doesn't change and if someone update a Mesh at runtime they probably want to update it's collision too.

But if we don't want to update at runtime maybe the listening to changes from the Mesh could be disconnected in a bake phase.