Building hit zones with multiple colliders

[clever umbra]

How do you build a structure consisting of multiple colliders to use them as hit zones?
Currently entity hierarchies consisting of multiple colliders will either merge them or unperent them.

[bold anchor]

I would recommend making each hit zone a static rigidbody, this way you can gain access to the specific Entity of the zone that got hit with a raycast, and you'll be able to look for components on that hit Entity (damage multipliers, armor value, etc...). Your hit zones can keep a reference to the main Entity of the structure, where the Health component would live. So when a hitzone gets hit, we go and get the Health component on the main structure Entity and we apply damage to it.

Now what if the structure moves? First, your hitzone rigidbodies would be kinematic instead of static (kinematic is more optimized for moving). Then you could simply create a component & system that allows you to specify a list of "child rigidbodies" on the main structure authoring object. At runtime, this list of "child rigidbodies" will become a dynamic buffer of entities & local pos/rots. Every time the parent structure entity's transform changes, a system can update the world transforms of all "child rigidbodies" to immitate parenting.

I know it sounds like a bunch of work for a simple thing, but once you've written this "child rigidbodies" system once, you can re-use it everywhere

[clever umbra]

Wow this sounds like a really plausible idea 🤔 I am still wondering why they are unparented in the first place as the transform systems could easily handle the same job

In addition it gets a bit tricky if you start moving the sub rigidbodies by them selfs (e.g. by animation). This would require the simple child rigidbodies system to mimic the complete transform systems with LTP, LTW and so on again, woulndt it?

[bold anchor]

I am still wondering why they are unparented in the first place as the transform systems could easily handle the same job
I'll ask around and see if I can find an answer. I can only speculate, but I think there might be performance reasons

[clever umbra]

I actually found a forum thread where someone resolved it by just reparenting it in the last baking/conversion step.
I absolutely see the reason for unparenting if it is dynamic but not for kinematic RBs.

[clever umbra]

Thanks I would really appreciate that 🙂

[bold anchor]

Hey, just got an answer for this. It's really just because there would be a performance price to pay for supporting this. Since the cases where this sort of parenting is needed are rare relatively to the cases where it's not needed, it seems like going with the "manual parenting" approach described above would be the way to go

[clever umbra]

Thanks for getting an answer on this. I dont think that this is a rare case though. Almost every game will have a need for movable "subcolliders". Every animated character that needs hitzones as in shooters or fighting games would need to keep track of their limb sub colliders in relation to the character.

Even just a car that can open its doors would need to have a separate collider for the door that is parented to the car

I am really curious how this issue will be resolved in the animations package

[ashen lintel]

I guess if you dont have experience making games, colliders seem like a rare thing. Did Gigaya only have one collider?

[bold anchor]

An update on this:
On compound collider entities, there is actually a DynamicBuffer<PhysicsColliderKeyEntityPair>, which associates a collider key to the original entity it was on. This looks like it would be the way to go for this use case. So no independent rigidbodies; just a compound collider where you can retrieve the original entity through the DynamicBuffer<PhysicsColliderKeyEntityPair>

Still working on getting answers for what's the best solution when the hitboxes would be moving relatively to the parent (like hitboxes on animated characters)

[clever umbra]

Yes that would be the best solution for non moving subcolliders. Not sure if it can handle disabling parts of the compound collider.
Our biggest problem with that is that the game instantly crashes on runtime conversion when generating compound colliders.
We are still on 0.51. I hope this is fixed on 1.0 either because it stopped crashing during conversion or because its possible to preconvert prefabs with the new "content managment"

[clever umbra]

Thank you very much for keeping on asking 🙏

I actually remember I found a forum thread where somebody had the solution to just reparent it in a late baking/conversion step. Didnt test yet if this actually works. But it feels a bit unsafe 😬

[bold anchor]

It looks like our suggestion for moving hitboxes at the moment is using the one-kinematic-body-per-hitbox + custom parenting approach. However, I'll make it a point to test this out in practice internally and provide feedback to our teams if I notice that the workflow needs improvement. Can't make promises as to when this will happen, but it'll be on my list