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

Hi, Slonika,

Have you seen this video (from 1:50)?

If this is an UMA character and you need to initiate it in runtime, you can call this line to apply limb orientations pre-defined for UMA:

Code (CSharp):

1.  ik.solver.SetLimbOrientations(BipedLimbOrientations.UMA); // The limb orientations definition for UMA skeletons

Cheers,
Pärtel

 

Thanks a lot for answers. I just did like in video (rotated the leg) and it started to work properly. Thanks a lot again

 

Thanks! No rush though

Btw, just in case you meant the video with the guys in the car: that video and the shown demo is not from me (I only did the silly nightclub one), I just liked the idea a lot so I want to be able to do the same in my little experiment

 

Hi Partel.

I'm using Final IK with UMA and everything seems to be working fine with the interaction system but am having some trouble getting AimIK setup properly. I assigned Spine and Spine1 and set the Aim Target but there character is not deforming right at all. the Target is a child of Spine 1. I tried orienting the target to 0,0,0 world space and local. Have you or anyone else gotten AimIK to work with UMA?

 

Hi, Hedonsoft,

If the Target is parented to one of the spine bones, you will get a circular dependenty. That means when AimIK rotates the bones, the target will rotate along. The Target should be independent of the bones used by AimIK.
If I misunderstood you, a few screenshots would help..

Cheers,
Pärtel

 

I'm using the interactionsystem to pick up a gun that gets parented to the UMA's RightHand. The UMA's structure is spine, spine1, rightshoulder,rightarm,rightforearm,righthand, gun. Is this setup correct?

Here's a screenshot. You can't see the jerkyness in the screenshot. I have a mouselook script attached. looking right aims left, looking left aims right and trying to aim up or down just makes it go crazy.

http://i.imgur.com/bkixJqa.jpg

 

It's very difficult to see what might be going on. Are you sure the Axis is correct, I mean is it the local axis of the "TargetObject" that you need to be aimed at the target? Seems to me the "TargetObject" is looking towards a point somewhere behind the character (indicated by the purple cone and the line to the target), but the hands seem to be aiming forward, so I guess the Axis is not right or the TargetObject's rotation relative to the right hand is offset to the left. Can't see the gun though.
Also I see you have 3 warning messages in the console, is any one of them from AimIK?

If you could dropbox-or-something the project and send me a link to support@root-motion.com I could solve this right away.

 

I found a very simple solution for adding some neck motion.

Just add a LimbIK component to the last spine bone. Assign the last spine bone, neck and head as bone1, bone2, bone3.
Set position weight to something between 0 and 1, depending on how much neck you need. Set rotation weight to 0 for starters, you might want to use it though for rotating the head. Assign the Head Effector gameobject as the Target of LimbIK and play the scene.

If you have more than 1 neck bone that you wish to use, you could try the same with CCD and FABRIK, but they might prove incontinuous when the character has neck animation.

Pärtel

 

Thanks, I will try it out!

 

Thanks Pärtel. With the LimbIK the head movement looks better when going side to side, but there seems to be a problem when going down (from top to bottom: LimbIK position weight 0, 0.5, 1):




When going down with the head, LimbIK seems to make the posture very unnatural.

 

Ok I see.. so you need the neck for only sideways motion, but ignored when pushing the character down?

Please try this little piece of code, see if it's any better for your needs (no need for LimbIK with this, put it on the Head Effector game object):

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class NeckRotator : MonoBehaviour {
5.  
6.     [Range(0f, 1f)] public float weight = 0.5f;
7.     [Range(0f, 1f)] public float maintainHeadRotation = 1f;
8.     public float maxAngle = 25f;
9.     public Transform[] neckBones;
10.     public Transform head;
11.  
12.     void LateUpdate() {
13.         if (weight <= 0f) return;
14.         if (maxAngle <= 0f) return;
15.  
16.         Quaternion headRotation = head.rotation;
17.  
18.         foreach (Transform bone in neckBones) {
19.             Quaternion r = Quaternion.FromToRotation(head.position - neckBones[0].position, transform.position - neckBones[0].position) * bone.rotation;
20.             bone.rotation = Quaternion.RotateTowards(bone.rotation, r, weight * maxAngle / neckBones.Length);
21.         }
22.  
23.         head.rotation = Quaternion.Lerp(head.rotation, headRotation, maintainHeadRotation);
24.     }
25. }

Pärtel

 

Hi all,
I managed to improve the head effector a bit based on some valuable feedback. Added a quick CCD pass for the spine and the neck to make the spine more flexible and give you more tweaking options.

Cheers,
Pärtel

 

OMG Pärtel you da man! That works awesomely.

For those who like me create the HeadEffector at runtime, I added some code at the beginning of the Start function in FBBIKHeadEffector to automatically find some CCDBones:

Code (CSharp):

1.      
2. if ( CCDBones == null )
3. {
4.     Animator anim = ik.GetComponent<Animator>();
5.     Transform[] potentialCCDBones = {
6.                 anim.GetBoneTransform(HumanBodyBones.Spine),
7.                 anim.GetBoneTransform(HumanBodyBones.Chest),
8.                 anim.GetBoneTransform(HumanBodyBones.Neck) };
9.  
10.     CCDBones = potentialCCDBones.Where(t => t != null).ToArray();
11. }
12.  

This is now an official must-have asset for Unity VR devs!

 

This asset is the craziest thing I've ever seen in my life (well, except for this one woman). I've got a jaw to pick up off the floor now. Thanks for making this available on the asset store.


Edit - Okay, now I just saw the craziest thing I've ever seen for the second time. Your advanced character physics demo. You might have just knocked sliced bread off the list of greatest things ever.

 

wow, didn't expect that. Thank you!
Also I very much appreciate the review

Cheers,
Pärtel

 

Pärtel, would there be any way to reposition a 'pin,' such as those used in your AimIK swing examples to take into account a resized UMA avatar?

 

Hi,
In case of uniformly scaling the entire character, i guess it would suffice to write

Code (CSharp):

1. pin.localPosition *= 0.5f;

for half a man. But if you are significantly changing body proportions, I don't think there is a simple way to automate it.

 

Hmmm, if you put a pin on the weapon or hand and checked its position at the time in the animation it should hit would that give a good pin position?

 

Good idea, indeed that might work... using this perhaps for sampling.

Pärtel

 

Cool, thanks. I'd like to ask your input on something.

I'm attempting to create a fairly involved combat system, and I want to decide on which route to take. What I'm currently working on is the portion for two-handed attacks. I want to be able to specify a target position, a direction of attack (a range of probably 360 degrees, specifying whether the weapon will swing left, down, diagonally, or anywhere in between), and a strength (with higher strength blows taking longer and having a more pronounced draw back and follow through) and have it produce an animation of the appropriate direction and strength, turned and extended/compacted to reach the target.

I have considered three approaches:

The first is to do the animations completely procedurally with FinalIK. I have been experimenting with manipulating Effectors and weights procedurally by Tweening them through various steps. I have also been using Vector3.Slerp to produce circular motions. The results have been better than I might have thought.
The benefit of this approach is that I need no animations and I have complete control over the behaviour, but every 'action' would be very laborious to create and would look somewhat mechanical.

The second method would be to do it almost entirely with animations and blend trees. The problem with this is that I would need many and very specific animations, necessitating I create them myself, and every variable I want the attack to accept would have a multiplicative effect on the number of animations required.
For example, for 8 attack directions, 2 attack strengths, and 2 distances, I would need 32 separate animations. It's feasible, but I would want to be certain of my choice before I invested too much time in this method.

Finally, what I hope is the easiest and best way is a happy medium of the two, where I take some foundation animations (which in this case I think would be the eight attack directions), and then redirect and scale them based on my inputs.
Now, making the attack face the target using pin transforms and AimIK is fairly simple, but stretching the attack to meet the target and scaling the 'strength' of the attack seems quite a bit harder. The offset script comes to mind, but I can't think of how I would apply it to this case. What components or applications of FinalIK do you feel would be most suited to this task?

That was a bit more involved than I had originally intended, but hopefully you find it a stimulating question.

 

Hi alphalpha, just chiming in here, hope you dont mind!

I've had the same problem and reached a similar conclusion, which I've now implemented in parts. You're right that option 2 isnt viable. It's the reason why Ubisoft can claim to have "8000 animations" for the Assassin's Creed avatar, and the reason why Final IK exists in the first place. Its not even a matter of budget, combinatorial explosion will always be the limiting factor.

Regarding your option 1, I was hopeful at first but quickly realized that there's a difference between "working" and "good-looking" procedural animations. It's easy to make something basic work, but very hard to make it look good and biologically plausible. All the little parameters you would tweak while animating your rig in Blender/Max/etc are unavailable in Final IK, and they should be, because otherwise it would get too complex. A solution to this is someting like NaturalMotion's Euphoria engine (made famous by Clumsy Ninja), which understands biological constraints of muscles and joints. Maybe someone will make such an asset for Unity one day, but until then, you're out of luck (and I'm out of luck anyway because such an engine is species-specific, and i'm animating dogs).

Your option 3 is IMO where Final IK really, really shines. For instance, I use AimIK to make my dog look around. This affects only three neck bones and the head bone, but by itself it still makes the movement look stiff and unnatural. The solution for me was to combine this with neck-animations and neck-poses (1-frame animations) which are placed into their separate layer in Mecanim. These do things like: bringing the neck into a pose from which AimIK can interpolate good looking movement, facilitating transitioning into/out of AimIK, and so on. This use is similar to what's called IK-hinting in traditional animation, where you combine forward and inverse kinemematics to get a better result from the latter.

My suggestion is for your to really explore first how far you can get with such a semi-procedural approach. It might be quite far! Another thing is that Mecanim's blend trees themselves are far, far more powerful for semi-procedural animations than most people realize. For instance, I'm using a chain of several blend trees to control the movement of the tail of my dog. Like that, the dog never wags the same way twice, although its all done via a small set of animations and blending!

Cheers, Wendelin

 

I don't mind at all Wendelin! In fact, it's very valuable to have input from someone who's worked on a similar problem.

I have tried a bunch of stuff with Mecanim's blend trees and I agree they're very powerful, which is why I think I'll rely on them for the attack directions around the z axis, for which it would be difficult to achieve a good result with FinalIK, letting that handle rotation around the y and x axes as well as hopefully stretching/compression. I've started messing around with the offset scripts and the results look promising.

I was intrigued by my progress in procedural animation, though; I may write a complete Slash function at some point just to see how good I can get it.

Combining animation and FinalIK like this is going to require a lot of crosstalk between animation states and FinalIK effectors and weights. How do you go about marrying the two systems?

Thanks again for your input.

 

Yip, that's a tough nut to crack. For starters, I keep the two cleanly separated but control them with a similar mechanism (a large set of concurrent tweens which are restarted/reinitialized on demand and always recycled). No other code gets to talk to the Animator or FinalIK. Coordination of the two (or of concurrent animations on different layers, etc) happens at a higher level that uses dedicated functions to schedule tweens. But I havent done much work on this higher level yet. However, I think my problem here is simpler than yours, because quadrupeds dont have this free upper-body with even freer limbs which can do all sorts of dangerous things (dangerous from an animation viewpoint, like cross-intersections). Keep us posted about how you solve this for your combat system! I think such a system would interest a lot of people. Pärtel has written somewhere in this thread that he encourages assets built on top of FinalIK (where users obviously need to license both assets).

BTW, for the tweening, I've tried iTween, HotTween, LeanTween and DFTween, and found that only the latter is both fast and memory-conscious, though it too isnt entirely bug-free.

EDIT: forgot to mention, I've also not yet finished evaluationg StateMachineBehaviors in Unity 5. They can obviously useful in the marriage problem you mention, but they are also a bit odd and overkill for many purposes. The truth is, Mecanim still lacks a general event system that can really smooth such coordination problems. Right now we have events at the level of animation clips, the new SMBs at the level of states, and nothing at the level of transitions. So weird. Yet i'm sure a lot can be done with this setup.

/W

 

Yes, you are right, the best solution is always achieved with combining keyframe/mocap animation with IK. Ideally IK is just for making minor adjustments to the animation to make it more consistent with the changing in-game environment.

In this case I would go with using IK to minimise the animation work to 8 directions, using effector offsets and perhaps the Amplifier to take care of strength and distance. It really depends on the kind of animations that you need though. I once made a small script for animating effector offsets based on normalised time of base animation. A customer needed something like this to simulate gait abnormalities. Here's the script:

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3. using RootMotion.FinalIK;
4.  
5. namespace RootMotion.FinalIK.Demos {
6.  
7.     /// <summary>
8.     /// Animate effector positionOffset for an animation state
9.     /// </summary>
10.     public class AnimatedOffset : OffsetModifier {
11.  
12.         /// <summary>
13.         /// Animated offset for an effector
14.         /// </summary>
15.         [System.Serializable]
16.         public class EffectorOffset {
17.  
18.             public FullBodyBipedEffector effector; // Effector type
19.             public AnimationCurve x, y, z; // Offsets for each axis in normalized time (0 - 1)
20.  
21.             // Apply the position offset
22.             public void Apply(IKSolverFullBodyBiped solver, float normalizedTime, float weight) {
23.                 normalizedTime -= (int)normalizedTime;
24.  
25.                 solver.GetEffector(effector).positionOffset += solver.GetRoot().rotation * new Vector3(x.Evaluate(normalizedTime), y.Evaluate(normalizedTime), z.Evaluate(normalizedTime)) * weight;
26.             }
27.         }
28.  
29.         /// <summary>
30.         /// Animated rotation offset for a bone
31.         /// </summary>
32.         [System.Serializable]
33.         public class BoneRotationOffset {
34.        
35.             public Transform transform; // Effector type
36.             public AnimationCurve x, y, z; // Offsets for each Euler axis in normalized time (0 - 1)
37.        
38.             // Apply the position offset
39.             public void Apply(float normalizedTime, float weight) {
40.                 normalizedTime -= (int)normalizedTime;
41.  
42.                 Quaternion euler = Quaternion.Euler(x.Evaluate(normalizedTime) * weight, y.Evaluate(normalizedTime) * weight, z.Evaluate(normalizedTime) * weight);
43.  
44.                 transform.localRotation = euler * transform.localRotation;
45.             }
46.         }
47.  
48.         [SerializeField] Animator animator; // If using Mecanim
49.         [SerializeField] new Animation animation; // If using Legacy
50.         [SerializeField] string animationState; // Name of the animation state
51.         [Range(0, 1)] [SerializeField] float cycleOffset; // Offset in normalized time
52.         [SerializeField] float blendSpeed = 1f; // The speed of blending in/out the effect when switching animation states
53.         [SerializeField] EffectorOffset[] effectorOffsets; // The animated effector position offsets
54.         [SerializeField] BoneRotationOffset[] boneRotationOffsets; // The animated bone rotation offsets
55.  
56.         private AnimatorStateInfo info;
57.         private float blend;
58.  
59.         // Add to FBBIK effector positionOffset
60.         protected override void OnModifyOffset() {
61.             if (animator == null && animation == null) return;
62.             blendSpeed = Mathf.Clamp(blendSpeed, 0f, blendSpeed);
63.  
64.             // blending in/out the effect when switching animation states
65.             blend = Mathf.MoveTowards(blend, (stateIsPlaying? 1f: 0f), Time.deltaTime * blendSpeed);
66.  
67.             if (blend <= 0f) return;
68.             if (weight == 0f) return;
69.  
70.             // Get the normalized time of the current animation state
71.             float n = normalizedTime + cycleOffset;
72.  
73.             // Apply the position offsets
74.             foreach (EffectorOffset o in effectorOffsets) o.Apply(ik.solver, n, weight);
75.  
76.             // Apply the bone rotation offsets
77.             foreach (BoneRotationOffset o in boneRotationOffsets) o.Apply(n, weight);
78.         }
79.  
80.         // Is the animation state playing?
81.         private bool stateIsPlaying {
82.             get {
83.                 if (animator != null) {
84.                     return animator.GetCurrentAnimatorStateInfo(0).IsName(animationState);
85.                 }
86.  
87.                 if (animation != null) {
88.                     return animation.IsPlaying(animationState);
89.                 }
90.  
91.                 return false;
92.             }
93.         }
94.  
95.         // Gets the current normalized time of the animation state
96.         private float normalizedTime {
97.             get {
98.                 if (animator != null) {
99.                     return animator.GetCurrentAnimatorStateInfo(0).normalizedTime;
100.                 }
101.  
102.                 if (animation != null) {
103.                     return animation[animationState].normalizedTime;
104.                 }
105.  
106.                 return 0f;
107.             }
108.         }
109.     }
110. }
111.  

I never had the time to fully test it or it's usability yet, but it is basically like effector animation running on top of normal animation. I'm not sure if it's any easier to set it up rather than just modifying the actual animation though.

Cheers,
Pärtel

 

Wow, that's a lot of useful information, thanks!

@WendelinReich I've been using DFTween myself, and have been liking it so far; good to know it's a solid choice. I'll probably have to do something similar to what you've got, so maybe I'll check out StateMachineBehaviours; thanks for the tip.

@Partel Lang Good to know I'm on the right track. Thanks for the script, it looks like good reference. I forgot the Amplifier, I'll go look over that again.

 

First off, thank you for a great package!

We have lots of cases where we want to use IK to slightly adjust the position of the hands during an animation so that they make good contact with surfaces, ropes, ladders etc. I have some stuff up and running but its a little fiddly because the HandEffector is matched to the wrist.
Would it make sense to add another effector to the arm chain that sits somewhere around the palm so that wrist rotation is solved by the IK system?
Or maybe i should really be using the interaction system for all this? I havent really looked that closely at it yet since i figured we want most reaching motions to be animated with IK simply making small adjustments.

Cheers!

 

Hi, Idoru, and thanks!

The easiest way to solve this would be to parent your hand effector target to a pivot object that is at the contact position. Then you can use a very simple script on the picot to keep it rotated towards the character using Transform.LookAt for example.

Code (CSharp):

1. void Update() {
2. transform.LookAt(character.position + Vector3.up, Vector3.up);
3. }

You can also use the RotationLimit components to limit the range of that pivot if you need to. Thats how the Interaction System is doing it.

Another solution would be to parent a dummy gameobject to the hand and position it to the palm. Then you set the hand bone in the FBBIK References to that dummy instead of the real wrist bone.
The wrist joint would not be used in the solving process though and the effector would not rotate the hand so I'd go with the first option.

Best Regards,
Pärtel

 

Hi Partel, I'd like to use FinalIK for bending a fishing rod. I've rigged the rod with bones and added the FABRIK component to it. It's working pretty well however it needs the end bones to bend before the later bones, at the minute they're all bending at the same time which is unrealistic.

 

Interesting case! But if it's realism youre after, you'll have to ask for something slightly different. The handle part of a real fishing rod doesnt start bending later, it bends right away (almost linearly w.r.t load, I think). But the end/fishing line-part bends less and less with higher loads because it's getting more and more aligned with the line. That's a different problem, but a hard one as well - I'm actually curious how an IK system can handle this, or if this is more a use case for a chain of configurable joints...

 

Sounds like you have it backwards. The handle part of the rod doesn't bent at all and then as the rod gets towards the tip and gets thinner the rod bends more. The thinner parts of the rod are first to bend under pressure followed by the thicker parts.

 

Hi, Did you try CCD IK? With CCD you can specify the weight for each bone in the rod. CCD tends to roll in on itself though with such long chains though, but it's worth a try.

Cheers,
Pärtel

 

Hi, I did try that too but it tended to bend in 2 directions so looked worse than before.

 

I saw some pics in the megafiers forum by someone making a fishing game. I think he used megafiers bend modifier to bend the pole and was trying to use quick ropes for his fishing line. Look at post #1487 More pics in the quick ropes forum if you look at his post history.

 

Do you need to just bend the rod or you also need for the tip to end up at a specific location? Because if you don't it would be much easier/faster to just bend the bones directly...

 

The tip needs to follow the direction the line is being pulled. This is where a regular bend animation falls short as it just bends down and if the line isn't directly below the rod tip it looks odd.

 

Thanks. Yeah I tried that but in order to get the position of each eye so I could pass the line through I had to get vertex position which was proving slow on mobile. How I have it now by rigging a simple bone system and adding extra bones where the line will pass through works good but if I can get partels finalik to bend the rod correctly I think it would be the best approach.

 

Would it be possible for you to send me the rod you are using to support@root-motion.com? I could try with a random bone chain, but the best results are always achieved with the exact model.

 

Sure, I'll package it up and send it to you. Thanks

 

I've been using FinalIK for aiming/foot placement and it is great. AimIK + Grounder with FBBIK. However, it is a CPU hog, even with relatively low weighting. Beyond selectively weighting agents based on distance, only enabling it for N number at a time, and other such heuristics, as well as keeping the number of spine bones to a minimum (which I do) is there anything else one can do to increase performance?

Since I don't use IK beyond aiming/foot placement, is the full FBBIK simulation necessary? It certainly seems like that is the culprit (the aiming seems quite performant).

 

Hi,

No you don't need FBBIK in that case. You can do practically the same grounding with other Grounder components, there is GrounderIK for example, that lets you use LimbIK for the legs and that is as fast as IK can ever be.
GrounderFBBIK was designed for making use of the FBBIK component if it already has to be used for something else.

Btw since FinalIK 0.4, you can set FBBIK solver iteration count to 0, in which case full body effect will not be calculated at all.

A couple of additional notes from the FBBIK page of the user manual:

• You can use renderer.isVisible to weigh out the solver when the character is not visible.
• Most of the time you don't need so many solver iterations and spine mapping iterations. Sine FinalIK 0.4, we are able to set solver iteration count to 0, in which case the full body effect will not be solved. This allows for easy optimization of IK on characters in the distance.
• Keep the "Reach" values at 0 if you don't need them. By default they are 0.05f to improve accuracy.
• Keep the Spine Twist Weight at 0 if you don't see the need for it.
• Also setting the "Spine Stiffness", "Pull Body Vertical" and/or "Pull Body Horizontal" to 0 will slightly help the performance.
• You don't need all the spine bones in the spine array. FBBIK works the fastest if there are 2 bones in the spine, the first one listed as the Root Node, and the other one the last bone in the spine (the last common ancestor of both arms). Having less bones in the Spine makes it more rigid, which in some cases might be even a better, more natural looking solution.

One question for you, do you have ragdoll colliders on your character?

Best Regards,
Pärtel

 

Yes I do have ragdoll colliders, but they are disabled until I need to ragdoll, at which point the IK is disabled. I did read all the performance notes - however, I didn't realize you could use grounder IK in a less intensive fashion, i.e. without FBBIK. (I figured this was possible, but I couldn't figure out from the docs to be honest.). Thanks, I will look into that.

Edit: Actually I just reread your post - I didn't realize I could turn off the solver iteration count on FBBIK. That likely will solve my problem, and leave it open for me to use FBBIK if I need it down the line.

 

Hi all,

I am just starting out with Final IK, and have some nice ideas of applications for this great tool, however I am a bit stumped as to where to start?

I would like to setup a quick test, using a Mecanim character standing with an idle animation looping, and then I want to be able to use touch gestures to move limbs on the character, eg touch a hand and drag up, down, left or right and the characters arm moves about, same for a foot and leg etc.

Anyone able to point me in right direction on where to start with the Final IK part, I can setup my Mecanim character and set it going with an idle loop, but how do I add IK in the Editor, and then be able to touch and drag limbs at runtime etc?

Thanks in advance for any assistance!

 

Hi, Greg,

Place your Mecanim character in the Scene, add the FullBodyBipedIK component to the same game object that has the Animator. Make an empty game object for each limb, position them to the hands and the feet. Then assign those game objects as Targets for the respective effectors in the FullBodyBipedIK component inspector.

I'm no expert on touch input, but you probably want to move those targets relative to the camera plane. You can use Camera.ScreenToWorldPoint to get the world space position of the finger, then move the effector target to that position along the camera plane.

Code (CSharp):

1. // Get the distance of the effector target from the camera (not directly, but along camera forward axis)
2.         Vector3 planeDistance = Vector3.Project (effectorTarget.position - camera.transform.position, camera.transform.forward).magnitude;
3.  
4.         // Direction from the camera to the finger point in world space
5.         Vector3 dir = inputWorldSpace - camera.transform.position;
6.  
7.         // Move the effector target to the finger, maintaining it's distance from the camera
8.         effectorTarget.position = camera.transform.position + dir.normalized * planeDistance;

I have seen something like this already implemented using Final IK in a game called HaremMate - Illusion. It is adult content so you'll have to google for a link yourself.

Cheers,
Pärtel

 

Many thanks Partel, I will have a play over the holidays!

 

Partel Lang,

I need some help getting my characters to look at things. Right now I'm using FBIK and a LookIK, but maybe that's the wrong way of doing it? LookIK is being handled before FBIK, so FBIK overrides the rotations causing the character to not look where I want. Does FBIK have a solver for looking at things? I seem unable to find it.

I tried moving LookIK to a later execution order, but when I started up Unity again the order was reset so I suppose FinalIK does not like you tampering with that...

 

Hi,

Please see this page, the part about Combining IK Components.

Basically you can change the execution order of IK components if you Disable them at Start

Code (CSharp):

1. void Start() {
2.         fbik.Disable();
3.         look.Disable();
4.     }

...and update their solvers manually in whatever order you need

Code (CSharp):

1. void LateUpdate() {
2.         fbik.solver.Update();
3.         look.solver.Update();
4.     }

That way you have full control over the updating cycle.

Cheers and have a nice holiday!

Pärtel

 

Awesome Partel, thanks! And you too!

 

Just wanted to chime in and say thanx for this amazingly great package!
I plan on using it for a few different stuff like animation blocking (sword fight), grounding, picking up stuff and headtracking for the Oculus and its really easy to work with, have the whole item picking stuff ready and integrated with my other systems today, was a breeze!
Also a huge thanx for the headEffector script, will be of huge help!

 

Hey, Virror, thanks a lot for the kind words!
Good luck with your game and let me know if you have any questions

Btw I just received my Oculus DK2, so time to put the original DK to rest and make a few demo scenes about mapping characters to the positional tracking..

Cheers,
Pärtel

 

Cool! Super jealous, i wish i had th cash to spend on a DK2 as well, only having a DK1 atm. A demo on how to use the DK2s positional tracking would be hugely appreciated since i cant really test it myself : )