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

@jeromeWork

I tried using animations and blend states in a VR Animation locomotion package that was linked on this thread, but I didn't see any better results, the legs become animated which is fine, but the body still leans so far forward when walking its like its being dragged. When you walk slowly it seems ok to be honest, only when running it looks weird

 

@Wully Could you link to that VR Animation locomotion package? I tried finding it in the thread but these search tools aren't coming up with anything.

I'd like to give it a go as I think managing the weights based on speed might do the trick.

 

@jeromeWork
This is it VRIK Animated Locomotion.unitypackage I cant find the original post by Partel either, but it has an example blended animation attached to the pilot.

I think my problem is using the OVR player controller, since its using transform to move I think its either moving it too fast, or maybe because the example only has walking animations, they just look weird when trying to run

 

I have a character I created in iClone's Character Creator 3 and applied VRIK. Everything is working except the hand pose controller. I have default poses for the left and right hand mimicking the Oculus hand default pose and it doesn't seem to apply the new default finger positions. Attached are some screenshots of my setup. Any help would be appreciated.

 

Hey,
I have a solution for you, please import this package. Move and rotate the "Mirror" object around to see how it works.
It is done by matching the localPositions and localRotations of all the bones (hierarchies must be identical), then just setting localScale of the mirrored character to (-1, 1, 1) and mirroring the position and rotation of the root relative to the mirror. It is a better solution than mirroring the IK targets because when the avatar has some asymmetry with the model geometry or the texture (like the microphone, some pockets and the pistol on the Pilot), that will be mirrored properly too.

Hey,
Yeah, the built-in procedural locomotion was designed in the very early days of VR, when there was no roomscale and all the games were pretty much stationary, so it was meant to handle just shuffling the feet around in a few square meters space. It doesn't to A-B locomotion very well. For that I suggest you use a basic 8-directional strafing animation blend tree and drive the 2 blend tree parameters to follow the horizontal direction from the character root to the HMD. In Dead and Buried 2 we used Kubold's Movement Animset Pro. If the feet still drag behind, you could add in to the script that forces root to be below the HMD while walking. It will introduce some foot skating, but it's better than dragging.

EDIT: Didn't notice there was another page, will reply to others in a minute...

Cheers,
Pärtel

 

Hey,
Sorry, what is the HandPoseController? Is it a script I have provided here or something else? Sorry, I've made so many over the years, I can't remember.

 

For some reason I thought the Pose Controller I was using was a part of FinalIK. It's actually part of VR Interaction and VR Weapon's Final IK integration by Mass Games. I am working with that developer for a fix.

Other then that, Final IK is working very well with iClone Characters!!!

 

That is so awesome! Thanks @Partel-Lang Very much appreciate you taking the time. It works exactly as required and I've learned a bunch by looking at your mirroring code

 

Partel,
Final IK uses lots of math and I think there is a good opportunity to take advantage of Burst compiler.
It seems pretty mature these days.

Yeah, it requires Job system but it might worth it to give a try.
To me, I plan to have 100's of characters running around with FBBIK enabled it's more like a sin not to take advantage.
Also, a side benefit is that it brings a step closer ECS when it's mature.

Thanks.

 

finalik jobification is another 90$ asset work.

 

well.. if runs faster by >2x, it's well worth it.
And why would anyone want to have non-Jobs? ^^

 

Because its in preview with a lot of other preview dependencies. (Jobs is @ version 0.1.1 right now)
Its madness to maintain those. For the developer of asset and for the developer who uses.

 

There are many packages that are already using jobs and jobs itself is pretty stable.
I want Jobs because of Burst compiler and it can make day and night difference.

If you are thinking if I'm asking Entities(ECS), it's totally different story and I'm asking that.
Anyway, once we have Jobs version, I don't think it's necessary to maintain both versions.

 

Question: How can I rotate the spine of a character to bend their back in very specific ways, when using FBBIK? The Effector Offset example is sort of useful, but I want way more accuracy- Preferably I'd be able to grab individual spine bones and offset (or better yet, rotate) them to affect how the spine bends, adding sharp bends wherever I want etc.

My understanding is that the spine is a FABRIK chain? I can't see any way to grab or manipulate the chain. Nor are there any spine effectors (only the one Body effector). Per-bone effectors would work, but I can't see how to spawn new ones.


EDIT: I think the secret lies in copying FBBIKHeadEffector.cs; I can register a solver OnPreRead delegate, then change the bone rotations there.
EDIT2: Yep that's the answer. (Btw, I'd recommend a simpler script example that just rotates 1 bone; my script has like 40 lines, compared to the 400 in the above module.)

EDIT3: How can I add new effectors to a custom FABRIK chain? Say to drag the spine around, or a twisty robot arm. (Without just replacing the spine with a chain of FABRIKroots etc)

 

Hi I'm currently studying Final IK.
But I have a question, so I post on the thread.

If you look at VRIKAvatarScaleCalibrationSteamVR.cs, you need to input Trigger to calibrate.
However, different people have different heights, so the size of an object changes when calibration is performed.
Is there any way that this character's size can be corrected regardless of the height?

Example: If the object is scale (1,1,1), the person who is 180cm is (1,0.8,1) and the person who is 160cm is (1,0.6,1).

As I wondered, is there a way for the feet to stick to the floor without changing the scale of 160cm or 180cm or characters?

Can a leg also prevent ik from working?\
In References, except for the objects associated with the bridge, I saw something strange.

I'll reply you.

 

Hi! I'm currently using VRIK in our VR project. I'm wondering if there's a way to make a parent of IK body so it will be calculated localy (It seems to be calculated in world coordinates. When the IK parent moves the body is following it.). I mean I want to attach VRIK body to the ship or plane or moving platform, etc., so it will work fine.

Thank you!

 

Hey,
I have already done a lot of testing with the jobs, I have written AnimationJob versions of LimbIK, AimIK and CCDIK, also tried Animation Rigging and IJob versions of LimbIK. BUT here's the thing - they are all much slower than their old single threaded counterparts, even if used on 100 characters, even with IL2CPP, Burst, Unity.Mathematics and what not tested in a build. I know it's not something I was doing wrong because my LimbIK job was running faster than the similar 2 bone IK from Unity's own examples. It's just that there is so much overhead to multithreading itself that even an empty IK job with all the solving code commented out still performs slower than it's fully functional single threaded sibling.

Animation and especially IK are terrible candidates for multi-threading by nature because they need to work on hierarchical data structures and be solved in specific linear order. DOTS animation is gonna be faster, but I think not nearly as much as you've seen in some of the DOTS tech demos that are about moving tens of thousands of independent objects. So for now I have given up on the AnimationJobs as there is no point in using them at all. I am looking forward to the new DOTS animation tools that should be made public any day now, then I'm gonna run some tests again and see how that compares.

Hey,
You can't add mid-effectors to FABRIK and FABRIKRoot doesn't work well on top of animation due to the limitations ot the algorithm.
If it's just something in the spine that bugs you, you can fine tune the bone angles just by adding rotational offset to the spine bones in LateUpdate:

Code (CSharp):

1. public Vector3 spineRotationOffset;
2.  
3. void LateUpdate() {
4. spineBone.localRotation *= Quaternion.Euler(spineRotationOffset);
5. }

Hey,
This is how I usually calibrate for player height:

Code (CSharp):

1. float sizeF = (ik.solver.spine.headTarget.position.y - ik.references.root.position.y) / (ik.references.head.position.y - ik.references.root.position.y);
2. ik.references.root.localScale *= sizeF;

So basically you just compare the height of the head target to the height of the head bone of the avatar and scale the avatar accordingly.

Hey,
Please check out the "VRIK (Moving Platforms)" demo.

Cheers,
Pärtel

 

Ah, I see. I didn't know that Jobs has such an overhead and no one talked about it.
So there is a couple of reasons why Jobs are not faster.

1. Overhead each job adds
2. Solving IK is inherently has order dependencies.

Which do you think it contributes more to the total solver time?
If #2 is the main reason, you might want to try different algorithms trying to make it as independent as possible.

 

Thanks for reply.
Then let me add some questions.

1. When a person sits down, is the scale of the character necessarily reduced when calibration is performed?
Is there a way to keep the scale from shrinking?

2. In References to the VRIK Component, thigh, calf, foot, toes are null.
VRIK.cs says "" VRIK also supports legless characters.If you do not wish to use legs, leave all leg references empty."
If you do not use the leg, the leg floats in the air according to the HMD angle.
Is this originally?

3. If the answer to the second was originally, is there a way to use IK only with the upper body?
In VRIK Component-> Solver-> Spine, If the position weight is set to 0, the lower body is not a problem,
but the camera and the upper body have some problems.
We're going to use teleport to move, so it doesn't matter if I have no IK in the lower body.
Please let me know if there is an easy way for IK not to work on the lower body and IK to work only on the upper body.

I'll reply you.

 

No matter what I try, VRIK lags behind in OpenVR. I am using an Oculus, VRIK stays with the transform it is following perfectly but only works there. What am I missing? I've done the ""SteamVR_Settings" file in the Project Window and change "Pose Update Mode" to "OnLateUpdate"." and Script execution order.

 

@Partel-Lang

Figured out what the issue could be. If you parent a model under a hand target that is not under the actual hand bone then you get the lag(Like parenting it to the Controller (left) in SteamVR). Is there another way around that? If your frame-rate drops then you get more lag of course unless it's parented but then the object you are holding would be lagging too. I would like the VRIK bone to not lag if possible. It's not as noticeable in just a simple pilot scene but in a game full of stuff it's really noticeable.

 

On the Full Body Biped IK, how would I turn off the upper body weights above the waist? Or disable the IK above the waist?

 

First off I'd just like to say what a terrific asset this is. I've been using it for a long time and it always seems to be capable of doing just about anything.

My question is: On the FBIK component, is it possible to run part of the solver first (like legs+spine), run some other code and then update another part of the solver (like the arms)? I'm having a problem setting up a first-person rig using purely IK where the camera position is dependent on the FBIK result -> the weapon is dependent on the camera position -> the hand IK targets are dependent on the weapon position. This creates a feedback loop which introduces some jittering to the hands. I've tried to make the camera not dependent on the rig which fixes the issue, but this makes it very inaccurate to the actual head position...

 

Hey,
It's mostly 1, having to transfer the data between the managed and native parts of Unity, which is a pretty slow process. With IK that data includes all the solver parameters that can change each frame and read/write information about the character pose, so it is a considerable amount. Just copying all the required data for the job is slower than a simple IK solver on the main thread. That applies not only to IK, so before you make the effort to convert most of your game code to jobs, expecting to gain a lot of speed, you might end up wasting a lot of time and losing in performance instead. So you better be smart about which parts to jobify - a flock of birds or crowd AI or pathfinding is probably good, but IK and some other stuff like anything you might otherwise want to put inside a coroutine or some functionality that requires a lot of input/output data, might not. I should add that jobs are also much harder to debug since you don't have access to static visualization tools like Debug.DrawLine and you can easily find yourself in trouble with memory allocation issues if you are not the top expert on that.

2. Most IK solvers are heuristic by nature, meaning there is no analytical solution, the solver (such as CCDIK, FABRIK, AimIK, FBBIK) iterates a number or times to get closer to the target and each iteration requires the results of the previous iteration, so there is no way to spread them out across the threads. VRIK is probably the best candidate as it solves the spine first, then all the limbs independently. Also, more complex rigs require multiple IK solvers on a character to be executed in a specific order, like when you have LimbIK to hold a hand on a weapon and then AimIK on top of it for aiming, so that is a limitation too. That is why AnimationJobs are multithreaded only on the character level, not each job independently;

Hey,
1. Normally you would calibrate just once somewhere in the beginning of the game. Most games have a calibration screen asking the player to stand up and sometimes stand in T-pose. Usually there is also some controller button combination or a menu button for calibration. After that, you can sit down and so will the avatar.

2. VRIK without leg references was designed for avatars that don't have legs, like ghosts floating around. If your avatar does have legs, you'll need to assign them to References, because when the solver moves the spine to match the head to the HMD, the pelvis will also be moved and if the pelvis moves, the legs will have to be solved because they are parented to the pelvis. If you wish to keep the pelvis locked, you should use the Pelvis Target and set Pelvis Position/Rotation Weight to 1.

Hey,
Changing SteamVR Settings did nothing because you were using OpenVR.
OpenVR by default updates the controllers in update and before render for minimal latency. Update is fine, but if the controllers are updated again before render, that will be after VRIK has already solved (happens in LateUpdate), so you'll get this visible jitter or lag. You'll have to go to the TrackedPoseDriver that is on the main camera and hand controllers and change "Update Type" to "Update". Also make sure the Animator is in "Normal" update mode.

Hey,
Set "Mapping Weight" to 0 for the arms and make sure none of the hand or shoulder effectors are weighed in. Then also set "Iterations" to 0, that will disable the full body effect.

 

Hey and thanks!
Have you already found the "First Person Shooter" demo? It's a first person shooter rig with FBBIK and AimIK, doesn't require you to change solver order.

Cheers,
Pärtel

 

Thanks for the quick reply! I looked at the First Person Shooter demo, but ultimately I wanted to try a fully procedural approach for the arms using just IK, which is why I set out to create my own rig. Another thing I tried was running the solver again after the other code (solver -> camera -> weapon -> solver) but I'm guessing this is not how it is intended to use as it produced some very odd results.

 

FBBIK is pretty expensive, usually there are better solutions than solving it more than once per frame.
You might want to try VRIK actually. You can have a head target so you can fix the head to the camera and the hands to the weapon. VRIK also uses the shoulder bones so might look better too.

 

I've worked with VRIK in the past so I can give that a shot. Actually, another option might be to just use IK for the arms since I'm not that bothered about the body orientation based on the weapon (in fact, it is most likely part of the problem since it moves the eye/camera position slightly).

Edit: Solved it! I switched out FBIK + Look at IK for 2x Limb IK (for the arms) + Look at IK. I update my camera orientation which moves the Look at IK target, let that solver run, then using its IKSolver.OnPostUpdate I update the position of the camera + weapon, then let the limb solvers run. Does exactly what I wanted and has no jitter. Thanks again for the quick input!

 

We don't use TrackedPoseDriver, we use SteamVR_Behaviour_Pose. Do you know what to change there?

 

Hello i am trying to use Aimik with PhotonPun.. however it wont sync the position of the AImIK to the object i have specified as it seems to be updated at run time and not really sure how it is doing it. Has anyone networked AimIK?

Thanks

Daniel

 

Will there be an update to this?

 

Hey,
With SteamVR you should do the same with SteamVR_Settings, but if that didn't work, I'm not sure. Perhaps try changing when VRIK updates instead by disabling the component and calling ik.solver.Update(), maybe you can use OnPreRender to update the IK.

Hey,
How exactly were you syncing the target position? With AimIK you have 2 ways - sync aimIK.solver.IKPosition using on PhotonSerializeView or assign an already synced Transform as the IK target. Keep in mind that if you have the target slot assigned, it will overwrite aimIK.solver.IKPosition before each update, so if you synced IKPosition, but had an unsynced Target transform, it would not move.

Hey,
Sorry, I've been occupied with other parts of FIK and PM, there's just one of me so I have to prioritize. Hopefully I can pick that one up sooner rather than later.

Cheers,
Pärtel

 

Hi
I'm looking at this asset and the Very Animation asset on the store. I'm undecided which one to pick. From what I understand that one edit animations and this one creates the animations on the fly. Is there anything Very Animation can do that Final IK can't? Because I see you can bake animations on Final IK too, but I don't know how easy is to actually edit an existing animation that is not working properly or adjust it to different characters and then bake it.

 

Hi,
I have a problem,i need upper body use VRIK and lower body use Animation.what should i do?Or if there are already such modules?
Thanks

 

Hi,

EDIT: Solved!


I have an robotic arm, with 7 joints. The joints only rotate along one axis, but not necessarily the same axis.
Most of the bends have been solved, but I have some issues with this specific one.

Currently i have used the Limb IK, with a bend goal, so that the arm bends correctly, but the joint rotates to the side out of its socket.

Is there a way to constrain the rotation axis for Limb IK? Or maybe a different component would work better?



Thanks!

 

Hello- I have two questions-

What is the best way to prevent a Fabrik joint chain from reaching the target?

I have a simple tentacle like joint chain with an eyeball at the end- it works great when the Target(player) is far enough away like so...


If the player moves closer the end of the join chain (eyeball) moves to the position of the player like so..


I'm not using colliders/rigidbody on the chain- would be the easiest way?

And what is the best way to add some lag to the movement of a Fabrik chain?

The end of the joint chain is the eyeball- it tracks the player perfectly- what would be the simplest solution so that its a few steps/ticks behind the current movement of the target?

And thanks for the amazing tools ^_^

 

Hello, I know UMotion and Final IK are two different things, but I'd like to know if I could record animations in Final IK, like how you can record animations in Unity. Basically press a record button and move the transforms of the arms for example, and it would save the keyframes. I imagine the result would be much better than a creation in UMotion by someone with no experience in animations.

 

Hey,
The Baker was just added to Final IK recently. It's basically a tool just for baking procedural changes (like IK) to Unity animation clips, it doesn't have any keyframing tools (at least not yet). So you can use it for stuff like fixing aiming or fixing an arm going through the body, but it's not a tool for creating keyframe animation from scratch.

Hey,
Just set locomotion weight to 0 in VRIK. Then you will be ably to play locomotion animation on the lower body and the IK will work on top of that.

Hey,
Looks like you'll just need to add some offset to the IK target to keep it away from the player. Something like this:

Code (CSharp):

1. Vector3 targetPosition = player.transform.position + (ik.transform.position - player.transform.position).normalized;

That would keep the target 1 unit away from the player, closer to the root of the solver.. You'll probably also have to add some Vector3.up offset to keep it away from the ground.

Then for the smooth following it's best to use Vector3.SmoothDamp():

Code (CSharp):

1. ik.solver.target.position = Vector3.SmoothDamp(ik.solver.target.position, targetPosition, ref targetV, smoothTime);

Hey,
Same answer as above:
The Baker was just added to Final IK recently. It's basically a tool just for baking procedural changes (like IK) to Unity animation clips, it doesn't have any keyframing tools (at least not yet). So you can use it for stuff like fixing aiming or fixing an arm going through the body, but it's not a tool for creating keyframe animation from scratch.

Cheers!
Pärtel

 

Could the Baker fix animations where the feet either floats or sinks into the ground at certain points of the animation? For example, I have a punch animation where halfway through the punch, one of the feet sinks into the ground.

 

Perfect! Thank you for the solutions

 

Hey,
Yes, make a new scene, add in the character model, make a new AnimatorController, add an Animation State with the animation you want to fix, add the Baker, set it to "Animation States" mode, add the name of the animation state to "Animation States".
Also add LegIK and a script with a few lines of code to clamp toe height:

Code (CSharp):

1. public LegIK ik;
2.     public float minToeY;
3.  
4.     void LateUpdate () {
5.         Vector3 toePos = ik.solver.toe.transform.position;
6.         toePos.y = Mathf.Max(toePos.y, minToeY);
7.  
8.         ik.solver.IKPosition = toePos;
9.     }

Best,
Pärtel

 

Is there some reason Aim IK's weight is not available to animate in Unity's Animation window? I was hoping to ease the weight from 0 - 1 as part of the aiming animation, but it seems you can only turn it on / off, and that makes it "snap" quite abruptly.

 

Hello
I would like to ask you about Final IK.
I checked the VRIK sample on Youtube and followed the same.

1. The Pilot FBX file in the VRIK sample works well.
By the way, it doesn't work well with objects I have.
It is also unnatural to stand up.

An object using biped walking. But it's a big object.
The petite objects in VRChat seem to work well, is there a way?
The screenshot below is an object for which I want to use IK.



Is there a problem with the rigging?
This is an warning in the FBX file.



Do I know why I'm standing up and flexing my back?
And as a developer, can you advise me that it's good to do rigging this way?
Please reply, thank you

- add problem -

2. If you use a small character, is there a way to fix the camera to the eye as the camera goes over the head instead of the character's head?


==================================================================

Rigging was a problem. I solved it. By the way, I have a question.
I'm not sure if the gorilla object I uploaded as a screenshot has a problem.
I copied the head and hand bones to the controller and the camera, respectively, and set the position and rotation value.

[ A problem so far ]

1) Even if you turn your head, your body will rotate as well.
2) Stretching the arm also causes bending.
3) I don't know if the face is big, but I can see the mesh of the character little by little. ( With camera )
4) On my device, the camera is in the character's eyes.
On other devices, however, the camera is on top of the object.
Is there a way to fix the camera to the character's eyes?

Is it because the object is big? would it be ok if I created the same size as the Pilot object?
Please let me know your answer 2. and your current answer.

 

Hey,
I got a question on using VRIK together with Leap Motion. I know that VRIK does not support Leap Motion anymore due to their ever changing API, but it still like to try and use them together.

So my question is if it is possible for VRIK to not influence the hand joint that Leap Motion is using, but every joint after that. In my current setup, both VRIK and Leap work fine, except for the wrists of the hands which rotate in unnatural ways. Turning off either VRIK or Leap entirely makes the hands behave as expected. So I wondered if it was possible to turn off VRIK for this specific joint, but have not found a setting that would allow me to do so (since it might be impossible). Any answers are greatly appreciated!

 

Hi Partel,

i have integrated an VRIK Charakter in an driving car interieur.
He snaps to
SteeringWheel
SeatReferencePoint
Gas pedal
Brake pedal.

and does all the movement nicely.

From the car physic i get the

longitudinalAcceleration
lateralAcceleration
verticalAcceleration
yawAngularVelocity
rollAngularVelocity
and
pitchAngularVelocity

and i would like to set the forces to the VRIK driver so that they influence the driver.
Do you have some tips for best practice.
Or would it be easier to do it with PuppetMaster?

best,

Sascha

 

It's kinda difficult, because I don't think there is a solution yet for the wrists, but what I did was separate the hands from the arms using Blender, and I had to weight paint the bones for the hand bones to only work for the hands, and the forearm bones to only work for the forearms, like this example:

Kinda weird, but let me know if you need help with the weight painting and stuff

 

Yes, the reason is OOP and modularity actually. Animator can't access it because it belongs to the IK solver, not the IK component. An IK component can have multiple solvers (like BipedIK has) and the component itself handles only the updating basically.

But what you can do is write a little wrapper:

Code (CSharp):

1. public AimIK ik;
2. [Range(0f, 1f)] public float weight;
3.  
4. void Update() {
5. ik.solver.IKPositionWeight = weight;
6. }

Then Animator will be able to handle that weight variable.

Hey,
2. If you disabled "Plant Feet" that would lock the head to the HMD no matter what. If your character is too small, the feet will float, but you can simply scale up the root, no problem for VRIK.

If you turn your head and the body rotates too much, decrease the "Neck Stiffness" and "Body Rot Stiffness" values in VRIK Spine settings.

I didn't understand about the stretching arms problem, could you please send some screenshots or a video?

Hey,

Not sure if I understood right, but if you needed VRIK to maintain the rotation of the wrists as they were before it updated, you could do this:

Code (CSharp):

1. public VRIK ik;
2.  
3. private Quaterion leftHandRotation, rightHandRotation;
4.  
5. void Start() {
6. ik.solver.OnPreUpdate += BeforeVRIK;
7. ik.solver.OnPostUpdate += AfterVRIK;
8. }
9.  
10. private void BeforeVRIK() {
11. leftHandRotation = ik.references.leftHand.rotation;
12. rightHandRotation = ik.references.rightHand.rotation;
13. }
14.  
15. private void AfterVRIK() {
16. ik.references.leftHand.rotation = leftHandRotation;
17. ik.references.rightHand.rotation = rightHandRotation;
18. }

If the problem was the wrists getting pinched when twisted too much, you could try adding the TwistRelaxer component to the forearm roll bones if you have them or the forearm bones if you don't. Like in the "VRIK (Twist Relaxers)" demo.

Hey,
What you could try is just add those accelerations as VR camera rig offset from it's default position relative to the car.
So if you turn right, the camera rig would slide a little to the left and back when you straighten the wheel.
But it sounds like a recipe for some serious motion sickness to be honest.

You could instead apply those accelerations as

Code (CSharp):

1. ik.solver.spine.chestPositionOffset

so the chest would appear to move slightly in the direction of the G-force.

Hey, thanks for helping out fellow developers here and there, very much appreciated!!

Cheers!
Pärtel

 

And thanks for creating such an amazing product!

 

hey partel, i was wondering if there was any way to make a humanoid character to prevent body parts from going through walls and different colliders.i mean something like when my character is getting close to a wall or door collider, he automatically put his hands on walls or doors.
also what can be done for character's head?
should i use head effector?
i also provided a gif file from another game to show what i exactly mean.
is this possible with Final Ik?
http://www.mediafire.com/view/tsd8iyb3kgrz83e/gif.gif/file

 

Hey, im currently thinking about buying FinalIK/Puppetmaster.

Im trying to create a melee fighting game with active ragdolls. I tried implementing Fabrik with constraints myself, but the joint constraint part gave me the biggest headaches ever.

I got 2 questions:
1. Let's say i have two identical characters, both are ragdolls and each of them uses the same punch animation. Whats the preferred way to make one of them punch harder than the other? I couldn't find something like muscle strength in the documentation.
2. I know that unitys ConfigurableJoint component has a muscle strength parameter. Does Puppetmaster/FinalIK use unitys joint components in the background?

Thanks for any help in advance!