[DISCONTINUED] Free R15 IKPF System (Inverse Kinematics Procedural Footplanting)

[iGottic]

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

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

---

@iGottic

I should make it clear that I do not update this system anymore and will not be fixing any issues. I may or may not recreate this in the future, but for now, no updates will be made.

@iGottic

Hey guys, I got an update!

I’ll soon be making a new post with a revamped version of this to include wide customizability, improved code, improved + full-body animation, and more. The upcoming version will also be a package on Wally and have a GitHub repository.

Please reply to this with any suggestions or ideas, and I’ll consider each and every one.

[Scarious]

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

TL; DR:

• 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.

[iGottic]

@Scarious

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.

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

@Scarious

ou 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.

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).

[Scarious]

@iGottic

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

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.

[iGottic]

@Scarious

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?

[Scarious]

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
end

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

[iGottic]

@Scarious

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

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

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

[iGottic]

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

[PysephDEV (Pyseph)]

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?

[iGottic]

@avozzo

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.

[Czlopek]

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.

[iGottic]

@Czlopek

Hey, is there a way to temporarily disable or set character back to default T pose?

You can modify the module/script to do that

@Czlopek

“if climbing” part doesn’t seem to work, at all.

Could you provide a video?

[Czlopek]

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

[4Slu]

It works with non startercharacters right?

[Czlopek]

What do you mean by non starter ?

[iGottic]

@4Slu

It works with non startercharacters right?

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.

[LeedleLeeRocket (BigMummyMilkers)]

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?

[iGottic]

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

[Sylveon_Hi]

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

[Czlopek]

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