Free R15 IKPF System (Inverse Kinematics Procedural Footplanting)

Open Source IKPF System

Derived from @Scarious’s code, revamped by @iGottic

What is IKPF?

IKPF (Inverse Kinematics Procedural Footplanting) is world-influenced animation done entirely in code. Inverse Kinematics (IK) is a series of mathematical calculations done to “guess” how parts of a limb should appear based on an origin and vertex. Procedural Footplanting (PF) is hard-coding animation, typically influenced by the direction the character is moving.

You may also know that as “IK Animation,” “Phantom Forces Animation,” or other community-dubbed names.

What does it look like?

Well, thanks for asking! Looks like this:

Don’t like the default animation? Don’t worry there is lots of customization available to change :slight_smile:

How do I get it?

You can download the system from the library here.

You can directly test it in the demo place I provide:
IKPF.rbxl (53,0 KB)

Module Documentation

-- '*' Symbol means the parameter is optional
[IKProfile] Module.New(Instance Player, Double Stride*, Double CycleSpeed*, Double MaxRenderDistance*, Double RaycastOffset*)
-- Creates an IKPF profile based on a player inputted.

[Boolean] IKProfile:IsActive() -- Checks if the profile is active
[Void] IKProfile:Enable() -- Enables the profile (done so by default)
[Void] IKProfile:Disable() -- Disables the profile
[Void] IKProfile:Destroy() -- Destroys the profile
[Void] IKProfile:Update() -- Plays the next frame of the profile

Attribution and Credit

You are free to use this resource on any of your games with giving credit in the description. However, the script source must always contain the following information:

  • The original script creator (Scarious)
  • Credit to original changes (me, iGottic)
  • A list of changes you or your organization made to the script

If the following conditions are not met, your edits to the script may not be distributed.
Otherwise, you’re in the clear!

Thanks for reading, hopefully you find this useful!
I’m open to answer questions, comments, and concerns in the replies below :heart:


Yeah that was some pretty old code, nice work on updating it!


  • Use the surface normal of the already cast ray to calculate the angle of the foot, and do not send CFrame values over RemoteEvents, see below for a method I would use to properly replicate this animation between clients.

A few things I might add though are:

  • You can use the surface normal of the raycast and calculate the angle of the foot to make it seem like the foot is actually on the surface. Not necessary but it would be pretty cool to add.

  • Something that is necessary, though, is that if you want to replicate this properly, do not try and send CFrame values over RemoteEvents, this will result in terrible networking (you would effectively be sending 4 to 6 CFrame values per step, especially considering that you would have to fire the event every frame (yikes) to make it “smooth”, and even then it wouldn’t look quite right. What you can do instead is go through each player in game, check their distance and whether or not you can see them. You will then use this to figure out some sort of render priority system which determines the wait time between animation updates. This might not be necessary if you have a small amount of players, but it will definitely increase performance substantially as more and more people are in the same server.


I handle all players on the client. This script is placed in StarterPlayerScripts.

Yea, that would be neat!

I am also thinking of integrating it with the developer’s animations. @ICan_RBLX mentioned using Motor6D.Transform to do this. Some experimenting will show if this is easily achievable or a pain (who knows, Roblox’s animation system sucks either way).


This part was more of a warning to fellow programmers that might want to edit this or make something similar, the main focus was on how you could go about improving the replication’s performance by “weeding out” unnecessary calls to the solving/footplanting methods. For instance, if you had a game with 30 people, calling the footplanting method could take anywhere between 0.0004 and 0.001 seconds, which is 2.4% to 6% of the amount of time between frames, which as you add more and more things to your game, could cause some problems. Raycasts are rather inexpensive in comparison, and using them for some sort of render priority system would greatly improve performance as the amount of people in-game increases.


I could make IK not be calculated if the character is outside the player’s view?


That could also work, just make sure to account for the possibility that something off screen (the humanoid center) still has a part visible on screen (for instance, a leg). This is just a matter of slightly increasing the boundary for what is considered “in the player’s view” , and shouldn’t be too much of a change.

I remember using something like this to check if something is on the players screen when I made a chunk-based rendering system before StreamingEnabled was really a thing:

if -camera.CFrame:PointToObjectSpace(POSITION VECTOR3).z > 0 then
-- visible on screen

Not sure if this is fully up to date nor fully accurate, since it’s a few years old.


That code doesn’t work, unfortunately. However, Roblox’s API allows you to detect with CurrentCamera functions! :smiley:

An update has been made to not render Motor6D changes of any of the following conditions are met:

  • The distance between the camera and the root part is greater than 200 studs
  • The root part position is NOT on the screen
  • The UpperTorso isn’t rendered due to StreamingEnabled

This is now used in No-Scope Sniping, a larger-scale game.
You can see the IK mechanics here.


Really amazing work!
I’ve been trying to achieve something like this myself, but as I’m no good mathematician I had to give up on it in the end.
Would you be able to create some sort of module out of this, where you can for instance specify a target object to rotate towards, and a limb (for instance your arm) that will be affected by the IK solving algorithm?


Potentially, although there are many resources on YouTube and the DevForum to do this already.


Hey, is there a way to temporarily disable or set character back to default T pose?
“if climbing” part doesn’t seem to work, at all.
Great module bdw.


You can modify the module/script to do that :slight_smile:

Could you provide a video?


My bad, i thought that when climbing it should stop moving or at least force idle pose.


It works with non startercharacters right?


What do you mean by non starter ?


Yes, as long as it is R15.
Make sure, however, you keep a consistent height among all of the players or the calculations may be incorrect.


This is really dope. Is there a way I can make the idle stance not look like the character’s about to drop last week’s Taco Bell?


You can change the idle angle of the UpperLegs’ Hips.

1 Like

Seems pretty neat! Wonder if I could try making it compatible with R6
Will be a long and time consuming task, but I guess that’s the fun in scripting


Pretty sure you gonna have to scrap 80% of entire script, beacus most of the code is positiong those three parts of each leg.

1 Like