I am trying to simply move an NPC with rootmotion.
On my NPC I have the following components:
Animator
RichAi
Seeker
CharacterController
MecanimBridge
RVO controller
Ai Destination Setter
When I press play, the NPC seems to try and animate but it wont move at all. Unless I comment out:
aiBase.canMove = false;
Which I guess means im no longer using rootmotion?
I dont really understand how its possible that the animator plays animations that have rootmotion in them and wont move.
What is the necessity of the “InputMagnitude” is this supposed to be used for some specific animator that I dont know about? Why isnt forward and sideways directionality enough like it is with the unity one?
In unity’s implementation of rootmotion we do this:
public void Move(Vector3 move, bool crouch, bool jump)
{
// convert the world relative moveInput vector into a local-relative
// turn amount and forward amount required to head in the desired
// direction.
if (move.magnitude > 1f) move.Normalize();
move = transform.InverseTransformDirection(move);
CheckGroundStatus();
move = Vector3.ProjectOnPlane(move, m_GroundNormal);
m_TurnAmount = Mathf.Atan2(move.x, move.z);
m_ForwardAmount = move.z;
ApplyExtraTurnRotation();
// control and velocity handling is different when grounded and airborne:
if (m_IsGrounded)
{
HandleGroundedMovement(crouch, jump);
}
else
{
HandleAirborneMovement();
}
ScaleCapsuleForCrouching(crouch);
PreventStandingInLowHeadroom();
// send input and other state parameters to the animator
UpdateAnimator(move);
}
I am gonna throw a wild guess here,
you can’t have root motion AND rvo, unless you manually do some tweaking to decide when to use rootmotion and when to use RVO.
K that sucks, seems its rootmotion or local avoidance. Not both. can that be true? Guess im going to have to drop rootmotion then - and accept the sliding. Thought I made a work last time with the pro features but I guess I misremembered. Gonna see what I can do with Unitys built in Navmesh system, that seemed to do rootmotion alot easier, perhaps I can make some pseudo local avoidance that will suffice.
I have the same question - what is the purpose of the “InputMagnitude” blend tree parameter?
Why is not the usual Vector2 parameter (Forward and Turn) enough? Forward determines the speed and the animation to choose based on that number… right?
I actually simply skipped this parameter in the bridge and everything works amazingly. I actually got RVO + root motion to work and it looks quite nice. Still… I would like to know the purpose of said parameter in the Mecanim bridge.
Thanks for the clarification. I also see I made a mistake assuming InputMagnitude was also a blend tree parameter, since blend tree can only have one or two parameters at most. Both are used up by the Forward and Turn parameter. So it’s just an additional animator controller parameter.
I will also have to modify the MecanimBridge component to better fit pair of parameters Speed and Turn, rather than VelocityXZ. I’m new to animation, but if I understand it correctly, the current MecanimBridge implementation seems to be tailor made for Directional Blending like in the spider agent examples? Or better put - tailor made for something that can move in any direction at any time but also rotates in the direction of it’s velocity?
Unfortunately I didn’t find it’s usage example anywhere in the A*PP example scenes. So I’m just guessing here.
EDIT:
One more thing I don’t quite understand. Again with regards to the MecanimBridge component. Character’s rotation (at least in case of normal bipedal humanoids) should be entirely driven by root motion, right?
So why is there the RotatePointAround blend point part? I guess it would make sense in case I’m right with my aforementioned spider example theory.
The RotatePointAround if I’m not mistaken is for humanoid characters. When walking around people don’t rotate around their center point, but rather around the foot that’s currently on the ground.
That makes sense, but I just thought that this should be done by the root motion animation itself.
Meaning this should be accounted for by the animator deltaPosition and deltaRotation properties.
Rotation around grounded foot and the resulting displacement is modeled by the animation creator. So then, empowered with the power of Mecanim animation blending, it should always perform this rotation and displacement correctly, right?
I’m the animation greenhorn here, so it very well may be just my ignorance speaking
I just want to understand this fully.
Yup that’s correct, normally the animation would take care of that.
But I feel like you can’t always fully rely on only animation parameters. Especially for rotation imo.
So I tend to ignore any deltaRotation and let the movement script take care of the real rotation. Then these functions become really useful.
Though with good knowledge of animator - movement etc, I’m sure you’d be able to create some super good looking root motion with all the correct foot work there.
I personally don’t have that knowledge and in our current production don’t have the time to investigate more about this in depth.
If you manage to work out the blend trees / root motion controller / movement communication etc.
For both standstill, and 360 degree movement, I’d love to talk more in detail.
Well… 360 degree movement is not required in our case. The game is viewed from the first-person perspective. So only the monster are using animations and root motion. And these are only ever moving forward. So no strafing and no moving backwards.
We also have an animator (I mean a person, not a component ) so I’m not afraid of animation/rig quality inconsistencies etc.
Glad to know the RotateAroundPoint rotation “correction” is not always needed or something like that. Just spooked me a little, since I didn’t really notice much difference after commenting it out and using just the raw animator deltaRotation value only.
