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.
Yes they do! let me know if that works with your rigs
We have fixed this and it will be live shortly, thank you for the report.
I figured out how to turn players into ragdolls using this new feature! They can also have animations played over the top too.
I’ve written a tutorial here:
Yes, we currently have a single pole which is used for the whole chain.
Performance was improved a lot during the beta, for reference a single IK control takes ~80 microseconds on average. Most of it it’s spent reading/writing to the rig, which we’ll improve further, but should be already fast enough.
Thanks for the report, I’ll add a fix.
I’ve discovered a CRITICAL bug (crashes every client):
Edit: this was reported by DrewDude500 above
If players/NPCs have their joints broken (which happens upon death) with IKControls active in their humanoid it will crash every single client (including the server & other players)
How to replicate this issue:
- Create a new place + insert a rig
- Insert an Animator & IKControl into the humanoid. Set the properties as you wish, as long as they are valid.
- Have the dummy die server-side or call :BreakJoints() on it.
- The client will immediately crash with an error exception.
is their any plans on adding more poles? If not, would it be possible to make limbs with multiple joints going in opposite directions by using multiple IK’s?
Edit: I was able to do something like what I was talking about (with multiple joints going in different directions) but it acts a bit weird.
You can see in the video that the rig would sometimes snap to certain positions.
Also because you can’t specify which joint the pole should be affecting and the solver doesn’t find the best solution where the joint would be closest to the pole, you can get different cases like these even though everything is the same: