Awesome! One revision to this solution though, you need to put the transform resets in CCDIKIterateOnce and CCDIKIterateUntil, BEFORE the goal magnitude check. Otherwise the transform does not reset on frames where there is no calculation because the goal is already near the end effector, and in this case the jitteriness returns.
4 Likes
Got some pretty good results!
https://i.imgur.com/Fgz7D97.mp4
If anyone is curious and needs some tips, here’s an rbxm showing how I set up the constraints for the arms. I also modified the ballsocket hip constraints from the example, because the bending backwards limit was too far. This setup seems to work pretty well, and you don’t need to set up any extra attachments outside of what the R15 rig is already using, which is nice. Character.rbxm (15.3 KB)
36 Likes
I just happened to be looking at this right now for using it on arms and a boat steering wheel and was getting the strange spinning issue alongside unnatural arm rotations.
Thank you very much my dude 
3 Likes
Do you animate server-side or are these movements only visible to the client?
I’m animating on the server currently so it replicates and it works perfect on the server, however the view on the client is offset from what I see on the server. The client’s local animation doesn’t get disabled by resetting the motor transform values on the server.
I think I’m going to have to reset motor transforms on the client too.
3 Likes
The transform resets and IK is all clientside, following the steering wheel which is physically replicated.
8 Likes
This is one of the most underrated and brilliant modules I’ve seen - really huge thanks for releasing this! My only “complaints” would be on whether you’d be able to setup more examples? I’m sure this module would gain tons of times more traction if you provided with sample footplanting code, either R6 or R15.
Other than that, I’ve no complaints! I’ll check out how this module fares in some of my projects 
3 Likes
Hey, sorry if I’m missing something, but I can’t get this module to work on my R6 character no matter how I try. I copied pretty much the exact same code as in the basic setup tutorial, but I only get some pretty weird results:
https://cdn.discordapp.com/attachments/785870115463626765/842444834614542396/mFsR6R4THn.mp4
If I add this
RunService.Stepped:Connect(function()
RightShoulder.Transform = CFrame.new()
end)
then the right arm is just permanently stuck as if it has no animation applied to it.
This is the test place:
IK_Test.rbxl (49.1 KB)
If you could help figuring out what the issue is, that’d be great.
Many thanks!
EDIT: Nevermind! Only now noticed that there is a test place attached.
EDIT 2:
For those interested in what the issue is, for R6 characters, you must set CCDIKController.UseLastMotor to true.
6 Likes
Hello everyone,
I’ve been messing around with this module and it works fine EXCEPT it’s kind of choppy when the r15 rig I am using is running.
Video:
Script
local RUS = game:GetService("RunService")
local IKSolver = require(script.CCDIKController)
local Folder = script.Parent
local TestModel = Folder.Test
local EndEffector = TestModel.HumanoidRootPart.LeftEndEffector-- Folder.EndEffector
local Motors = {}
for i, v in pairs(TestModel:GetDescendants()) do
if v:IsA("Motor6D") then
Motors[v.Name] = v
end
end
local LeftHip = Motors.LeftHip
local LeftKnee = Motors.LeftKnee
local LeftAnkle = Motors.LeftAnkle
local RightHip = Motors.RightHip
local RightKnee = Motors.RightKnee
local RightAnkle = Motors.RightAnkle
local LeftLimb = {LeftHip, LeftKnee, LeftAnkle}
local RightLimb = {RightHip, RightKnee, RightAnkle}
local LeftLimbSolver = IKSolver.new(LeftLimb)
local RightLimbSolver = IKSolver.new(RightLimb)
local CoolDown = false
local PreviousGoal = nil
LeftLimbSolver:GetConstraints()
RightLimbSolver:GetConstraints()
local function SetCoolDown(Duration)
if CoolDown then return false end
CoolDown = true
delay(Duration, function()
CoolDown = false
end)
return true
end
local function UpdateSolver(dt, Solver)
local Goal = (CoolDown and PreviousGoal) or (SetCoolDown(0.3) and EndEffector.WorldPosition)
Solver.LerpAlpha = 0.7 * dt * 60
Solver:CCDIKIterateOnce(Goal)
PreviousGoal = Goal
end
RUS.Heartbeat:Connect(function(dt)
UpdateSolver(dt, LeftLimbSolver)
-- UpdateSolver(dt, RightLimbSolver)
end)
As you can see in the video, the solver stutters a little bit when the goal is close to it. The script proves that I haven’t put any yield functions like wait() that would pause its iteration. Am I doing something wrong (like changing the LerpAlpha or something) or is there a bug that I’m unaware of? Thanks for your help
p.s: I’m not sure if I should post here so let me know if I should switch this to scripting-support thanks 
2 Likes
Sorry, I realized I haven’t made it clear that there is a parameter in the second parameter called tolerance.
CCDIKIterateOnce(goalPosition,tolerance,step)
If the limb is within stud distance goal of this tolerance it’ll stop updating as the goal is reached and reduce lag. However this also causes the limb to be unresponsive so try setting tolerance to zero.
Also you didn’t put dt or step into the step parameter as well of the iteration function so it’ll not lerp and not be smooth.
2 Likes
Thanks for the clarification! I didn’t realize there were more than one parameter on the function.
Now it works!
2 Likes
Hey, I’ve noticed that the controller performs quite poorly with R6, especially in terms of how accurate it is with it’s end destination.
Is there some way to fix this behavior?
3 Likes
The movement of the arms is dependent on two things, the joint position and the end effector.
The joint will rotate from the position of the joint, such that the end effector will reach the goal.
JointPosition modified to be at the top of the arm, with the end position located at the tip of the hand:
Resulting motion:
I believe you can try adjusting the position of the Motor6D Joint until you get the behavior you want, but with the default R6 Joint position with the joint located at the torso you will get some weird results.
For reference default R6 rig position with same end effector setup:
Someone fix his shoulder please:
3 Likes
Thank you so much for the in-depth explanation! Works phenomenally now 
I can’t get over how easy this module is to use… I’ve had so many issues trying to use FABRIK that after a week of trying I just gave up. Amazing module!
5 Likes
Hey, quick follow-up question: what is the step parameter in CCDIKIterateUntil? Is it expected to be a value between [0, 1], or is it just
RunService.Heartbeat:Connect(function(Delta)
Step += Delta
, with no clamping?
1 Like
Oh just realized having step in IterateUntil is pretty weird, never tested IterateUntil, never had any use of it for now.
So yeah step is deltatime returned from a run service according to API naming conventions RunService | Roblox Creator Documentation. It’s expected to be between [0,1] but theres a safety measure with math.min there so it should be fine, no clamping should be required.
The only function in CCDIK which needs step:
rotate joint from to with Lerp
--Controls the primary CCDIK Method but instead of going fully towards the goal it lerps slowly towards it instead
function CCDIKController:rotateJointFromToWithLerp(motor6DJoint : Motor6D,u,v,axis,step)
local rotationCFrame = getRotationBetween(u,v,axis)
rotationCFrame = motor6DJoint.Part0.CFrame:Inverse()*rotationCFrame*motor6DJoint.Part1.CFrame
rotationCFrame = rotationCFrame-rotationCFrame.Position
local goalC0CFrame = CFrame.new(motor6DJoint.C0.Position)*rotationCFrame
local lerpAlpha = self.LerpAlpha
local currentC0 = motor6DJoint.C0
if step and self.ConstantLerpSpeed then
local angularDistance = VectorUtil.AngleBetween(currentC0.LookVector,goalC0CFrame.LookVector)
local estimatedTime = self.AngularSpeed/angularDistance
lerpAlpha = math.min(step*estimatedTime,1)
end
motor6DJoint.C0 = currentC0:Lerp(goalC0CFrame,lerpAlpha)
end
2 Likes
Ah, seems like I shouldn’t really be using it then. Is there an alternate method for smoothly ‘tweening’ an arm towards a target goal? I’ve noticed the properties such as AngularSpeed, but I’m not fully sure on how to utilize them properly.
1 Like
To those interested, I made a quick and easy AnimateGoal function which works flawlessly for my intents
local CurrentlyAnimating = {}
local function AnimateGoal(Controller, Target, Length)
local AlreadyAnimating = CurrentlyAnimating[Controller]
if AlreadyAnimating then
AlreadyAnimating.Iteration:Disconnect()
AlreadyAnimating.Transform:Disconnect()
end
local IterationConn
local TransformConn
local Step = 0
IterationConn = RunService.Heartbeat:Connect(function(Delta)
Step += Delta
if Step > Length then
IterationConn:Disconnect()
TransformConn:Disconnect()
end
Controller:CCDIKIterateOnce(Target, 0.05, Step / Length)
end)
TransformConn = RunService.Stepped:Connect(function()
for _, Motor in next, Controller.Motor6DTable do
Motor.Transform = CFrame.new()
end
end)
CurrentlyAnimating[Controller] = {
Iteration = IterationConn,
Transform = TransformConn
}
end
An issue I’ve been experiencing would be the lack of communication on the API page, though. I had to look through the source to find out about the Motor6DTable property of the CCDIKController object. Other than that, I’ve yet to have any annoying issues with this module! 
7 Likes
What would be the proper way to stop a CCDIKController? Even if I stop calling any functions, the arm keeps being animated weird even after I restore the C0 and C1 properties of the Motor6D object.
What’s weirder is that I don’t even have to call any methods for the weird behavior to occur - the moment I create a new CCDIKController object, the animation for the left arm becomes off:
My code is just this:
Is this expected behavior? Because even after calling
:Destroy() this remains 
I’m assuming the behavior has to do with how you reset the rotation here:
But it seems pretty hard to restore the original Motor6D behavior nevertheless
3 Likes
It’s probably due to the C0 and C1 resets I included when creating the CCDIK controller which @nurokoi pointed out since I reset the orientation to CFrame.new() which probably messed up the direction the animations were made in.
You can probably include a method to reset it to original orientation once the CCDIK controller is destroyed.
2 Likes
Yeah, I fixed it by just resetting the C0 and C1 values back to default right after creating the CCDIKController object. Would this cause any unexpected behavior when using the Controller’s methods later on? Because I’m thinking of wrapping the CCDIKController.new method to safely reset the C0 and C1 properties back to default right after creating the controller object.
EDIT: Yeah I see what you mean by what nurokoi pointed out now - it seems like I need to nullify all rotation right before calling any CCDIK methods to fix this behavior… Really weird workaround, but it’ll sadly have to do
2 Likes