Yeah, it already caught my eye too, just finished downloading it… 
I hope I can use it as a template for all my future 3rd person demos and tutorials.
If I wanted to use this to cause a character to aim at mouse cursor regardless of the mecanin animation positioning or current character position that would just be a pretty simple effector on the arm / hand right?
I’m sorry, but I’ve got something cooking in the labs that is probably going to leave a lot of animators unemployed
@Fuzzy_Slippers:
You mean aim a weapon? That would be a job for the Aim IK. Take a look at this> older video.
1 Like
How does that work if you want certain things to be controlled by a fbbik and other things by just the biped ik functions like aim ik? Does fbbik inherit all the functionality of the biped ik or do you need to attach both to a model and selectively disable them?
Good question…
FBBIK doesn’t inherit anything, basically all the IK components are fully independent and can be additively applied on top of each other, meaning you can use FBBIK to change an animation and then apply Aim IK to keep aiming at the target. Or you can solve LookAtIK first to gaze at something and solve FBBIK or whatever you need on top of that to further manipulate with the pose. That way you have complete freedom in what you are doing and you can also change the updating order of the solvers.
BipedIK is essentially little more than just a collection of solvers, you don’t need to use it if you want to just have Aim IK on your character, you can use the AimIK component instead. BipedIK can just help with automatically setting up the solvers for your convenience.
Cheers,
Pärtel
WOW! You’ve excelled yourself there Partel XD How soon can we beta testers get our hands on the InteractionIK? I’d already started to write one, but as usual, you’ve made my attempts look totally pants, lol.
Thanks, Whippets, but hold your horses with this, the thing is just a few hours old
About the new Standard Assets… if you notice FBBIK acting weird on the 3rd person character Evan, that is not a FINAL IK issue, it is the broken skinning of the character. If you remove the last (Neck) bone from the spine of the References, it will work fine. I will send feedback about this…
Cheers,
Pärtel
GodDAMNIT Partel!!! I just got a call from my current client…they saw this and said “Steven, sorry but you’re now unemployed” and I was like "PARTEEEEEEEEEEEL!!!, shaking my fist in your general direction…
…haha no seriously I have no work now, thanks.
…okay but more seriously, when we have IK Interaciton!?! 
-Steven
Heh - I’m poor at waiting XD XD - I’ll just carry on with my idles and emotes.
Something else came to mind. UMA dna let’s us add new body parts with new bones (for instance, a tail, wings, boned ears, stranded hair, etc). It would be great if we could add new solvers to fbbik to handle these new body parts, so that we can treat the body with it’s extra parts in a whole/holistic way.
I’m guessing that wings, tail, etc will be multi boned, so would act like new limbs, though with possibly different rotational constraints be bone to an arm or leg.
Really digging this. I see a lot of opportunity for creating procedural combat animations in a really fun way.
I’m also a little confused about what the ‘pin’ is doing in the Aim Boxing demo. Could you explain a bit about how it is anchoring the animation? (I took it off to see what happens when it is gone and obviously removing it makes everything goofy)
Man this plugin looks incredible.
1 Like
Yea I’d like to know what this is too…
Oh, I forgot to ask this…
…but at 1:54 you say that AimIK was interfering with the animation. You then add a few lines of code and immediately the spine begins to behave they way you expect it to.
Perhaps with the full documentation explaining what your functions do I’d grasp this easier, but for now can you explain why adding Targeting and Offsets allowed the original animation to play correctly AND still aim at the target (and why initially AimIK was interfering with the animation playback)?
Thanks Partel
Looking at how amazing this can be for animations and interaction, do you know what scares me?
That someone will swoop down and buy it up. And that’s the last we’ll see of it at a reasonable price!
Granted…the only ones who might “buy it up” would be UT.
Hi,
I’m attempting to use the Biped IK aim functionality on my character and I’m running into problems. how can I keep the aimpoint infront of my character instead of, whats happening now, is that it is left behind as he walks forward?
Ive also tried with just AimIK,
I noticed, another object is created after the aim transform. This seems to be the final in the linked system, yet it doesn’t move with everything else, warping my character.
thanks
Nice cooking Partel Did you add a new feature to do this or is it just a new demonstration of what we can already do with the first beta package ? Cause I was already thinking we can open a door and many other interaction before to buy it. But I you have added some new “shortcut” to do this, I’m happy too
Haha i am glad i never learned to animate properly and good, becouse now i have good reason why i certainly dont have to. That procedural driven video is amazing.
Ok, the way I see it, each action/interaction has 3 stages. Ping (from base state to IK state), Mid (some iterati0n of motion), and Pong (from IK state to base state).
Let’s look at an avatar stood by a console, typing (or pressing buttons). The Ping is from idle to hand over the buttons. The Mid could be a continuous loop of some button presses. The Pong would be from hand over buttons to idle).
How about a wave emote? The Ping raises the hand, the Mid rotates the wrist a few times, and the Pong lowers the hand.
Hand on hips idle? The Ping move the hand to the hips. We might not want a Mid or Pong yet - keeping the hand on the hips until we want to do something different, at which point we’d play the Pong first (moving hand from hips to base idle).
Sitting idle. The Ping would be from standing idle to sitting. The Mid isn’t used. The Pong we’d play later, when we want the avatar to stand again. In this case, we’d need to remember that the avatar is sitting, and let other actions/interactions play in the mean time; maybe typing on a console, reading a newspaper, gesticulating whilst talking, etc.
So, I can see a need for the ability to play just one or more stages of the action/interaction, or continuously loop a stage. I can also see the need for the Mid stage to be made up of either none/a single/multiple elements.
Did any of that make sense?
Since I’m located almost exactly at the other side of the globe, the general direction to shake your fist to would be Vector3.down
Those two questions are actually about the same thing… First, let me explain you how Aim IK works. Basically it is just bending and twisting a hierarchy of bones (that you assign to the “Bones” of the component) so that a child of that hierarchy (the Aim Transform) would be rotated to the target direction.
Imagine aiming a gun for example. Let’s say you have a static aim forward pose and the AimIK component set up so that the gun is the Aim Transform and the spine bones are assigned to “Bones”. Now if you move the AimIK IKPosition around, it will take the FromToRotation from the animated direction of the gun to the desired target direction and bend the spine accordingly. Thats the normal use case for Aim IK, that it was designed for - keeping something directed to a position at all times.
That works fine with aiming guns, because you are supposed to keep the gun aimed at something when you shoot it. But with sword swinging or boxing, we can’t use that solution, because those animations have spine movement and if we keep the last bone of the spine fixed to a direction with AimIK, it will obviously change how the swing looks.
We don’t want that, we just want to use the animated swing by default and only bend it when the target direction is different from the default direction. Thats why we need the pin - the direction to the pin will be our default direction.
We can make it the default direction by making the Aim Transform look in the pin direction before Aim IK solves, so when it does, and if the target position is the same as the pin position, it will find that it has nothing to do, because the Aim Transform is already looking at the target and the animation remains unmodified. But if we now offset the target from the pin, the directions are different and AimIK will bend from default direction to target direction.
I know its mind boggling shit, but it works, and can be quite helpful at times
If it’s still too confusing, let me know, I’ll try drawing a scheme or something.
Hi, Tonmeister, and welcome!
That’s how it’s supposed to work, you need to tell the solver where to aim or look at, or where to put the hands and feet. If you don’t, they will remain where they were at Start().
There is no object created after the aim transform, it is the scene view handle for the target for your debugging convenience. You can change where to aim at by:
public AimIK aimIK;
void LateUpdate() {
aimIK.solver.IKPosition = something;
}
…and don’t forget to include the RootMotion.FinalIK namespace.
Hope it helps,
Pärtel
That was just composed using the same package that you guys have, you can already do the same if you like.
Thanks, but animation skills are still useful…just that with the interaction system, you can animate the object instead of the character :).
For the demo, I animated the button and the door and the cigarette, and the effectors will just be pinned to those animated objects. Thats what drives it.
Cheers,
Pärtel
Yes it makes sense, thank you for the thoughts, I’ll try to make it as modular as possible