Animated 3D collision objects from blender

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By killerpixler

I’ve managed to successfully import a simple 3D model from blender 2.8 via the better collada exporter into Godot as per the docs.

Animations are there and play properly, moving both the bones and mesh. However I will want to have simplified collision meshes for specific parts of the character (think hurtboxes kinda thing) that of course will need to be deformed with the bones as the characters arms, legs, etc. move. I made those simple meshes and for testing purposes just bound the full collision mesh to a single bone. It moves with the bone movement and rotation when I play the various animations in blender, but not in Godot.

Setup in blender:

→ Player (Armature object)
—> chest_hurtbox-colonly
—> player_mesh

The colonly marked mesh has the armature modifier on it, as does the player_mesh.

When opening the scnene in Godot I get the following node tree:

Scene Root (Spatial)
→ Animation Player
→ Player (Spatial)
→ Skeleton
—> chest_hurtbox (static body)
----> shape (Collision shape, concave)
—> player_mesh (mesh instance)

As I mentioned the mesh animates but the collision does not. I tried changing the static body parent of the collision object to a kinematic body but the animation will still not move the collision box around.

Thoughts?

I don’t think that collision detection from blender & godot collision engine resources are interchangable (maybe meshes as collision shapes). So for your player you want to have a kinematic body parent with collision shape child. Static bodies are meant to be static, so I think you shouldn’t use them for player. I haven’t yet confronted a problem like this (I usually use one capsule shape for a player), but if you want every part of the body to have separate movable collision object (like in fifa games) e.g. lower arm one capsule, upper arm one capsule, body one capsule, you could try adding multiple collision shapes and binding them to location of wanted bones, so they move when the bones move. Not sure if it will work though, never tried it. According to this answer/question you can have multiple collision meshes, so it could work.

gmaps | 2019-09-04 12:29

Godot imports them as static bodies from the DAE file. Interesting solution with binding primitives to individual bones. Do you mean doing that in the GD script? Since that is exactly what I did in blender. A collision mesh is bound to a bone there and moves with it but the imported collision shape in godot does not follow the moving bone.

killerpixler | 2019-09-04 17:29

Hi.
I haven’t used collision export meshes from blender, but did try setting up a collision shape that follows the shape of the player as they move. In the end I used a solution similar to gmaps suggestion, with different shapes collision shapes added to the collision area (you can have multiple collision shapes), and I kept their positions using code to keep them bound to the position of the relevant bones.
It took a while to set up, but it seemed to work well in the end, I have a copy of a small project on my laptop that I can link to if you want to see the scene setup/script.

DamonR | 2019-09-04 19:28

Thanks but I think get the idea. The question was really more about whether or not there was an issue with the blender export / godot import where the imported collision shapes that were bound to the bones in blender were not in godot. From what it sounds like, having custom collision shapes deform with bones is not (currently) possible. Setting the loc/rot/scale of a custom collision shape via code is an ok solution if you don’t require the collision shape to deform with the animation. With engines like Unity or UE4 I can have make a custom collision mesh that deforms with the bones, meaning I can just have a low low loooooow poly version of my character/enemy and know the collision will work according to how it is being moved around.

killerpixler | 2019-09-04 19:54

I think that also in Unity/UE4 it’s better to use primitives (if we’re talking about human/animal collision shapes) not just for performance, but also realism. Take an arm for instance, We know it’s kinda rounded in humans. If you want to generate a dynamic concave collision shape, it won’t detect it as round as the mesh itself is not round, you can approximate roundness by having a lot of vertices, but that makes it very slow. So having for example, a capsule shape, for a part of the arm, would better simulate collisions than having an octagon or something. I don’t know what your use case is, but if you want the objects that hit the arm to bounce back more realistically than it’s better to have a round object. And if it’s also works well as a hitbox (it’s more performant than deforming a concave shape every frame). Godot is pretty young and you have to struggle a bit to be able to achieve same things as in UE4. In version 3.2 you will have convex decomp option, it could help you with your issue:

Godot 3.2 adds support for convex decomposition

You can get a 3.2 build here:
https://downloads.tuxfamily.org/godotengine/3.2/dev.00aabec8b/

gmaps | 2019-09-05 07:16