Add new external 3D scene import hints to allow for better collision shape generation

[darkerbit]

Describe the project you are working on

This problem applies to multiple of my projects, and is generally a problem when importing external 3D scenes as physics objects.

Describe the problem or limitation you are having in your project

The existing 3D scene importer uses import hints to create both the collision shape AND the PhysicsBody node simultaneously. Collision shape creation can be done either from the visual mesh, or another collision mesh, and it can create either a StaticBody or a RigidBody node in the resulting node tree. This approach has a few flaws:

1. There is no import hint to generate a RigidBody node with a separate collision mesh. A collision mesh can be deconstructed from the visual mesh using 3.2's new convex decomposition algorithm, but there is no option to do this for a non-visual mesh. This flaw is outlined in the table below. Bizarrely, there was a Pull Request (godotengine/godot#8435) that was merged for a -rigidonly import hint, but the code that was merged seems to have disappeared.
2. Multiple collision shapes for the same physics body is impossible with this approach.
3. There exist no import hints for generating a KinematicBody node.
4. This approach flattens sets of multiple options into one option each, making it more difficult to expand in the future.

Table illustrating problem 1

-	Creates collision from visual mesh	Creates collision from separate invisible collision mesh
Creates StaticBody Node	-col/-convcol	-colonly/-convcolonly
Creates RigidBody Node	-rigid	No equivalent

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

I propose that the functionality for creating a PhysicsBody node and the functionality for generating a collision shape be separated into different sets of import hints. This way, the 3D artist and game developer are free to organize their node structure in whatever way they see fit, and can produce all permutations of physics body and collision shape generation.

The existing import hints should also be kept for backwards compatibility.

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

Here is a list of my proposed new import hints with descriptions.

1. -staticbody, -kinematicbody and -rigidbody: Creates a Static-, Kinematic or RigidBody node, with the imported scene's node's visual mesh as a child of that node.
2. -staticonly, -kinematiconly and -rigidonly: Only creates the corresponding PhysicsBody node, discards imported node's mesh.
3. -colnode: Generates a concave CollisionShape node from the imported node's visual mesh, and also keeps the visual mesh. Only usable with StaticBodies.
4. -colnodeonly: Generates a concave CollisionShape from the imported node's mesh, and discards the visual mesh. Only usable with StaticBodies. Works with objects with no visual data, like Blender's Empties.
5. -convnode: Generates a convex CollisionShape from the imported node's visual mesh, and also keeps the visual mesh. Works with all PhysicsBodies.
6. -convnodeonly: Generates a convex CollisionShape from the imported node's visual mesh, and discards the visual mesh. Works with all PhysicsBodies. Works with objects with no visual data, like Blender's Empties.

This allows for many kinds of scene structures to be brought into Godot as-is. Here are a few common setups:

A simple physics object with just one mesh

The 3D artist has setup a GLTF scene as follows:

• Ball-rigidonly
• • BallMesh-convnode

With my proposal, this setup would be imported as:

• Ball (RigidBody)
• • BallMeshMesh (MeshInstance)
• • BallMeshShape (CollisionShape, created with Convex Decomposition from BallMesh-convnode)

This example also illustrates what happens on a name conflict if an import hint generates multiple nodes. The game developer should not rely on the specifics on name suffixes or conflict resolution, and instead use explicit separation as in the FPS character example below.

A simple physics object with separate collision mesh

The 3D artist has setup a GLTF scene as follows:

• Ball-rigidbody
• • BallCol-convnodeonly

With my proposal, this setup would be imported as:

• Ball (RigidBody)
• • BallMesh (MeshInstance)
• • BallCol (CollisionShape, created with Convex Decomposition from BallCol-convnodeonly)

An FPS character with a collision mesh and optional visual mesh that can be turned off

The 3D artist has setup a GLTF scene as follows:

• Character-kinematiconly
• • CharacterVisual
• • CharacterCol-convnodeonly

With my proposal, this setup would be imported as:

• Character (KinematicBody)
• • CharacterVisual (MeshInstance, not affected by my proposal)
• • CharacterCol (CollisionShape)

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

Some individual usecases can be worked around with editor scripts, however these usually end up being the same across projects and really just indicate a flaw of the existing system.

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

The problems I mentioned are flaws of the main 3D scene importer itself. I believe that these issues should be fixed directly, rather than via external add-ons.

[Calinou]

I doubt this proposal will be implemented, as https://github.com/godotengine/godot/pull/39105 already implemented additional import hints but they were ultimately rejected: https://github.com/godotengine/godot/pull/39105#issuecomment-753481845

[Shatur]

Also similar thing was suggested in #542.