Character Animations Overwriting Inverse Kinematics

[madattak]

I’ve created an inverse kinematics system to control the characters arm. The system outputs a CFrame for the upper and lower arm which is correct, but applying the appropriate changes to the Shoulder and Elbow joint motors in the character doesn’t work, as the default character animations still cause the arms to move around. The motors C1 property is set as so every frame:

ShoulderJoint.C1 = UpperArmCFrame:Inverse()*ShoulderJoint.Part0.CFrame*ShoulderJoint.C0
ElbowJoint.C1 = LowerArmCFrame:Inverse()*ElbowJoint.Part0.CFrame*ElbowJoint.C0

Where UpperArmCFrame and LowerArmCFrame are the desired world cframes of the respective arm parts. This code works fine if it’s being applied to a motor not being controlled by animations.

The grey blocks are parts that are set to the output CFrame of the inverse kinematics system, they represent what the players arm should be doing. However it can be seen that while the players arm vaguely follows where it should be, the character animations still seem to be affecting it. I have tried using .RenderStepped, .Stepped, and :BindToRenderStepped at various priorities. Blanking both the C0 and C1 of the motor each frame does not fix this problem, and the arm will still wave around, just beginning from the middle of the torso instead.

I don’t want to delete the joints and just set the CFrame directly as I may still need to use regular animations at times.

EDIT: I also tried setting Transform to a blank CFrame, but that made no difference. Here’s what happens if you pull out all the IK code and just replace it with this:

		ShoulderJoint.C1 = CFrame.new()
		ElbowJoint.C1 = CFrame.new()
		ShoulderJoint.C0 = CFrame.new()
		ElbowJoint.C0 = CFrame.new()
		ElbowJoint.Transform = CFrame.new()
		ShoulderJoint.Transform = CFrame.new()

https://i.gyazo.com/7685741964c2aabaa1b1d4e775d18e7c.mp4
Notice the arm is still animated, even though all the CFrames of the motors and being blanked every frame

[xLinkTijgerYT]

Hm. I can’t really think of a solve to this.
Maybe add a small part with cancollide off welded to the IK part and the uppertorso?

When I tried making it it worked in fact, until I put it in my other game.

[MrGreystone (Grey)]

I can give you a solution. Not necessarily the best but it works. My theory is inspired from scrupulous observation of @badcc’s IK work on JailBreak;

where I concluded after nefariously using stats data in a dead server;
https://developer.roblox.com/en-us/resources/studio/Studio-Shortcuts

that an additional rig was being introduced. Note here in Figure 1 that the second frame is after equipping a mesh-bodied weapon that would reasonably contain no more than half a dozen parts. If I’m correct Moving Prims can be expressed in Lua as:

print(workspace:GetNumAwakeParts()) -- prints the number of 'awake' parts

and hence I made for no delay when taking these photos to apprehend physics sleep’s chances to confound my measurements.

Here, down below is my own interpretation of what such a system would look like, seemingly redundant but that’s with good reason: we’re giving the Roblox developer full control over the behavior in this system free of any lurking variables.

My only caveats:

• You’re going to have to mark the transparent limbs into a rayIgnore bin and switch them out with the surrogates every time the user changes equip state.
• To preserve zoom-relative transparency of the surrogate limbs you’ll have to tinker with the TransparencyController in Camera under StarterPlayerScripts.
  • This is done by taking the CameraScript obtained from studio test → play mode and using the modified copy to displace the auto-loaded one.
• This is CFraming the surrogate limbs. So you’re going to have to process the output of your IK calculations from the angles to transformations relative to the limb dimensions. This can make for a redo or a convenience depending on what you have thus far produced.

If you nonetheless forgo my seafaring advice of superlative rationing I’m left to give but cautionary tales of the many persons sent to watery graves by The Humanoid. If you manage I’d presume your going to have to outfit the current character core Animate script in-effect creating a game rigid to the frequent updates it tends to receive.
(Introducing the "Avatar Evolution" Studio Beta Build! comes to mind in particular.)

Oh and if I ever have to do live IK again I’d see if I could reverse engineer Roblox’s Animation Editor plugin first. Sanity checks for quirky solutions? Not fun. So I never got rid of them. (Seen above during secondary equip?)

[madattak]

I eventually decided to do something similar and just delete the joints when the IK system started, and return them when it’s finished. New humanoids can’t come soon enough!

Edit: Urgh. So what I thought was NaN errors flinging my arms into the void, actually turns out to be an inherent part of Humanoids. Because of course it is. Why would Humanoids ever be easy to work with? Humanoids delete any limbs that have been disconnected after a seemingly random interval, so this method does not work.

Edit 2: for anyone reading this in future, the best I could come up with is basically Greystones solution, with the caveat that limbs in the separate IK rig, which has no humanoid in mine, are still connected via motor6ds to benefit from the efficiency of the transform property