CCDIKController - Alternate inverse kinematics method for Motor6D rigs

Since you’re gonna anchor all the parts you can’t use physics (which right now seem to be causing bugs in your code). Simplifying by removing humanoid, physics, and weird default behavior you can focus on your code.

Raycast to make sure you’re not going through parts then add the current cframe to the directional cframe (0,0,1 would move you forward).

Which is why you’re anchoring the parts! :smile: The beauty of this is that the mech only needs to move on the X and Y axis, and adding onto the current cframe will move it relative to its existing position (forward is forward relative to the mech).

No problem about the questions; you stay pro as well :wink:

3 Likes

If i anchored everything i wouldn’t be able to use network ownership. So er idk what to do. It wouldn’t work as a longtime solution unfortunately.

1 Like
Advanced

Cool trick for one of these situations is to do things on the client and the server. This gives the benefit of no replication lag (client sends input to server, server receives then sends position to client VS client moves, sends input then server moves). A method that goes hand in hand with this is do all ik calculations on the client then send over the results to the server. This doesn’t have to be done every frame.

Convenient

Try to work out the bugs with humanoid, should be possible.

I may advise to try convenient since it’s less work and you don’t have to build a whole framework. Bugs are frustrating, the trick is to stay frustrated until it works.

3 Likes

Alright so I stick with the humanoid then try change some properties of humanoid? Since humanoid seems a lot more convenient.

1 Like

Sure. Try to fix the legs first, I think the supports may be causing it to spin. I really don’t know, just mess around with it 'til it works

3 Likes

Alright thanks for all the help stay safe. :slight_smile:

2 Likes

Great news on my side, and if anyone else is having similar issues, I believe iv lowered the search down to my humanoids hip height. Iv increased it to 15 where its above the ground and the issue hasn’t occurred. From now on ill always blame humanoids lol. Thanks for all the help and motivation.

2 Likes

I call upon thy once last time, honestly sorry the amount of times that I ask for help from you, the IK legs start jittering out trying to reach the goal again even though they have already reached it? I use :CCDIKIterateOnce and call it using heartbeat. Hes a vid of it happening.

robloxapp-20210804-2100018.wmv (3.1 MB)

2 Likes

Update! I have fixed the C0 formula which also fixes the bug for R6 characters @nurokoi and other types of rigs @iiau. You can find as always on the GitHub and the toolbox.

Old C0 formula:

New C0 formula:

Explanation for the new C0 formula can be found in this scripting support post.

Additionally the function tween drag debug has been updated to draw limbs between Motor6D joint for better visualization of how the CCDIK algorithm works.

local Leg= CCDIKController.new({"Stuff"})
Leg:InitTweenDragDebug()
5 Likes

Just gave a quick look to see how this new formula performs and it’s perfect, thanks for this update, very useful for the coming stuff I’m aiming to create.

2 Likes

Thanks a lot for the help! Great guy.

1 Like

Guess I was wrong lmao

image

1 Like

Great to see you still updating the module! Have 0 idea whats happening or what it does but looks cool lol.

2 Likes

When I play with the custom rig we have, the leg starts spazzing everywhere ignoring like 80% of the ball socket limits. Any Idea why?

Are you using the old version of the CCDIK module? If not then I haven’t tested it out the new C0 formula with the constraints. Then a Repro file will be necessary.

1 Like

Would you be willing to help out a little bit? We are trying to make the Footplacement work with walking animations on our custom rig but I’m not sure how to set up the constraints well, I tried ball sockets but our rig is a little complicated I think? we will check if we are using the old module. Do you have Discord?

Not an update unfortunately, just some disclaimers, issues, and tips.

The first issue is that the module was never intended to combine animations and CCDIK together. The resolving issue with the HumandMale_Model in the CCDIK file just happens to be a one in a chance fluke. What happens is that the animations is added on top of the IK which move the arm away from the goal which the IK algorithm hates and tries to fight back hence the spinning arm problem commonly seen.

Currently, there is no plan on combining IK and normal animations as it’s pretty complex, look at all these diagrams:

Also I recommend this video for additional customization over the IK with a modified CCD algorithm:

To achieve Bone priority / Motor6D priority/ which limb it iterates through more with the module you can modify the input Motor6D table.

So for example this motor6D table:

local leftArm = {leftupperArm,leftelbow,lefthand}

The algorithm will first move the left elbow, then the left upper arm ignoring the left hand as normally we don’t move our wrist when reaching out to grab an object as explained in the video.

*Unless you enable the useLastMotor property, ideal for R6 with only one limb. Though I find it a bit weird to use Inverse kinematics when there is only one limb to control which you might as well just do something like CFrame.lookAt, though I understand theres other benefits like end effector control via an attachment and the built in lerping functionality with the module.

--Within the module
function CCDIKController:_CCDIKIterateStep(goalPosition, step)
	for i = #self.Motor6DTable - 1 + useLastMotor, 1, -1 do

So to modify it we can do this:

local leftupperArm : Motor6D --Some motor6D instance
local leftArm = {leftupperArm,leftupperArm,leftupperArm,leftelbow,lefthand}

This will make the iteration prioritize the left upperArm 3 times more within the module.

5 Likes

I can’t get CCDIK to work in this example (with our without the constraints and attachments).
I tried using EndEffector which made it point correctly, but the issue is that the second part doesn’t move. Only the first one.
Some extra info if it helps in any way:

  • both are unanchored and are set to non collidable.
  • the Body is anchored (i plan on having it anchored)
  • the attachments that are at the same position are facing both the same way
  • I didn’t work either when I tried without the attachments (End Effect made a change though, now its more correct)
  • Not using the “step” parameter, nor the threshold (those arent the cause here)
  • Im using get constraints and, in heartbeat, IterateOnce

I was able to get one working with more points in a different model so I have a little experience with this module, but I still can’t get this to work.

Video link example:

https://medal.tv/games/roblox-studio/clips/wVDg9tD5yOAm6/d1337pDi29eD?invite=cr-MSxaeVQsMzcwOTA5MTks

InitTweenDebug showed this:

Hierarchy:

image

Motor6Ds and attachments:

I don’t know if it’s just not possible with only 2 parts but I’d really appreciate any help you people can give me. Thanks in advance.
Sorry for the 4 edits lol

1 Like

Set this property to true.

The explanation for the InitTweenDebug is that it’s only occuring from 1 Motor6D and the 2nd Motor6D is ignored.

The design choice is explained in the post above and the CCDIK video there.

2 Likes

Rotating arms?

I’m using armController:Destroy() upon the player going beyond a certain distance. Other than that, everything is the same as in the test game.

https://gyazo.com/f02913db42a26f6c1d4a05a94d7324f3

https://gyazo.com/5ae2d24de98b8ace3b641ac8ebf23fd5

1 Like