Likely you’ll need to annotate your animation with events so you know when the foot is supposed to be planted. Not sure how you’d do this with non-custom walk animations though, you might be able to make an educated guess by measuring distance between the foot and the floor to detect plantedness. When the foot is planted, you should raycast (some distance above the foot, downwards to mitigate clipping) to determine the positioning for the foot on the floor, then move the target there, each frame for the duration of the planted portion of the animation. You can use the transform mode to match the orientation of the foot to the normal of the floor.
Haven’t tried this myself yet so this is just a rough idea. Note also that there might be timing issues with raycasting for the foot position from the raw animation position before the IK is applied, so you probably need to use a specific event to do this properly. I think RunService has several events, but I’m not sure when the IK calculations happen so you might have to experiment.
I’m trying to get this to work with my custom characters and I’m not seeing the instance have any effect (or any effect that doesn’t teleport body parts somewhere else) on some of my characters. These are old characters that were built manually rather than imported that I really do not want to try to redo through the importer.
What are the particular character requirements? I.e. the required naming of attachments, motor hierarchy direction (e.g. the head contains the motor connecting it to the torso, or vice versa), required children of instances (e.g. originalposition, originalsize), or god forbid part names? These kinds of details are annoyingly never documented.
Aside, definitely need a way to offset the EndEffector in local space. This is a lot more intuitive than offsetting the target.
How did you achieve this effect? I’m raycasting from the player’s feet as well but I’m getting really odd results, and it completely overrides the walk animations.
You can achieve the behavior you mention about anchoring joints by using the ChainRoot property. That specifies the upper-most joint that can be affected, so if you don’t want the UpperArm to move, you can set as ChainRoot the LowerArm and only that + the Hand will.
The reply by @PeZsmistic is spot-on.
You can create custom animation by animating the Target and/of Offset property as you wish.
For the foot-planting, the suggested solution is exactly how we also do it, using raycasts to detect the ground point and normal. We’ll release a script for foot-planting soon.
The IK solver runs after the animation step one but before physics. It happens right after the RunService “Stepped” event, so you can use that to do your computation.
For characters using Motor6D, we currently require a setup similar to how R15 are:
a MeshPart (e.g. Hand) that has a Motor6D under it (e.g. Wrist) should have that Motor Part0 be the parent part (e.g. LowerArm) and Part1 be the part itself (e.g. Hand).
That’s the way we currently walk the hierarchy but we’re working to make it so that any setup works. I’ll make sure to document as you suggested.
we don’t have any other requirements, but if the part are named like an R15, we detect when you are working on an arm or leg and automatically make it bend as you would expect without the need to set a Pole manually.
@sg3cko Are there any plans to add “easing time” or lerping as a property to the IKControl instance? Use case : Dynamic headlook at objects. Currently, if you make a character look at an object, the IK rig “snaps” to the object instead of smoothly transitioning to the look, as seen below:
What about replication? Currently if done from a local script, IKControls will not replicate to server. Doing everything on a server will be pretty heavy on performance, for example when you raycast every frame for foot planting.
Is there going to be an official solution for replication, or should we implement ours?
Sounds good, thank you! Would definitely appreciate this system working with motor6Ds parented any which way, but I will experiment after work and see if I can get my old rigs adjusted with this information.
Do you think there are plans to support custom poles with e.g. attachments? This would be very helpful for me.
Given that I keep running into undocumented problems with obscure character requirements for related features (e.g. character scaling, this), I’m starting to think I need to write a plugin to automatically fix wrong setup. Pretty sure I have to have to flip a lot of Part0/Part1 properties and reparent everything (and probably kill all of my animations…). Would be nice if Roblox had some rigging tools built in that kept everything consistent with how characters are supposed to be set up; it’s very easy to make mistakes.
Further, if you rotate your automatically generated rig attachments for any reason, god help you if those scaling values on the humanoid change. Do you happen to know how these are generated from the motor6D transforms when importing? I need to write something to fix these automatically.
IMO you probably want to run this on the client according to character distance from your camera. You won’t notice details like footplanting from far away.
I was personally hoping the adjusted positions would replicate like animations / character parts moved locally, and maybe they will later, but it’s not the end of the world if not.
YESSSS!!! I’m so happy to see that this new IK instance is compatible with R6! I am personally not the biggest fan of R6, but there’s no denying that a large portion of the community loves R6, and having R6 compatibility in mind with big updates like this definitely deserves some cookies
(Attachment being in the very right part selected in the image of the rig)
However, it teleports the very right part selected in the image to a far coordinate. Why?
