Is it just me or does the weight property not really do anything useful? Any value over 0 and it just snaps… I would expect it to not affect the animation at all at 0, and gradually increase until 1, like AnimationTrack weight works.
I can agree, it doesn’t really do what it’s supposed to.
Just what I needed for my VR game! Time to add a full body character.
Sort of, it’s used for “live”/procedural animation and intended to be used along with animations by using a “best guess” approach. For example, guessing how an arm should be bent at joints in order to keep a hand attached to a part. Your issue still is using inverse kinematics but I would guess that it’s a separate issue exclusive to the animation animator and should make a bug report.
how many poles can you use on it? just 1? Also any stress testing, will we be able to make hundreds of these without performance issues?
Thank you! Currently they don’t work for R6, since for chains with a single bone it’s almost always impossible to find a solution, but we’re experimenting with a few possibilities of how to make them look good with R6.
Yes! We still have work to do and features to add to it, we’ll announce when we publish new features! We’re currently working on the solver that runs behind the scenes so it produces more natural poses by default.
Pole
is a script-only property, it can be set via lua using .Pole
. We didn’t want to overload the interface, but it’s there for advanced users that want it. Same holds for .EndEffectorOffset
.
It works as long as there is an Animator on your character, both when an animation is playing or not.
Hi, we do support this. IKControls are NOT limited to R15 rigs, but work with ANY rig made out of parts+motors or bones.
The idea of detecting existing constraints from blender or other software is interesting, although the format and results would be different as the underlying solvers are. But I’ll have a look, thanks.
Thanks for providing the resources!
Hi, thanks for your report.
We are aware of the candy-wrap issue and working on it.
For the second issue, the “memory foam”, is because we don’t reset the pose between frames. We’re discussing exposing an option to do so. In the meantime, you can achieve the result by resetting your motors manually. Below a script.
Reset pose script
local function resetpose(character)
for _, obj in ipairs(character:GetDescendants()) do
if obj:IsA("Motor6D") then
obj.Transform = CFrame.new()
end
end
end
local function Update()
resetpose(script.Parent)
end
game:GetService("RunService").Stepped:Connect(Update)
Thanks for the info, I’ll check it out!
When messing around with IKControls, I found a bug where using attachments as EndEffector
s (when the Attachment is parented to the ChainRoot
) would send the ChainRoot
to NaN. This can be reproduced by setting the ChainRoot
to R6.Left Arm
and the EndEffector
to Left Arm.LeftGripAttachment
Viewport:
Explorer:
Left Arm properties:
IKControl properties:
(Target is the green cube in the first image)
I’m pretty sure this is due to the arm trying to move with the attachment, and they keep pushing each other recursively. Whatever the case, this limits my use case for IKControls and forces me to go back to my old workaround of using parts instead. Hope to see a fix for this soon!
You’re right, that was my mistake.
Thank you for the report, I’ll investigate.
Yes, this is intentional. Originally Pole
was exposed to the GUI as well, but we felt that we shouldn’t require devs to set the pole just to get realistic poses, and should instead work on improving the solver (still on it). We still have it available for advanced users however as script property.
Hi, this is for the old IK system in the Animation Clip Editor, which although uses the same name (IK) is not related to IK Controls. That system will be replaced with IK Controls. I’ve forwarded the report to the relevant people in the meantime, thanks!
Thanks for the reports, I’ll check them out and fix them.