I have a bit of an issue trying to get a hitbox to work with my animation.
Here’s my setup:
I have an imported root motion animation
I duplicated the animation so that I could edit it in the animation tool in unity
I added a child game object to the character with a 2d collider on it (this is my hitbox)
I animated the collider to coincide with the punch animation
Because the animation for the collider is in the same clip as the mesh animation, it’s on the same animation controller (in case that’s not obvious).
This looks fine in the preview when I scrub the animation or play it in the animation window, but there’s an offset when I test in playmode.
This is the animation when I set it up in the animation window. Looks fine.
Same animation when I test it in play mode:
I chose this workflow because it allows the designer to easily tweak hit frames, etc, and you can preview it easily. Having to animate the hitbox on a separate clip/controller would be a nightmare to line up.
So, is there a way to fix this, and/or a better workflow to animate the collider?
EDIT: This behaviour was observed in 5.6.0, 5.6.1 and 2017.1
I’m not sure why it’s happening, but what about making the collider object part of the character asset itself, eg. 2d plane standins for the hitboxes? Then you could animate the hitboxes along with the rest of the animation. In Unity you’d hide the plane’s renderer and add a matching collider. This could also make later changes easier, since you wouldn’t be duping the imported animation.
We’ve definitely considered this option–that said, I’d much prefer if the designer had the ability to do the tweaks in Unity rather than having to do them in Maya/Max. I’m thinking it’s a good fallback to an in-editor workflow, but I’m hoping there’s a simple fix to my current issue.
What happens on the next animation cycle? Does the hit box move as desired but delayed?
A video or gif of both preview and in play mode would be helpful - showing more than one animation playing sequentially with the results of the hit boxes showing.
I’ll do a gif later tonight and post. That’s a great idea.
The offset is always the same. I can trigger the punch animation from any location, move the character, do it again, and the offset is still wrong (but the same relative distance).
That looks like a double transform. I don’t know if that happens in Unity, but it’s common in other systems. The collider shares the animation clip and animation controller, but is it a separate asset with its own Animator? It could be getting moved by the motion of the character you parented it inside, then moved again by the hitbox animation. If so, you might try making the GameObject the collider lives in exist in the character asset, iand adding the collider to that (so there’s only one Animator), instead of parenting a new object inside the character.
Can you do a simple test - parent a non-animated hit box just like you did with the existing hit box and see what the results are?
I agree with @NoiseFloorDev - this does look like a double transformation.
Are you using root motion (I don’t know if this matters)?
If so - by turning off root motion in the inspector - does the hitbox still offset incorrectly?
Edit: Where is the hit box parented in the character hierarchy? Can you show your character hierarchy?
Also might consider looking into some of the asset packs on the store that are related (hitbox). I bet you might be able to solve based on referencing those - and possibly the supporting forum threads.
@theANMATOR2b
I tried a second hitbox with no animation, and its offset is correct.
I am using root motion animation.
Here is a screenshot of my hierarchy:
Colliders contains the hitbox (the copy is the one I was testing with per your question)
Are you familiar with animation layer masking? IDK if this is a solution but thought I’d mention in case you are not familiar.
The hit box is inheriting the root motion translation - based on the the test you performed.
So - you are going to have to research parenting an animated object to a root motion controlled character - without inheriting the root motion transform.
Does changing the animation set up root motion options in the inspector for the hit box solve?
Root Transform Positoin (Y), (XZ)
Alternative (probably not optimal) syncing a separate animation controller for the hit boxes with the existing character animation controller.
@theANMATOR2b
Unfortunately, this approach did not work–it overrides the default root motion behavior on the biped with the animator, but doesn’t do anything for the collider.
The result is the character loses root motion, and the child collider is still offset.
Back to square one.
From google - it seems maybe the ‘workable’ solution is to move the hitbox via code - but I refuse to believe that is the ONLY solution for this. There should be a simple animation solution.
Right??? It just seems odd that there isn’t a simpler what to solve it.
I’m doing some timeline research right now to see how that interacts with Mecanim. Animating the collider in timeline works fine, but then I have some animations in mecanim and some driven via code + timeline/playables
Create the hit box in 3D and animate it as normal in 3D. In Unity use avatar mask to allow for humanoid retargeting.
Create the hit box to be the size of the fist, parented to the hand (not animated) so when the hand shoots forward the hit box ‘hits’ with the fist instead of having the hit box be the size of the arm.
Have the hit box positioned where the punch will occur and turn it on/off when needed. (not the best option)
Of the 3 solutions that will solve the problem, I prefer #1, but would still like a solution that allows for the hit box to be animated without multiplying the root motion translation.
