FINAL IK - Full Body IK, Aim, Look At, FABRIK, CCD IK... [1.0 RELEASED]

Partel I am working with Adventure Creator and creating a point and click game, I am wanting to use the AimIK to make the character eyes, head and torso to follow the mouse pointer. I get how I can do that through your documentation, but I thought it would be cool that when I click on an object or on the floor that my character would look at it till it reached the spot then go back to following the mouse curser or if it was an object that it would start its interface animation.

I have no idea how to make the AimIK target stay where the mouse was clicked until the character has reached it's target then move target back to pointer or to turn off AimIK to play out the interface animation or switch over to your Interaction system... Can all that be done through your playmaker scripts?

Can this be done?

 

Hi,
The Playmaker scripts that I have at the moment are only for FBBIK and outdated, but they are actually next in my list to update/expand.

What you can do though is just interpolate the AimIK target to whatever the mouse touches. It could be something like this:

Code (csharp):

1.  
2.  
3. public AimIK aimIK;
4. public float lerpSpeed = 3;
5. Vector3 aimTarget;
6.  
7. void Update() {
8.  
9.   if (Input.GetMouseButtonUp(0)) {
10.      aimTarget = whateverTheMouseHits;
11.   }
12.  
13. // Always interpolate towards the aimTarget
14.  aimIK.solver.IKPosition = Vector3.Lerp(aimIK.solver.IKPosition, aimTarget, Time.deltaTime * lerpSpeed);
15. }
16.  
17.  

You'd be better off with LookAtIK instead of AimIK though, because thats exactly what LookAtIK was designed for. It works the same code-wise.
You can blend in/out the IK by using ik.solver.weight (from 0 to 1).

Cheers,
Pärtel

 

Partel

Thank you very much!

 

Partel - Really starting to like FinalIK....Thank you for creating it....

I am using hitreaction on a mecanim rig, and it seems to be a little "jittery" - I tried increasing the strength and it helped a little, but it is not smooth like the demo? It is kind of hard to describe...

Any ideas?

Maybe I could send you the project to test? Or should I record a video?

Thanks again

 

Hey, please send me the project to support@root-motion.com, its the fastest way

Pärtel

 

I got it working - seemed to be caused by the rig on the model.
It was a mixamo zombie model/rig - I ended up creating my own HumanIK rig in Maya and binded it instead. That one works fine without stuttering.
(Although I had to adjust the elbow joints to work with fbik - FinalIK didn't give a warning like ti sometimes does...)

Thanks again for your quick response...

 

Well I spoke too soon - not related to the rig.

Butthe problem is tied to the "Animate Physics" settings on the Animator.

If Animate Physics is enabled, then the hitreaction is jittery.

I am fine for now without turning Animate Physics off...But

I am confused by Aimate Physics - Partel can you elaborate on when it might make sense to use it?

And how it affects FinalIK

Thanks again for your help

 

Partel - One more question -

Does FBIK/HitReaction work with Animator controllers with "Apply root Motion" checked?

Seems that the FBIK effectors are not getting updated as the animation plays?

Sorry if this question is too basic - but I think I need to update the effector position with the transform changes caused bu the animation playing?

Thanks again for your help

 

Hi!

I updated the HitReaction script, it should now work with animatePhysics without any jitter, you can get it from here.. As for "Apply root Motion", it should make no difference at all, FBBIK doesn't even know about this checkbox and it only changes stuff internally in the Animator.

HitReaction is using effector positionOffset so if you are also pinning the effector to somewhere with full positionWeight, you will not see the effect because pinning an effector to effector.position with positionWeight overrides positionOffset.
If you want to pin an effector to somewhere, but still use hitreaction, you should add positionOffset to the pinning position like

Code (csharp):

1.  ik.solver.leftHand.position = leftHandTarget.position + ik.solver.leftHand.positionOffset;

Let me know if thats not the case
Pärtel

 

If anyone here is thinking about making a shooter, here is a tutorial on integrating Final IK with the awesome Shooter AI by Gateway Games. Should get you up and running (and shooting) in no time!

 

Partel, you said that your updating/adding to your Playmaker scripts, will blending like this be a node as well.

Also a lot of the scripts that you have for interaction etc, will we be able to have access through playmaker so scripting dunderheads like myself can tie them easily to mouse clicks, triggers, etc...

 

Partel - The linked hit reaction.cs to fix the jitter with Animate Physics enabled is the same I already had from the FinalIK unity package?

 

Partel - I am looking through hitreaction.cs, and making sense of most of it.

However, I have a conceptual question in the main update of hitpoint:

Code (csharp):

1.  
2.       // Update and apply this hit point
3.       public void Update(IKSolverFullBodyBiped solver, float weight) {
4.         // Update velocity
5.         velocity = Vector3.Lerp(velocity, -offset, Time.deltaTime * spring);
6.  
7.         // Update offset
8.         offset += velocity * Time.deltaTime * speed;
9.        
10.         // Update Effector Links
11.         foreach (EffectorLink e in effectorLinks) e.Update(solver, offset, weight);
12.        
13.         // Update Bone Links
14.         foreach (BoneLink b in boneLinks) b.Update(offset, weight);
15.       }
16.  

Basically update the Bone and Effector Links every frame.


But how does the following magic cause the spring effect of the offset:

Code (csharp):

1.  
2.        velocity = Vector3.Lerp(velocity, -offset, Time.deltaTime * spring);
3.        offset += velocity * Time.deltaTime * speed;
4.  

I understand what Lerp is doing, but how does this result in a "spring effect".
The velocity is being interpolated between the velocity and the offset, and the offset is being changed by the velocity every frame.

Over time, the offset oscillates in reducing swings - as you want - I am just impressed that these two lines accomplish that.

How did you come up with that?

Is there a good source of info on physics in Unity that you can recommend?

Thanks again for creating FinalIK and any feedback/advice is much appreciated....

 

Hi!

Yes all important variables and functions will be included

No it's new. Works the same, just fixes the bug.

The spring is in the first line, it pulls the velocity back, which is basically what a spring does.
Lerping stuff with Time.deltaTime makes the first parameter follow the second with speed depending on the distance, so the greater the offset, the greater the pull, which is also a characteristic of a spring.

The second line just applies the velocity.

I don't have a good source on physics to give you though, I just come up with that stuff by trial and error and lots of it

Thanks and cheers!
Pärtel

 

Thanks Partel - I am starting to understand hitreaction better. It is more of a "get results that look good" than a " model real-world physics forces" approach?

Is the following a correct(any feedback appreciated)

Offset is basically an "accumulated force offset" applied over time to both the Effectors and the Bones.
Offset starts at zero
Initial force is applied to velocity (unit force based on direction to weapon)

then every frame:
-velocity is calculated (interpolated between current velocity and offset based on deltaTime and spring strength)
-offset is adjusted by this velocity
-offset is then passed to each bone and effector to use
repeat next frame

Question: From a performance standpoint - would it be worth testing if offset was 0, and short-circuiting the loop. (Only apply hitreaction if there was force to be applied). Trying to use hitreaction on a horde of zombies .....

Thanks again
(btw - I am the same as CodeMonke234 - forum seems to auto-log me in to different accounts)

 

Hi I got some problem with the Aim IK. When I drag the aim target to the left and right hand side of the character, I was expecting he will rotate his body to facing it. But the result looks like this


The up and down rotation of the body is alright though.

 

Yes, its the look of the behaviour that you end up with that matters, I never aimed for real-world physics.
Looks like you understand the script well, in terms of performance, It might probably be indeed beneficial to disable the effector links if they fade out.
As of setting the effector position weight, that has no cost at all, its just changing a variable.
Please note that it is just a demo script and its purpose was not to be an out of the box solution, but rather learning material, so I tried to keep it as short as possible so there is surely room for optimisation.

Hi,

Its very difficult to say based on those pictures, could you please make a screenshot that shows the AimIK setup in the scene and the component inspector?

Better yet, if you could dropbox me a package with that character setup and send a link to support@root-motion.com, it would be the fastest way.

Cheers,
Pärtel

 

Partel - Are there any performance costs associated with having an FBIK component enabled? In other words, if I only use the FBIK for hitreaction, should I disable it and only enable it when the character is hit?

Also - Is there a lookat for FBIK like there is for grounder?

Or should I just use the LookAt Ik for characters that have FBIK instead of BipedIK?

Thanks again for your help

 

Yes, if FBBIK is enabled and its weight is 1, it will have a performance cost. If you fade weight to 0 or disable the component, there is no performance cost.

You can solve LookAtIK before FBBIK (not after, because twisting the spine will change where the hands will end up), remember, you cal always stack different IK components on top of each other.

The code for this would be like so:

Code (csharp):

1.  
2. public LookAtIK lookAt;
3. public FullBodyBipedIK fullBody;
4.  
5. void Start() {
6.    lookAt.Disable();
7.    fullBody.Disable();
8. }
9.  
10. void LateUpdate() {
11.    lookAt.solver.IKPosition = lookAtTarget.position;
12.    lookAt.solver.Update();
13.  
14.    fullBody.solver.Update();
15. }
16.  

Cheers,
Pärtel

 

Hello Partel,
Purchased the package yesterday. Overall very impressed.
A few niggles, mostly because I'm a beginner no doubt.
1. Grounder is causing a jitter in the pelvis of my character when an animation is playing and his foot drops down a step.
2. How is FBBIK affecting a throw animation? My character released a grenade via an event set in the animation itself. This event just adds force to the grenade and sends it off in a forward direction. However, with FBBIK enabled, the grenade simply explodes in the character's hand.

Thanks,

Bhads.

 

Hi Bhads44, I greatly appreciate the purchase!

1. Can you tell me which Grounder component are you using, FBBIK, BIpedIK or IK? Have you adjusted it's parameters or are you using the same as in the demo? More info would help a lot.

2. I can't think of any way FBBIK could be interfering with an animation. Final IK does everything it LateUpdate, after Mecanim/Legacy is already done animating for that frame. If you could package me that character throwing a grenade rig and send a link over to support@root-motion.com, I could see whats going on.

Cheers,
Pärtel

 

Partel,

Thanks so much for all your work on this asset. I'm very excited about what it can add to my game.

I've started out by adding the GrounderQuadruped script to a quadruped character I have. Things work as expected when the character is just walking around, but I'm getting some strange behavior when the character is either jumping or galloping -- the character rocks violently forward and back (around its x-axis) during both animations.

It looks to me like the Grounder is trying to ground the feet, and is rotating the body to accommodate, but the feet shouldn't be grounded at these moments in the first place.

What do you think? Am I right that the Grounder is trying to ground feet that are supposed to be airborne? If so, what can I do about it? I tried digging through the examples and didn't notice anything special for jumping. Any ideas?

Thanks!

 

Hi, Poatatojin,

You can adjust the amount of that with Root Rotation Weight, Min Root Rotation and Max Root Rotation and if thats not it, lower Max Step in the Solver and ForelegSolver. If still no luck, let me know

Cheers,
Pärtel

 

Partel, would your Playmaker scripts be able to load and unload IK rigs in Runtime, I have a point and click game where the character will look at the mouse curser as I navigate through the game, interact when I click on an object or open a door or pick something up, and then minigame parts where the animation will be procedural and would work best with FBBIK.

So will I be able to load different rigs using your playmaker actions and have the setup the same going back and fourth or can you think of a better way...

 

Thanks, Partel. I'm afraid that didn't do it. I'll send you a video to illustrate the problem and maybe you'll have an idea.

 

How feasable is final IK for 2D sprites (sidescroller)? I asked this on your official forums, but it seems like this page is more active All of these new shiny 2D sprite and physics components are coming out and I am thinking about buying IK for a 2D game project. Would I just constrain all rotations to the Z-axis then, in theory, a humanoid could still work (with a bit more playing around)? Of course the other option is that I use a 3D character as normal but with a fixed, orthogonal camera; however I think it would be more elegant if I could integrate it with the 2D layers and components. Have you tried this out yourself?

 

Hello Partel,

I fixed the throw animation by disabling fix transforms in FBBIK.
I will learn more about the various modules before troubling you again, however I would appreciate any hints, tips about how you would go about smoothly turning on AimIK for just 1 animation in mecanim (ie. when a rifle is equipped) and then turning it off when transitioning to other animation states.

Thanks.

 

Partel,

My compliments on an amazing Asset! I was blown away by the number of scenes you included to demonstrate all of the features of Final IK. Very well done. and even in beta it's a tremendous value.

I would like your opinion on how to best accomplish the following using Final IK:
I have a humanoid character that I would like to have crawl across a narrow balance beam. I purchased a crawling animation from Mixamo which is very close to what I need. The problem with the animation is his hands and feet are spread too wide when they connect with the ground so it doesn't look like he is connecting or grasping the balance beam. In your Grounder scene, I've replaced Grounder FBBIK with Grounder Quadruped and hooked everything up as close as possible to the way you hooked up the wolf. Crawling along the ground partially works. The hands work very well but the legs are having some problems. When I place the character on the beam, since his hands and feet are spread too wide, he sort of lands on his torso on the beam and slides along with his hands and feet dangling down flailing in the air. I was thinking perhaps rigging up the interaction system so his hands and feet actually interact with the beam as he is crawling along might work.

Do you think I may be able to accomplish what I am trying to do by using the interaction system in combination with Grounder Quadruped or would there be some better option?

Thanks
Allan

 

I think you would be better of to have all the IK components already on the character, then use IKSolver.weight to blend them in/out or just enable/disable the components. That would be also possible with the forthcoming Playmaker actions.

Just in case anyone else runs into this problem, it was the Pelvis Damper that was too high, it should not be higher than 1, I'll make sure to clamp that range in the next update.

I have not yet fully tested Final IK in 2D (do you have any nice free 2D character resources I could try with?), but you can't constrain FBBIK to 2D, I mean if you pull the character along the z axis, it gets pulled along the z axis. 2D IK components are somewhere down in my todo list though.

You can blend out/in the effect of AimIK using the weight parameter (aimIK.solver.IKPositionWeight). The code (from the top of my head) could be something like that:

Code (csharp):

1.  
2. Animator animator;
3. static int rifleState = Animator.StringToHash("RifleStateName");
4. AnimatorStateInfo stateInfo;
5. private float aimWeightTarget;
6.  
7. void Start (){
8.     animator = GetComponent<Animator>();              
9. }
10.  
11. void LateUpdate () {
12.     stateInfo = animator.GetCurrentAnimatorStateInfo(0);
13.     aimWeightTarget = stateInfo.nameHash == rifleState? 1f: 0f;
14.  
15.     aimIK.solver.IKPositionWeight = Mathf.MoveTowards(aimIK.solver.IKPositionWeight, aimWeightTarget, Time.deltaTime);
16. }
17.  
18.  

Hey Allan, and thanks for the compliments!

I never anticipated anyone using quadruped grounder for human beam crawling animation, so I honestly don't know how this all would work out, but I bet it would be easier to get rid of the grounder and just rotate the character to match the angle of the beam (if its straight) and use FBBIK effector.positionOffset or LimbIK to move the hands and feet closer together. If you could package me that scene, or show me a video or something, then I could help more.

Cheers to everyone!
Pärtel

 

Hi Pärtel. Me again, with more questions

I'm trying to get GrounderQuadruped to work with LookAtIK.

On my first attempt, it didn't seem like LookAtIK was doing anything, so I figured that Grounder must be overriding the lookat. I disabled Grounder, and LookAtIK worked perfectly, so I knew that was my problem.

I figured that it was an execution order problem, so I followed your instructions here for prioritizing execution: http://www.root-motion.com/finalikdox/html/page13.html

I have each of the quadruped's four legs updating before the LookAtIK, and it _sort of_ works, but now I'm seeing a very high frequency jitter in all the IK-solved motion: the head flickers back and forth between it's look at position and default, and the feet, when put somewhere new by the Grounder, flicker as well.

What am I missing? Is there a better way to get these two to play together nicely?

Thanks!

 

Hi, is the Animate Physics enabled in the Animator/Animation component of the character? If thats the case, then your animation is playing in FixedUpdate. The IK components can handle that, but if you disable them to update their solvers manually, you'll have to make sure to update only when the animation has updated. Otherwise the IK effect will accumulate over the frames that don't have a FixedUpdate call and that results in this kind of high frequency jitter.

You can either uncheck Animate Physics or check in each LateUpdate if a FixedUpdate has been called, something like this:

Code (csharp):

1.  
2. bool updateFrame;
3.  
4. void FixedUpdate() {
5.   updateFrame = true;
6. }
7.  
8. void LateUpdate() {
9.    if (!updateFrame) return;
10.  
11.    // Update IK here
12.  
13.    updateFrame = false;
14. }
15.  

Its a hacky workaround I know, but If you'd like a more elegant solution, you could place a hopeless vote on my feedback idea, that would help to clean up that mess

Cheers,
Pärtel

 

That was exactly it! You're the best.

Follow-up question: is there a way to limit rotation in LookAtIK so characters don't try to look down between their legs at targets behind them?

 

You can only limit LookAtIK with the Clamp Weight property. But you could also try using AimIK instead, its a very similar thing and I bet it will work better with quadrupeds. AimIK also supports rotation limits. Check out the manual of AimIK, specifically the paragraph "Using AimIK with Rotation Limits"

Cheers,
Pärtel

 

Purchased this asset a few hours ago and I must say that I am already very satisfied with the purchase. I have been playing with the many included scenes and they cover a wide gamut. It is refreshing to not only see a well developed plugin, but also one with such great examples and decent documentation to boot. So thank you for a job well done.

Here is what I need help with. I am using a Mecanim humanoid, with a rigid body with gravity. I need to be able to drag his hand upward and pull the character upward by this hand as well as side to side with the rigged character swaying appropriately when moved quickly while animation of the legs and other arm is continuing. So far I have attempted to raise the effector of the hand while lowering the other effectors, however I still have the issue of the root position not being effected. How should I go about setting this up?

Thanks again,
Tim

 

Hi, thanks for the purchase and the feedback!

If you set Pull to 0 for both of the arms and 1 for both of the legs, then the hand effectors won't be pulling that body up. Also set Pull Body Vertical to 0, that should do the trick.

Cheers,
Pärtel

 

Hi Partel,

Thanks for the quick reply. Sorry if I wasn't clear.

What I would like IS to be able to pull the body up with the hand, while the body sways, and animation. Somewhat of a ragdoll effect with animation. In the past I have switched to ragdoll and back however I would like to be able to continue animations with the other bones.

Attached is what I am getting. with left hand pull at 1 and other pulls at 0.


Thanks again,
Tim

 

Oh I see, did you mean something like this?

 

Thanks for that. That gets me started. I guess the way to go about it would be basically:

1. Detect when the hand is grabbed and the feet leave the ground
2. Attach the top of the pendulum to the hand and the bottom of the pendulum to the root transform of the character, This script could adjust the length of the pendulum depending on the rig size.
3. Deactivate the pendulum when then character hits the ground

This is what I was originally thinking but I didn't know if I was missing something. Sound about right?

One more quick question. With the fabrik arm. I am attempting to attach gravity and create a wrecking ball style chain similar to https://www.youtube.com/watch?v=oAWGs0kt_vM

I started with the Fabrik example and added the rigid body to each of the segments but nothing happens. What am I missing here?

Tim

 

Hey Partel,

I'm just getting back into things now, and trying to work out BipedIK. For some reason with UMA, it doesn't seem to automatically find any of the references. Is there any way to fix this, or is it just a case of adding them all manually?

I'm using (attempted to take from the inspector code)

Code (csharp):

1.  
2. bipIK = gameObject.AddComponent<BipedIK>();
3. BipedReferences.AutoDetectReferences(ref bipIK.references, OUR_Skeleton[BONE_ROOT], new BipedReferences.AutoDetectParams(false, true));
4.  

Scratch that - I had to have BipedIK on the same GO as the Animator. Sorted that now, and getting aiming sorted now. Could you tell me what sort of difference there is in load between FBBIK+AimIK and BipedIK? which is the heavier load?

 

I'm having a blast prototyping with FinalIK.

Your comments were very helpful regarding making a humanoid character crawl using Grounder Quadruped. It turns out, Grounder Quadruped works very well as long as you have a decent crawl animation. I'm still using Grounder Quadruped on a humanoid because it handles body rotation and keeping him on the ground. Per your suggestion, I've applied an Effector Offset in order to bring the hands and feet close together so they appear closer to the balance beam. The character rotates as the beam tilts and sticks to the floor with hands and feet just like spiderman, very nice. One strange thing that is happening is the feet and hands animate closer together but don't appear to IK at those closer locations. In other words, even though the hands and feet are animating in the offset position (along the centerline of his body) and thus staying on the narrow balance beam, the feet and hands still fall off the beam. In order to keep his hands and feet on the beam, the beam needs to be about body width. Since I'm only planning a 2D game, I've locked the character's Z position and am only moving back and forth along the X axis. My solution so far has been to increase the collider width of the beam but keep the mesh narrow so it only “appears” that he is on a narrow beam. This will work I think but would like your thoughts on this. (Animate Physics does not appear to make any difference. My guess is it has something to do the timing of Offset vs. FBBIK vs. the animation where the IK collision point(Raycast) is not in the offset position but the animation is. Since I can't see the raycasts for Grounder Quadruped it's kind of hard to tell.)

Next question: I'm switching back and forth between Grounder FBBIK (walking) and Grounder Quadruped (crawling) during runtime. I'm leaving both components active and adjusting their Master weights (0 vs 1) depending on whether the character is walking vs. crawling. For performance, i'm assuming adjusting the weights is the best way to handle that during runtime vs enabling and disabling those scripts.

Final questions: These have to do with the upper limits of Grounder Quadruped.
Using the default values is a great starting point because you've tuned them in. My character is having some trouble rapidly keeping up with the tilt of the balance beam as he is crawling back and forth especially when the beam tilts past the 50-60 degree angle. I have adjusted the following values:
Max Foot Rotation Angle on both solvers to 180,
Pelvis Speed on both solvers to 40,
Min Root Rotation to -180,
Max Root Rotation to 180,
Root Rotation Speed to 40,
Rotate Solver on and off.


What I don't have is a good feel for the min and max ranges of these variables before it no longer makes sense. That may be something worth putting in the documentation. Do you have any thoughts on mins and max settings before it no longer makes sense and are there any other settings I might consider?


Thanks
Allan

 

Partel,

I can confirm that the IKPosition that is calculated by GroundingLeg.cs is not the same position as what appears in the animation for my character's hands and feet when I use EffectorOffset.cs to offset the hands and feet when using Grounder Quadruped with 4 childed LimbIKs. I set up my humanoid exactly as you setup the wolf. So there are 4 LimbIKs childed to the Grounder Quadruped. Each LimbIK is mapped to the character's arms and legs and each LimbIK is then mapped to the legs and forelegs in Grounder Quadruped. I'm using EffectorOffset.cs to offset the positions of the hands and feet and that is mapped to FBBIK on the Animation Controller Object. For some reason, this offsets the animation as predicted but the IKPositions which determine collision with the ground are not being offset.

I placed the following code at line 144 in GroundingLeg.cs just after IKPosiiton is calculated in order to determine where IK is colliding with the ground.
Debug.DrawRay(IKPosition, Vector3.down, Color.red);

This appears to be a good way to debug where IK is determining the collision points with the ground.

I guess it's possible EffectorOffset.cs doesn't do what I think it does but it seems to me that any offset that changes the animation hand or foot position should also offset the predicted collision point with the ground.

Thanks for any feedback.
Allan

 

Please could give me a demonstration of a wallrun, if it is not too much to ask.

I mean this:
rotateSolver - if true, will use the character's local up vector as the vertical vector for the solver and the character will be able to walk on walls and ceilings. Leave this off when not needed for performance considerations.

 

I think the 3 points sound about right.
About the wrecking ball, why don't you just use the physics and the joints for that? Because if you put IK on a chain with non-kinematic rigidbodies, it will conflict with the physics.

Hi, Whippets, glad to see you're back!

BipedIK is basically just a collection of solvers, its just something like this:

Code (csharp):

1.  
2. public LimbIK leftHand, rightHand, leftFoot, rightFoot;
3. public LookAtIK lookAt;
4. public AimIK aim;
5. public FABRIK spine;
6.  

so using the AimIK of BipedIK is basically the same as having an AimIK component on the character, which is fast. So it depends on what kind of other IK stuff you need to do with your character, FBBIK is more expensive than the other IK components.

That first question, it must be because FBBIK solves after the Limb IK components that the quadruped grounder is using. So I suggest you overrride that updating order like so;

Code (csharp):

1.  
2. public FullBodyBipedIK fullBody;
3. public LimbIK[] limbs;
4.  
5. void Start() {
6.    fullBody.Disable();
7.    foreach (LimbIK limb in limbs) limb.Disable();
8. }
9.  
10. void LateUpdate() {
11.    fullBody.solver.Update();
12.    foreach (LimbIK limb in limbs) limb.solver.Update();
13. }
14.  

To answer your second question, indeed adjusting the weights is the best way.

About the min and max ranges, that indeed needs some clarification. I'll make sure to clamp the ranges and improve the docs on that, but to quickly answer the question, the reasonable ranges would be:
Max Foot Rotation Angle: 0 - 90
Min Root Rotation: -90 - 0
Max Root Rotation 0 - 90
Rotate Solver should be true for the quadrupeds, there is a typo in the current version about that, in GrounderQuadruped.cs, lines 223 and 224 should hardcode both the solver and forelegSolver to true.
About all the Speed variables, the best range seems to be usually between 5-30, but it really is a tweaking matter more than anything.

Thanks a lot for the feedback on the Grounder, it sure needs some
Oh, and I greatly appreciate the kind review if it was the same Allan

Sure why not, I'll try to put together something today.

Cheers,
Pärtel

 

Been thinking of getting this for my game, but have a few questions first.

1: How is performance on mobile? Only 1 character will be running IK.

2: Would this work with lets say a goal keeper, where I position the goal keeper between the goal and ball and when the player shoots the ball and it gets close enough I use IK to catch/deflect the ball.So like the goal keeper stretches out to where the ball will be in the future ready to catch it.

3: Does it work well with legacy animator?

Also how difficult will No 2 be to implement?

Thanks

 

Here you go: horizontal wall run Web Player demo

The only walkable vertical surface is the big wall behind you. Just run almost parallel to the wall and jump, try to keep moving towards the wall with the keys once walking on the wall. I've set max time to 1 sec since jump for this demo.

Hi, WJ,

1. Check out these two videos, iPhone 4 and Samsung Galaxy Note 10.1. .

2. Yes, but you would be better off if you didn't do it with just IK only (which would be difficult), but if you had some base animation for this and only used IK to make adjustments relative to the position of the ball. I mean like if you had the animation for catching a low ball to the right corner, then it would be much easier to use IK to make things look right if the ball ends up bit off from the ideal target.

3. Yes, it works with Legacy

Cheers,
Pärtel

 

Wow that WallRun was rather good!

I suspect there's a tad more going on than merely turning on the rotateSolver , hehe; will you release this demo scene as well, perhaps with the next update (or is it already available on your site)?

Thanks Partel!


-Steven


EDIT: Heck perhaps even the script would suffice I'd wager, as Grounder does most of the work.

 

@Partelang: many thanks, this is a bigger reason to buy this great tool

PS: Might have put at least 3 seconds

 

Partel,

In regards to Grounder Quad and my previous post:

I tried your suggestion:

Your solution does appear to cause the IKPosition to offset correctly however the animation has severe jitter and instability. It looks like there are frames of animation overlapping, conflicting, fighting with one another somehow.
Here is a shot of the IKPositions (Red Drawlines) vs. the animation of the Offset Hands and Feet using EffectorOffset.cs. Your script is in the lower right. The second shot has your script enabled but It's impossible to capture the jittery unstable animation in a screen shot. If you'd like me to shoot you a package just let me know.

 

I just wanted to show my support for this product. I hope it continues to be developed. The TrigonometricIK has opened a world of opportunity for my one-man-development-show that previously seemed out of reach.

My approach is to animate empty Game Objects that are tracked via a simple script. The script manually sets the GoalPosition and BendNormal based on the tracked Game Object every LateUpdate. Simple as it gets.

For example, note the simplicity of this animation:



And the script doing most of the work:

Code (csharp):

1.  
2. public class FinalIKGoalAnimator : MonoBehaviour
3.    {
4.       #region inspector
5.       public TrigonometricIK TrigIK;
6.    
7.       public Transform Goal;
8.  
9.       public Transform BendHandle;
10.       #endregion
11.  
12.       #region properties
13.       private Transform CachedTransform;
14.       #endregion
15.  
16.       private void Awake()
17.       {
18.          CachedTransform = transform;
19.       }
20.  
21.       private void Start()
22.       {
23.          if (Goal == null)
24.          {
25.             Goal = CachedTransform;
26.          }
27.          TrigIK.Disable(); // we will update it manually
28.       }
29.    
30.       private void LateUpdate()
31.       {
32.          if (BendHandle!= null)
33.          {
34.             TrigIK.solver.bendNormal = BendHandle.forward;
35.          }
36.          TrigIK.solver.SetIKPosition(Goal.position );
37.          TrigIK.solver.Update();
38.       }
39.  
40.       private void OnDrawGizmos()
41.       {
42.          if (BendHandle != null)
43.          {
44.             Gizmos.DrawLine(BendHandle.position, BendHandle.position + BendHandle.forward*.1f);
45.             Gizmos.DrawWireSphere(BendHandle.position + BendHandle.forward*.1f, .01f);
46.          }
47.       }
48.    }
49.  

Keep up the awesome work.

 

Hey, thanks, you can grab the scene. All the new code went inside CharacterThirdPerson.cs. Basically it just checks if the character has jumped, if it has enough velocity and stuff like that, then it just raycasts towards character forward to find the surface normal and rotates the character to that. Then while wall running, it keeps the character from falling down until max duration or the player moves away from the wall.

Hey, if its not the Animate Physics thing again, it would be best if you could dropbox me a package, it would be the quickest way to solve this.

Hey, and thanks for the support, the development of FinalIK will go on for a long time as far as I'm concerned.

The stuff you are doing actually is essentially quite similar to the "animate your characters entirely in Unity by using additive procedural animation modifiers" thingy I already showcased at Nordic Game last week. I used to call it Effector Animator, but it has grown a lot since then and become a much more powerful tool. Basically you can build your animation by stacking various animatable modifiers (FBBIK, Aim, Footstep, FK....) on top of each other, then bake the results to an animation clip.
Of course ideally you would be able to reuse those modifiers, group them (have a zombie style group on top of a normal group) and stuff like that, but there is still a lot of experimentation to be done on that.

Cheers,
Pärtel