I’m trying to add foot-planting into my game; I don’t know how to make it look good, like how to make the foot rotate to match the raycast’s “normal” angle (which instead makes the foot point towards -Z no matter what) but that’s not why I’m posting.
I’ve found a bug with IKControls. Here, I joined the game as a taller character, then changed my character’s scaling using a HumanoidDescription. While IKControls mostly correctly positions the parts of my character’s leg at “normal” size, when I’m this small, it does…something.
It looks like it’s moving the lower leg under the ground for some reason, while still placing the foot where it’s supposed to go. I don’t know if this is just caused by having a small character (something Roblox developers might’ve forgotten to test) or if it was caused by changing sizes mid-session, but it’s still a bug that should be fixed.
Also, yeaaah… I don’t think IKControls cares about how it bends joints; Knees aren’t supposed to bend backwards like this:
It looks like IK doesn’t properly bend the upper legs, either; I have the start set to LeftUpperLeg and the end to LeftFoot, but my character’s upper leg maintains its orientation used in the standing animation (notice how it mirrors the right upper leg, both in angle and texture). Also, the knee really needs to be limited to bending backwards only; It really limits the usefulness of IKControls for dynamic footplanting if it contorts my character’s legs 99% of the time.
This is mostly fixed if you apply motor reset. I’m working on a similar system at the moment, and I simply applied this to the end of my renderstepped:
for _, m in motors do
m.Transform = m.Transform:Lerp(none, dt * 10)
end
(replace motors with list of motors affected by IK. none is a blank CFrame.)
I set up then added your code to the end of the looping function that does the raycasts and enables IK on the legs, and while I think it might be improving the legs when I plant the feet vertically (like, casting a ray straight down, and placing the foot where it intersects the floor if it does so before the leg’s full length), if I offset the IK so it’s one stud out in front of my character, the knee still bends the wrong way and stuff.
This isn’t the whole function (though all that’s really above this is the same raycasting but for the other leg, an empty CFrame definition, and all of the Motor6Ds in characters’ legs, but here’s where I added your code:
That looks about right. I’m not sure why they are bending but I intended it to only have 2 IKControls that have the chain root set from the upper legs down to the foot.
Also, keep in mind that I had a pole set 2 studs forward from the HumanoidRootPart
Aside from this, I found a bug. When disabling a Motor6D and then enabling it again (like a ragdoll), it will fail to maintain its previous position. The C0 and C1 have not seemed to change either.
Simply add an IKControl and connect it from anywhere to anywhere. Disable one of the motors and enable it.
However, I am managing the IK on the client, so that might be why. I will follow up to this when I implement a system to replicate the IK’s creation and attachments.
Edit: about 5 minutes later after just managing to create the IKs on the server, the problem is fixed.
What I had was a ragdoll script that runs on the server (disables motors) and IK on the client.
The IKControl.Weight property doesn’t do what I expect it to do. I assumed that it would work just like the AnimationTrack.Weight, but when I Tween the Weight of the IKControl from 0 to 1 or vice versa, the IK just snaps like @ThatPreston mentioned earlier. This only happens when IKControl.Type is set to Enum.IKControlType.LookAt.
I don’t like this philosophy. Please don’t hide this property just because Roblox wants to try to optimize it away with solver improvements, the usefulness of this property will never be completely eliminated, and it’s scriptable post-release, so this property is here to stay.
Hiding this hurts everyone because this bars people from conveniently setting this property to a statically defined pole instance to be used for rig testing, or to be referenced later by script, and obscures that the property exists at all, requiring you check documentation just to stumble upon it. Not to mention, if the pole is ever accidentally unset it’s now much harder to visually see this for the sake of debugging. EndEffectorOffset is for sure an advanced user feature given you can set an attachment for the EndEffector, but I don’t agree for Pole. Overall, I’m finding this being hidden is annoying.
100% would love to see a pose reset built in, I plan to take advantage of IK heavily for creatures with multi-segmented limbs / tentacles and the memory-foam like behavior is very valuable.
It looks like this helps a little bit with the spaghettification happening for this experiment I was playing with today, but not completely. Is there anything happening to help with this problem? There are 9 bones to this tail, and moving the body around without even rotating it will eventually result in this twisting deformation, even despite setting a Pole above the chain.
While I am for automating a pole system in the future, I do think allowing manual control of an IK’s poles is fairly important for both power users and those who wish to learn how to use IK to it’s fullest potential. By hiding this feature you’re unintentionally preventing somebody from discovering an aspect of IK that your automated system might not be able to fully replicate to their desired effect.
I urge you folks to reconsider, if you must automate it, perhaps do so when the poles are not set- but otherwise allowing users a degree of freedom that they don’t have to dig around for should be considered first and foremost, even if it’s initially complicated for newer users who wish to experiment.
I might be misunderstanding some of the intent, but hiding parameters from users is not a great idea as it will cause more friction in users figuring out they can use it to begin with.
There are already a lot of complex parameters in the GUI of certain physics instances that are exposed, and none of that is being hidden. It feels a bit silly to draw arbitrary lines for which GUI parameters should or shouldn’t be hidden from the user.
If you’re worried that users will think they need to set the parameter themselves manually and not understand that the solver will do work for them, it would be simpler if this information was just communicated to the end user more clearly instead.
Seems like recently the reset pose stuff we’ve been using recently got an “update” that makes it so that it will reset the transform after the IK has rendered, causing jittery motion.
I’m going to reconfigure my version to Lerp the script to CFrame.identity. Here’s an updated version:
local alpha = 0.05 --Increase if the motors are "bending slowly". Decrease if they're "lazy".
local cache = {}
local identity = CFrame.identity
local function resetpose(character)
for _, obj in cache do
obj.Transform = obj.Transform:Lerp(CFrame.identity, alpha)
end
end
local function Update()
resetpose(script.Parent)
end
--Wait half a second for character to fully load.
task.wait(0.5)
--Cache:
for _, Motor in script.Parent:GetDescendants() do
if Motor.ClassName == 'Motor6D' then
table.insert(cache, Motor)
end
end
game:GetService("RunService").RenderStepped:Connect(Update)
--Change RenderStepped to Heartbeat or Stepped if you have issues.
Written on DevForum. Expect incorrectly formatted code, runtime errors, and incorrect configuration values.
Changes:
Added a cache of the motors for performance reasons.
Changed Stepped to RenderStepped (though I’m not sure if this will cause problems)
Lerp the transform to the identity CFrame.
Changed CFrame.new() to CFrame.identity, because it’s faster.
EDIT: This is clearly a bug.
Nope, this doesn’t work after testing. The only partial solution is to set SmoothTime to 0. Also, if an animation is playing over top of the control, the animation will have priority OVER the IKControl’s target. I guess that’s why I didn’t notice it at first, because I don’t mainly use animations in my game.
The animation I’m using has a Core priority. Almost every animation in my game has a Core priority, because other priorities tended to break IKControls. Now, they do that regardless of the priority and they reject the previous behavior.
Have you guys exposed the option yet? I really need it as I am working on a lot of models with multiple joints, and they will always turn into a candy wrapper and its super annoying. Thanks!
I’m having an issue where the IK Controller just stops working sometimes. It’s very inconsistent and doesn’t appear to be based on making any sort of changes. It just works for a few test runs, then it stops when trying again later for literally no reason…
Also when it works, using the UpperArm and Hand often give unrealistic results for how the arm should bend. LowerArm and Hand works much better, but I haven’t been able to get it to work for a while now.
Edit:
I finally got it to work again by removing all of the properties and resetting them (this really should not be needed).
Here are the problems I’m having.
Disclaimer
Both gifs have a lower framerate, but it still shows the issue. SmoothTime is set to 0 for both as well.
First is using the UpperArm and Hand:
The arms are both clearly moving in an unnatural and unneeded way.
Then here’s using the LowerArm and Hand:
This looks much more natural, except the hand is now desynced from its target, which obviously shouldn’t happen.
It seems that having an extra part in between will make it sync properly, but as seen in the first gif, it doesn’t look very good at all.
Even if the parts stick to the (invisible) attachment, when the torso (of the not yet existing spider) moves the root part doesnt stick to it.
Also when I am doing the exact opposite thing:
when i am moving the lower part, the rest of the parts does not move with it. (i checked the distance between a second (invisible) attachment and if the distance crosses over 10 studs the lower part gets moved to the second attachment, thats how i create this spider movement. I really dont know how to fix this issue (I already tried welding the parts together with hinge constraints but this broke the whole ik movement. Any helps/tips would be appreciated ;-;
I was really excited to try this feature out, but it feels almost unusable for skinned meshes as it currently stands. In the video below, I’ve set everything up as necessary incl. a pole and yet whenever the target moves, and especially when the IK target extends further than the joint, the bones roll erratically and end up in what is effectively a random orientation when the target returns to its original location.
Am I doing something wrong here? I’ve seen the post about integrating constraints to IKs, but in a circumstance where a pole is already in play, I’m confused why this behaviour persists or why additional work would be necessary to suppress it.
