FULL BODY IK, Mech Spiders and much more about to hit the Asset Store!

The way you prefer to implement emotes is entirely up to you and depends on the specifics of the use case. The way I'd do it, I'd probably create an abstract EmoteBase class that has the StartEmote() function and all the other common functionalities. Then I'd make EmoteWave (and EmoteHug, EmoteClap or whatever) class that extends EmoteBase and handles all the animation and IK for that emote. Then I'd need something like AvatarEmoteController that has a reference to all of those emotes and that the server can call StartEmote(EmoteType) on.

Yes you can use Final IK with Unity free.

I cant give you an ETA, it is software development and you know it's always full of surprises and it is not even entirely up to me since it has to pass AS submission too. I've had a couple of setbacks (not related to Final IK), like I have to move out of my rental apartment and find a new one, with the warm moist winter it has become full of mold, but the development is still on full steam and if all goes as planned my todo list will run out sometime next week.

I will, and once it's submitted, I'll switch to making tutorial and workflow videos so you got something to start with.

Cheers,
Pärtel

 

Would it be a good idea to use animations that control certain points in IK (the hands, feet, etc) and let IK move the body to handle the rest of body movement? Or would it be better to actually script the movement of certain body parts via tween or whatever? Animation already supports events.

How does this compare performance wise to the legacy or mechanim system? I know this is vague and may not have a definite answer, I'm just wondering if it could be used for animations for a reasonable number of characters instead of legacy or mechanim animations, or if that is really not the purpose due to the computations involved. I can definitely see how it would be great for an emote system, but I'm just curious to what extend it can replace the existing systems for routine animations.

 

I want to show you my full body IK attempt. I'm integrating it into BMX The Game. I was working on it before Final IK announcement.

[video=youtube_share;HFzUqzJHk-s]http://youtu.be/HFzUqzJHk-s

I can't wait to see what can I do with Final IK, but it seems that it will help me a lot with my physical driven animation system. So here's my application as Final IK beta tester !

 

Cheers for the tunes on that long one Partel, when this is finally out and i've purchased it, i've had an idea that will amuse you, make all the hard work worthwhile for sure

 

FBBIK is not supposed to replace the existing animation systems, but to complement them and provide flexibility of animation. Therefore it's intended use is not animation authoring, but editing and manipulation, although you could do authoring to some extent as well.

Well done, looks like you got most of it already

Haha, what is it? I cant wait

Anyway, Ive been cleaning up demo scenes, so it's been quiet with the video uploading, but I sure got something interesting for you people coming up, so stay tuned

 

Let's say frequency analysis and an ik system like this could make for funky disco bedfellows!

 

1) Fantanstic work you've done there. Man, you will be a hero when you put this on asset store for a decent price.
2) I am making a ballroom dancing game. I tried to do FABRIK, but got stuck on the constraints. I have deadlines so I gave up having full body IK on my game. You sure have my money on your asset if you deliver within a month (deadlines, always deadlines).
3) Any hints on making constraints on FABRIK? I couldn't figure this on just by the paper explanation.

And, again, you have my respect.

Cheers from Brazil,
Rubem Medeiros

 

Haha, that sounds funky indeed

Hi, Kukamed
Constraining FABRIK was indeed one of the most difficult tasks, that is because the solver works both ways and so will your constraints need to be working identically both ways. I implemented the constraining logic as in the paper, only to find that Dr Aristidou had probably not been very thorough with testing the algorithm under heavier constraints and it did not have nearly the stability and continuity of CCD. (It could not really if you think of it, CCD solves in orientation space, FABRIK solves in position space, it does not make sense for it to perform better with orientation constraints). As you see from the paper, all examples are made with very long chains and only angular/elliptic constraints. The problems however occur with shorter chains and constraints with less DOF, like hinge and twist limits - unfortunately the kind of chains that are the limbs of biped characters. I eventually ended up borrowing a bit from CCD to improve the constraining of FABRIK .

If you wanted to make a FBIK solver of your own, I can tell you, constrained FABRIK as in the paper will not be sufficient. I already tried it, it does not have the consistency to tame the full range of character animation. The solution I ended up with in my FBIK is actually a hybrid solver of 3 different algorithms .

 

Partel, what sort of internal array of bone transforms does FBIK have? Working with UMA, I've got various functions for blinking, winking, and some jiggles, that require an internal array of bone transforms, as we have lots of extra bones and adjustment bones in UMA. So I'm wondering what the best system is to marry the two together.

 

I got a class called BipedReferences. It contains:

Code (csharp):

1.  
2.  
3. /// <summary>
4. /// The root transform is the parent of all the biped's bones and should be located at ground level.
5. /// </summary>
6. public Transform root;
7.  
8. /// <summary>
9. /// The pelvis (hip) bone.
10. /// </summary>
11. public Transform pelvis;
12.  
13. /// <summary>
14. /// The first bone of the left leg.
15. /// </summary>
16. public Transform leftThigh;
17.        
18. /// <summary>
19. /// The second bone of the left leg.
20. /// </summary>
21. public Transform leftCalf;
22.        
23. /// <summary>
24. /// The third bone of the left leg.
25. /// </summary>
26. public Transform leftFoot;
27.        
28. /// <summary>
29. /// The first bone of the right leg.
30. /// </summary>
31. public Transform rightThigh;
32.        
33. /// <summary>
34. /// The second bone of the right leg.
35. /// </summary>
36. public Transform rightCalf;
37.        
38. /// <summary>
39. /// The third bone of the right leg.
40. /// </summary>
41. public Transform rightFoot;
42.        
43. /// <summary>
44. /// The first bone of the left arm.
45. /// </summary>
46. public Transform leftUpperArm;
47.        
48. /// <summary>
49. /// The second bone of the left arm.
50. /// </summary>
51. public Transform leftForearm;
52.        
53. /// <summary>
54. /// The third bone of the left arm.
55. /// </summary>
56. public Transform leftHand;
57.        
58. /// <summary>
59. /// The first bone of the right arm.
60. /// </summary>
61. public Transform rightUpperArm;
62.        
63. /// <summary>
64. /// The second bone of the right arm.
65. /// </summary>
66. public Transform rightForearm;
67.        
68. /// <summary>
69. /// The third bone of the right arm.
70. /// </summary>
71. public Transform rightHand;
72.        
73. /// <summary>
74. /// The head.
75. /// </summary>
76. public Transform head;
77.        
78. /// <summary>
79. /// The spine hierarchy. Should not contain any bone deeper in the hierarchy than the arms (neck or head).
80. /// </summary>
81. public Transform[] spine = new Transform[0];
82.        
83. /// <summary>
84. /// The eyes.
85. /// </summary>
86. public Transform[] eyes = new Transform[0];
87.  
88.  

Head is optional for FBBIK and eyes are not used.

 

Thanks Partel I'm wondering whether to extend FBIK with an UMA class to do all the extra things (keeping all IK/transform alterations) together inside FBIK, or to have a separate UMATransformations class that calls on both UMA and FBIK. I don't want to reinvent the wheel, nor to keep yet another local set of bone transforms, when many exists already (in BipedReferences, and UMAData and UMASkeleton).

So far, I have the following functionality, which is head based, but I want to add all sorts of IK emotes/movements to it as well (such as ear scratching, head scratching, various arm/hand gestures, etc)

AutoBlink, BreastsJiggle, BreastsConstrained, EyesClosed, EyesHalfClosed, EyesOpen, Wink, Blink, Shock, LookLeft, LookRight, Watch, LookAt

 

This whole project looks amazing! Great job!

 

Don't extend FullBodyBipedIK, you will lose the custom inspector and its generally not good to directly extend classes that are being maintained externally if you can use the API instead. While I can take care of maintaining the API so it does what it does, it is impossible for me to foresee how anyone might extend the class so you risk with your stuff getting broken when I change something in the future.

You will get very low level access to the solver updating process through delegates, so you can even change things between solver iterations. That's how I've planned it to be extended anyway.

 

neat

 

That sounds great. I'll look at an UMATransformations class that works with both UMA API and FBIK API

 

Thanks for the hints. It's a shame FABRIK doesn't deal good with constraints for a FBIK. FABRIK is efficient, maybe it must be better for tails and snakes yet.

I will sure make a FBIK when I'm done with the game I am working right now. But don't worry, I don't intent to make a similar tool. It's just that making those kind of things is sometimes way better than playing games. I will still prefer using your implemmentation for IKs for game dev, it seams far more complete, better, faster and easier to use than what I would make on my spare time.

 

Those videos are very well put together in a professional manner. Jaw dropping to da floor

 

I spent some time a couple years ago building my own limited system... mainly just for integrating ragdoll and partial ragdoll on my custom characters. But it was half baked, and bugged out, and I gave up on updating it any further. But this project of yours looks incredible... can't wait to see it up on the asset store!

 

new video!

I forgot to mention in the video, that the offset pose definitions like tilt left and tilt right can be shared between the characters.

Cheers,
Pärtel

 

Nice one Partel XD - Is there anything that FBIK can't do in a jaw-dropping way?

 

Wow, this is amazing.

 

Now I've seen what FBIK can do, and having built a set of emote functions, I'm thinking of changing tack from having dozens of different idle animations (for different races/gender), I'm going to use my emotes + FBIK to control *all* idles, with only a single stationary breathing idle animation. Can't wait for the beta to work in some body IK emotes to go along with my facial ones.

 

Something that somebody asked for a while back, finally got to it

 

Wow Partel, awesome like every video

I'm saving money for buy it and waiting for the release ^^.

 

Hit Reactions....Sweet!

P.S. Hurry Partel!! Haha...how many tasks left brother?

Cheers

 

Jesus another awesome thing i would need for project, bone affecting damage. Ok i am setting up bitcoin mining comp so this should be first thing to buy with its profits.

 

yeah I'll need that too, ...

holy S*** this Final IK isssss AWWWSSSOOOMMMMEEEEE, ....

wah wah wah why can't I get it?!?!? :cry:

how much time till release?
how much tasks till release?

 

Hold on, 26 to go . The biggest work left is cleaning up all the demo scenes and scripts I've made over the last couple of weeks. Other than that, it's basically just icons, formatting the package and final review. Once I get it submitted, I'll switch to making tutorial and workflow videos and improving the user manual and documentation so you got something to start with.

In the meanwhile, check out this video

 

So tasty...mmmmm

 

now THAT is all i needed to see

The robot and pterosaur pretty much nailed it for me (animating flying things, naturally and gracefully is an artform). Look forwards to a bunch of money

 

Nice Partel...Lazy just said he's giving you a bunch more money than you will actually charge...sweet deal man and very generous of him huh?!!

 

Hah on your bike, i live on the generosity of others, ill find the means to give Partel his price, i'm just assuring him the rest of you folks will be throwing money at this too"

 

Oh I know man, haha

 

Just... take my money. Please.

 

lol XD

Workflow tutorial is going to be very interesting to see, especially for coding things done over time.

 

Yup.

 

I watched all the vids.. amazing! If you didnt know it already, you are really good! I liked the PuppetMaster demo very much. So you gonna learn GA, and rewrite it all? Damn, that is gonna take some time ..perfectionist i suppose ..any change to get current version to assetstore? I know i would love to play around with zombies, and i'm sure many others would have fun with it. Just add a disclaimer, its ..what it is.

I hope you dont get too much pressure from all of us

(youtube: The Seeds - Pushin' Too Hard.)

 

PupperMaster is currently in broken state and not ready for real use yet, I'm really looking forward to creating some kind of a crazy zombie smasher with it though, maybe I'll put together a team for that when I get to it

...oh and thanks for the musical interlude btw

 

How about a fully IK-driven sword swing?

 

Page 5.

http://forum.unity3d.com/threads/21...Store!/page5?p=1460338&viewfull=1#post1460338

 

Oops. Although I admittedly missed that, not quite what I meant, that's just using an animation clip and transferring the force of the swing... I meant fully IK driven sword swinging without animation.

There are only so many retargetable sword swing animation clips out there, it'd be nice not to have to rely on them and to be able to create an innumerable amount of different types swings just by moving effectors around.

 

What about blending between different swipes (or even different animation that could be useful)? It's made ridiculously easy with mecanim. I'd use this in your context to add 'physically aware' animation at runtime, like using it to control animation based on collisions and wotnot. You'd get your variety there

This seems like a ridiculously trivial thing to ask for a video for but im assuming you could have an effector override a strike animation if a sword were to clash with an object (Or triggered by any number of events)? My most clear example would be like when strikes that hit walls rebound in dark souls

 

I don't think animating effectors in Unity and somehow linking that with Mecanim so it would call those effector animations would be any easier than just animating the character in your favorite 3D app. With Final IK however, you can just create 1 swing animation from the left and 1 swing animation from the right if you like and use IK to turn that into a sword fighting system in which there is never any repetition at all. I mean you can use FBIK effector offset to make the character do a crouching swing, change the angle or the radius of the swing, absorb motion on impact like in the video, you could also use Aim IK to manipulate that swing to the left or right or up or down. You could even turn a 1-handed swing to a 2-handed swing by connecting the other hand's effector to the sword or vice versa, release the other hand from the sword to do something else. You can follow the same logic with blocking animations, I mean you can make a single blocking animation and pin the shield hand to where it should meet the sword... Or you could have a sword fighter grab his opponent's sword and have them rumble about it, but thats quite advanced stuff already... Im just coming up with these thoughts as Im writing this, so you see I could carry on making videos of Final IK in action forever, but then I'd never have the time to actually release the damn thing

 

I actually already do it, just using mecanim's hand IK... I'm animating the effector with the legacy animation system, though. I just find a sequence of 3 points and rotations for the effector that make a good slash movement, make an animation clip out of it with the legacy animation and apply it to the effector. It looks alright, but since the mecanim hand IK doesn't use other bones to lean/crouch etc. to try and reach the effectors like your FBIK thing, I can imagine it would look worlds better with Final IK.

But you're right, I'd prefer you work on releasing it, rather than waste time showing me what I already know I'll be able to do with your system

 

Not sure if this has been asked already here, but will this system have a built in solution for IK foot placement for moving over uneven terrains/stairs etc? I have used a few different IK solutions before in Unity that were great, but when trying to use them for foot placement it was a nightmare!

 

I have a solution, but it still needs a bit of work so it will not make it to the beta, but it will be there in a (near)future update

 

You can check video on first page that shows it on "spider".

 

I actually thought the "spider" video shows foot placement using this system. So is the functionality on the spider not going to be available in the release?

 

The spider video is not about foot placement, its fully procedural animation using IK, meaning there is no Mecanim/Legacy animation on the spider. You are probably looking for a foot placement system that can be used on human characters on top of their animation? Thats the thing I was talking about, that still needs some work. The spider demo will be in the release, but it's not meant to be extend to human locomotion just like that.

Cheers,
Pärtel