How to stop bones from clipping through objects during animations?

I recall seeing a video in the monthly WIP thread a long time ago that was using the new Animation System with inverse kinematics and physics ( I think?) to make an animated character model go up a set of stairs without having its walk animation cause the feet to clip through the stairs.

I am trying to figure this out now that I am working with the DynamicAnimControl and AnimComposer on 3.3 for my NPCs, but can’t find that topic and I am struggling to figure anything else out on the idea.

I was going to procrastinate this problem until a later date, as I thought this feature was mostly a visual thing that wouldn’t affect gameplay, even though the animation clipping with feet and legs can get really ugly in hilly and uneven areas.
However, now that I am working with the DynamicAnimControl’s ragdoll and dynamic modes that interact with physics, I have noticed that it is imperative that the legs are not clipping through any other phyics bodies when a walk animation is playing with the AnimComposer. From my testing so far, this can accidentally (and wrongly) pin the NPC to the ground if the DAC’s ragdoll or dynamic force mode gets activated while a limb is clipped through another physics object.

This functionality also seems necessary for making an NPC recover from a big fall / knockback that uses ragdoll mode. Once an NPC is done being knocked back they will be laying on the ground in the DAC’s ragdoll mode, then I blend to kineamtic mode while rotating the the NPC onto its stomach and playing a stand animation, so the NPC can recover - but while this recovery process occurs, the bone clipping is very noticeable.

Any help figuring out how to do this type of Inverse Kinematics with animations and physics is greatly appreciated :slightly_smiling_face:

1 Like

i dont really think IK walking example were avoiding clipping, but rather “set IK point to stairs contact point” i guess.

But for your problem i have some idea like setting “collision bone with wall”(and adjacent bones) to ragdoll mode, while keep other bones in animation mode.

Anyway i would suggest avoiding much collision detection since its all additional physics work, thats why many games have like “ragdoll limit” setting too.

here some example(old test video i had just to quick show, start from 0:17):

where i set ragdoll mode for a moment on collision for a adjacent bones of collision bone.

1 Like

I’m not sure if I was correct to use the term Inverse Kinematics. But I do know I have seen this feature in other 3d games, where the character’s walk animation adjusts as they are going up a hill, so their thighs get pushed higher to make sure the feet don’t clip through the up-hill terrain. I am not sure what that is called, but it would be a great feature in JME and I think it should be possible to do with something like DAC’s physical bone capabilities.

I am curious if you have done any stress testing on a desktop device to know what are the capabilities and how many ragdolls you can have at once?
I haven’t gotten that far yet myself, but I am hoping I can manage to minimize the performance impact by only using the ragdoll mode for a few seconds at a time when a knockback occurs.

And then depending on the results of my stress testing, I am planning to write all of my game’s spells/abilities with knockback effects so that they have low radiuses, or I will dissipate the impact for enemies that are further from the center or if they are behind many other enemies. I am going off of the assumption that I should be able to have at least 3-4 enemies in ragdoll mode for a 2-3 second span of time, so anything more than that would be a bonus. But I still havent’ gotten far enough to stress test lots of DACs at once yet myself so hopefully I’m not wrong on that :laughing:

I also don’t use physics for anything else in my game aside from static bodes, and use my own very light weight physics for movement and normal NPC push-physics. So I hope that my minimal use of Physics will help the fps as well so I can use as many DACs at once as possible.

2 Likes

Yes you are right, what i mean is that IK adjust feet bone to some point, and this point can be calculated for example via simple “Raycast” instead using full ragdoll system. But i might be wrong, i just thoguht it would be faster than using default bone collision all the time.

I am curious if you have done any stress testing on a desktop device to know what are the capabilities and how many ragdolls you can have at once?
I haven’t gotten that far yet myself, but I am hoping I can manage to minimize the performance impact by only using the ragdoll mode for a few seconds at a time when a knockback occurs.

This all depends on Bones amount and complexity of skeletons, so hard to tell.

For example i would avoid using fingers/tips/etc in ragdoll mode. Even avoid eyes when in ragdoll mode to make it work faster.

Or make it LOD based, its also possible. Far ragdolls could be just 2 bones really :slight_smile:

1 Like

Are there any new developments?

1 Like

I never made any more progress on this unfortunately.

I had a few ideas to try out using Minie’s DynamicAnimControl but didn’t feel confident enough that my ideas would work and look good enough to justify working on this instead other things at the time.

I had two general ideas I was going to start with though:

The first idea I have is to do a completely procedural walk animation with code for the legs where I’d try using the setDynamic() method in the DAC to guide the feet up and down in an elliptical shape and hopefully it would look like walking when the feet collide with the ground, but I had a hunch that I probably would not be able to do this well without spending a lot of time tweaking things with trial and error. I also have lots of different animals in my game with 4 legs and slightly different walk cycles, so trying to make a clean procedural walk animation for all of my unique animated models could be difficult and time consuming; or maybe not, I haven’t attempted anything so I’m just speculating still.

And the second Idea I had (that I expect would be easier if its even possible) was to try something where I let the legs play their normal walk animation, and then if the feet or legs clip through something (like sloping ground or stairs) then I would just reposition the joints upwards at the Y level of the collided object. It sounds easy enough, but I expect the results could also end up real sloppy and buggy and could look nothing like what I expect, depending on how the AnimComposer responds when a joint gets its transform manually adjusted in the middle of an animation.

If I get around to this anytime soon and make any substantial progress I’ll post back with more information. Although I am still interested to hear if anyone else has any other ideas / insights, or if anyone else makes any progress on this in the mean time.

2 Likes

Thank you for providing a very good development idea

1 Like

I’m back to focusing on this issue, since I’ve finally implemented ragdoll physics in my game on a large scale, and now I need to find a way to make sure that legs and feet are not clipping through the ground when the model enters ragdoll mode (as mentioned in my original post):

The best solution so far seems to be to use a walk animation cycle where both feet have target positions at specific times of the cycle, and then each foot would also do a ray cast towards the ground every frame to determine if that foot’s current position for that frame needs adjusted to prevent it from clipping through the ground.

@sgold so this leads me to ask: is it is possible for DAC to have a method to force-set a boneLinks current location using DAC’s inverse kinematic potential?

Similar to the way a regular characterControl has a setWalkDir() method for moving the character naturally with forces, and also has a setPhysicsLocation() method for when you want to warp the character control to a precise location immediately… I think that having something similar for immediately setting the physics location of a bone-link could be very useful for creating precise walk cycles with inverse kinematics.

Do you think something like a dac.setSubtreeLocation(BoneLink rootLink, Vector3f location) method would be possible to add to DAC for cases like this where you want to immediately update a bonelinks location? (or is there maybe already a way to do this that I’m overlooking? or I also worry: is this potentially an entirely different type of inverse kinematics that would not work with DAC?)

And of course I’m very interested if you (or anyone) have any other thoughts or insights on my ideas so far.

Thanks :slightly_smiling_face:

1 Like

is it is possible for DAC to have a method to force-set a boneLinks current location using DAC’s inverse kinematic potential?

There are mechanisms to do this, but I’ve never tried using them for walk animation, so I can only speculate about what will work best. I think you’ll need to constrain both the locations and the orientations of both feet. You’d start by putting both chains of links into dynamic mode: the feet, lower legs, and upper legs.

If the ground is a static rigid body, then dynamic feet shouldn’t clip through it. So perhaps you don’t need raycasts to position them?

You’d need to provide some support to keep the ragdoll from collapsing; a slight upward gravity on the torso should do the trick. For this to work, the torso would also have to be in dynamic mode.

There are 2 ways to constrain a link in dynamic mode: IKController and IKJoint. IKController is the more flexible mechanism, and IKJoint is the simpler one.

To position a foot in 3 dimensions, for instance, you could use DynamicAnimControl.pinToWorld(), to add an IKJoint to each foot link. By itself, that wouldn’t keep the feet from twisting and turning, but you could combine it with other constraints that would do so. Or perhaps you only want to specify the X- and Z- coordinates, leaving the Y coordinate to be driven by (downward) gravity.

having something similar for immediately setting the physics location of a bone-link could be very useful for creating precise walk cycles with inverse kinematics.

If a link is in kinematic mode, then nothing prevents you from positioning it using getRigidBody().setPhysicsLocation() and .setPhysicsRotation(). But you’d be on your own to calculate the necessary joint angles, which is (I believe) the difficult part of inverse kinematics.

something like a dac.setSubtreeLocation(BoneLink rootLink, Vector3f location) method

I’m unsure what you mean by the location of a subtree. Is that the same as the location of the link at the root of the subtree?

Example apps that might help clarify DAC inverse kinematics include:

2 Likes

Thank you for the information, I will take a look at the 2 examples you linked and re-read the idea in your reply some more when I can better understand how the IKController and IKJoint all works.

I was thinking that it would be the location of the link at the end of the subtree, and then the rest of its parent boneLinks in the chain would handle the inverse kinematics and and rotate in order to get the boneLink at the end of the chain to the location passed into the method (or as close as possible if the desired location is still out of range of the limb when its fully extended)

So essentially I was hoping that a dac.setSubTreeLocation(BoneLink rootLink, Vector3f locationForEndLink) method would work to handle doing the difficult inverse kineamtics math to achieve what you mentioned here:

In addition to being potentially useful for a making dynamic walk cycle that prevents clipping while walking, having a method like this would also be very useful to call on both feet prior to setting any model into ragdoll or dynamic to ensure sure there aren’t any bonLinks stuck intersecting the ground from any other static animation that was playing before the model suddenly gets launched in ragdoll mode and is susceptible to being pinned down if that animation left off with any boneLinks intersecting the ground.

So I was imaging a situation where, right before putting a model into ragdoll mode with a dynamic force applied to the torsoLink, I would do a ray check upwards from each foot. And then if there’s any collision detected very close (indicating that a foot boneLink is potentially intersecting the ground), then I would call a method like dac.setSubtreeLocation(footBoneLink, collisionLocation); which would handle the IK code in order to immediately reposition the foot at the detected collision location above the ground so the model will always be prevented from getting pinned down by its feet when entering ragdoll mode from static animations that were running in kinematic mode.

2 Likes

This video gives me an idea but I’m still working on my model and I haven’t done it any further.
(I hope the artist I hired can finish the model as soon as possible :grinning:)

1 Like