IK Foot Placement Setup

[toomasio]

Had a tough time figuring out the execution order of how this stuff works. So I am dumping what I figured out here in case I need to check this again and so anyone else can also benefit from this thread.

I believe all constraints work AFTER animations transforms systems, but BEFORE LateUpdate in Monobehaviour scripts. So in order to override IK positions, you will need a parent constraint to the bone you are referencing BEFORE you raycast based on that bone position.

This is a setup for ONE FOOT. You can take what you learn here and either add to the script or duplicate this process for the opposite foot. In this case I am using the left foot.

Setup (One Foot only):

Script example:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.Animations.Rigging;

public class AnimationRiggingFootPlanter : MonoBehaviour
{
    [SerializeField] private MultiParentConstraint footRefConstraint;
    [SerializeField] private TwoBoneIKConstraint footIK;
    [SerializeField] private Transform IKTarget;
    [SerializeField] private float rayYOffset = 1;
    [SerializeField] private float rayDistance = 0.1f;
    [SerializeField] private float plantedYOffset = 0.1f;
    [SerializeField] private LayerMask mask;

    private Vector3 rayOrigin;

    private void LateUpdate()
    {
        footIK.weight = 0;
        footRefConstraint.weight = 1;
        transform.position = footRefConstraint.transform.position;
        rayOrigin = transform.position + Vector3.up * rayYOffset;
        var footPos = footRefConstraint.transform.position;

        if (Physics.Raycast(rayOrigin, Vector3.down, out var hit, rayDistance,mask))
        {
            var hitPosY = hit.point.y + plantedYOffset;
            if (footPos.y < hitPosY)
            {
                footIK.weight = 1;
                var pos = hit.point;
                pos.y += plantedYOffset;
                IKTarget.position = pos;
                var tarRot = Quaternion.FromToRotation(Vector3.up, hit.normal) * footRefConstraint.transform.rotation;
                IKTarget.rotation = tarRot;
            }
        }
        Debug.DrawRay(rayOrigin, Vector3.down * rayDistance, Color.red);
    }
}

Result:

Hope this helps some people! If there is anything I messed up on please let me know!

[CaseyHofland]

I thought this was neat, but I wanted to extend the concept for hands, as well as making a few additional improvements while I’m at it.

Setup Feet

Relaxation of the ray values:
ray step = Step Height (how far the foot may move up)
ray dip = Dip Height (how far the foot may move down)
solver direction = relative ray direction

“The solver direction points upwards?” This is because the left foot up transform is the direction in which we want to cast: the solver direction is relative. This has the neat, totally unintended, benefit to work in different gravity scenarios as well.

Up = Down

You will also need to set the target offset and create a constraint, but don’t worry: the context menu has got you covered.

The new script looks a little something like this:

#nullable enable
using UnityEngine;
using UnityEngine.Animations.Rigging;

[RequireComponent(typeof(TwoBoneIKConstraint))]
public class IKPlanter : MonoBehaviour
{
    private TwoBoneIKConstraint? _twoBoneIKConstraint;
    public TwoBoneIKConstraint twoBoneIKConstraint => _twoBoneIKConstraint != null ? _twoBoneIKConstraint : (_twoBoneIKConstraint = GetComponent<TwoBoneIKConstraint>());

    public Transform tip => twoBoneIKConstraint.data.tip;
    public Transform target => twoBoneIKConstraint.data.target;

    [field: SerializeField] public Transform constraint { get; set; }
    [field: SerializeField] public Vector3 solverDirection { get; set; } = Vector3.forward;
    [field: SerializeField] public float rayStep { get; set; } = 0.5f;
    [field: SerializeField] public float rayDip { get; set; } = 0.1f;
    [field: SerializeField] public LayerMask layerMask { get; set; } = Physics.AllLayers;
    [field: SerializeField] public float targetOffset { get; set; }

    private void LateUpdate()
    {
        var direction = (Direction)(constraint.rotation * solverDirection);

        var rayDistance = rayStep + rayDip;
        if (Physics.Raycast(constraint.position - direction * rayStep, direction * rayDistance, out var hit, rayDistance, layerMask, QueryTriggerInteraction.Ignore))
        {
            twoBoneIKConstraint.weight = 1f;
            target.position = hit.point - direction * targetOffset;
            target.rotation = Quaternion.FromToRotation(-direction, hit.normal) * constraint.rotation;
        }
        else
        {
            twoBoneIKConstraint.weight = 0f;
        }
    }

    [ContextMenu(nameof(UseLeftFeetBottomOffset))] public void UseLeftFeetBottomOffset() => targetOffset = GetComponentInParent<Animator>(true).leftFeetBottomHeight;
    [ContextMenu(nameof(UseRightFeetBottomOffset))] public void UseRightFeetBottomOffset() => targetOffset = GetComponentInParent<Animator>(true).rightFeetBottomHeight;
    [ContextMenu(nameof(NormalizeSolverDirection))] public void NormalizeSolverDirection() => solverDirection = solverDirection.normalized;
    [ContextMenu(nameof(CreateMultiParentConstraint))] public void CreateMultiParentConstraint()
    {
        if (constraint == null)
        {
            constraint = new GameObject($"{tip.name} Constraint").transform;
            constraint.SetParent(transform.parent);
            constraint.SetSiblingIndex(transform.GetSiblingIndex());
        }

        if (!constraint.TryGetComponent(out MultiParentConstraint multiParentConstraint))
        {
            multiParentConstraint = constraint.gameObject.AddComponent<MultiParentConstraint>();
        }

        multiParentConstraint.data.constrainedObject = multiParentConstraint.transform;
        multiParentConstraint.data.sourceObjects = new WeightedTransformArray()
            {
                new WeightedTransform(tip, 1f)
            };
        multiParentConstraint.data.constrainedPositionXAxis
            = multiParentConstraint.data.constrainedPositionYAxis
            = multiParentConstraint.data.constrainedPositionZAxis
            = multiParentConstraint.data.constrainedRotationXAxis
            = multiParentConstraint.data.constrainedRotationYAxis
            = multiParentConstraint.data.constrainedRotationZAxis
            = true;
    }

    private void OnDrawGizmosSelected()
    {
        var direction = (Direction)(tip.transform.rotation * solverDirection);

        Gizmos.color = Color.green;
        Gizmos.DrawRay(tip.position, direction * -rayStep);
        Gizmos.color = Color.red;
        Gizmos.DrawRay(tip.position, direction * rayDip);
        Gizmos.color = Color.blue;
        Gizmos.DrawRay(tip.position, direction * targetOffset);
    }
}

[CaseyHofland]

We can use the same script for hands, with just a teeny tiny change in our setup:

Setup Hands

Nothing special here yet, but instead of creating our constraint automatically like last time, we’re gonna do it manually.

We’re going to constrain its position to “Ball”, and its rotation to how the hand would be rotated under normal circumstances. We DO apply an offset to place the hands in a more natural “holding”-position.

Et voilà!

The fingers obviously need some work but the hands snap to the ball in a holding manner, all dynamic, no tricks. Once I animate the fingers more realistically, I can easily fine-tune the holding position by changing e.g. the position offset on the constraint, or tweaking the IKPlanter values ever so slightly, daily and nightly (10 points if you got that reference). Or perhaps I’ll give the fingers IKPlanters as well, who knows what objects our character will hold right, from boxes to balls to demon babies, heck who cares about shooting 10 extra raycasts per frame if it looks cool go wild explore ta-ta!

[toomasio]

@CaseyHofland

Or perhaps I’ll give the fingers IKPlanters as well

If you try this lemme know how it works out. Thanks for your detailed approach!

[HitsuSan]

Is this really working for you? I’ve tried it but it seems like it’s flickering a lot and i can’t really figure out why.

[CaseyHofland]

We’re working on a new game where something was going wrong with the feet, so… no there’s definitely a bug in there. Unfortunately we’ve pushed it back right now since visuals have less priority over prototyping.

However the flickering I thought was fixed. Are you setting the solver direction correctly? It’s a really annoying value actually that I’d like to change as well, but it wants a normalized direction of which angle to respect when raycasting from the feet. So when your feet’s forward is looking down, then the solver direction should be (0, 0, 1) - not great UX honestly.

[HitsuSan]

@CaseyHofland

We’re working on a new game where something was going wrong with the feet, so… no there’s definitely a bug in there. Unfortunately we’ve pushed it back right now since visuals have less priority over prototyping.

However the flickering I thought was fixed. Are you setting the solver direction correctly? It’s a really annoying value actually that I’d like to change as well, but it wants a normalized direction of which angle to respect when raycasting from the feet. So when your feet’s forward is looking down, then the solver direction should be (0, 0, 1) - not great UX honestly.

Sorry i didn’t realize you had a totally different script going on from the original post and i’m testing it right now but it seems like the flicker still persist so i’m trying to figure out what’s going on. The bone direction unfortunately changes from rig to rig system so trying to figure out the direction like that is quite normal.

What is (Direction) in your script? Looks like a simple vector3 casting but you never know… ^^

[CaseyHofland]

[quote=HitsuSan, post: 8849203, member: 694988]
What is (Direction) in your script? Looks like a simple vector3 casting but you never know… ^^
[/quote]
Oh whoops that is some of our internal api so I can’t show you, but it should be pretty easy to make one yourself: it’s a quaternion that you can also use as a normalized Vector3 direction, which just makes it a little easier to do math-stuff.

In this script a Vector3 should suffice though, maybe only line 30 needs a little tweaking, I don’t remember and I can’t look into the code till after the weekend unfortunately but it should work probably.

Imma be real: not my finest professional hour this

[HitsuSan]

@CaseyHofland

Oh whoops that is some of our internal api so I can’t show you, but it should be pretty easy to make one yourself: it’s a quaternion that you can also use as a normalized Vector3 direction, which just makes it a little easier to do math-stuff.

In this script a Vector3 should suffice though, maybe only line 30 needs a little tweaking, I don’t remember and I can’t look into the code till after the weekend unfortunately but it should work probably.

Imma be real: not my finest professional hour this

Haha, not at all, we figured that out pretty quickly and you helped a lot so thanks

[cmann]

This doesn’t actually solve the problem though…
Sure you get the correct position to do the ray cast in LateUpdate, but the IK constraint is only updated on the next frame so you’re still one frame behind.