[Released] Kinematic Character Controller

Well damn I guess I was wrong on that. I thought you could override access on abstract methods but I guess not.

 

Kinematic characters should never be a child of a moving transform. This is because if the parent transform moves, it'll also move the character, but without any of its movement solving algorithm being used. This will surely cause problems such as going through walls or jittery movement

If you take the planet in the demo for example, it all works through the same mechanics that are used for moving platforms (the character motor knows what "PhysicsMover" it needs to stick to, and calculates how that PhysicsMover's movement would affect its own movement. Basically, it simulates parenting without actually parenting)

However.... now that I think about it, I think it might be possible to add support for this. The character motor could try to remember what pose it had at the end of last frame, and then at the beginning of the current frame, look at the diff between last pose and current pose, and apply that as real movement..... I'll investigate this

 

Ya I wasn't making it a child, just anchoring via setting it's position manually to the anchor position every Update and setting the velocity in the controller to 0 while doing so. Which appears to work fine.

 

Oh I see, well just keep in mind that this too may cause the same kinds of problems you'd get with transform parenting

But if you don't need your character to move around while you're anchoring it (which I guess is the case since you set the velocity to 0), then there should be no problems

 

It's a temporary solution anyways until I move to the boat being a moving platform. I'm just getting ready for some demo's and don't need the moving platform stuff

Hmm so this doesn't appear to work like I thought it did. I'm already moving the platform via fairly complex physics. So in this case I don't even need a physics mover correct?

 

So the character controller looks like it just needs the total velocity of the platform. so if I modify KinematicCharacterMotor to have a reference to the platform rigidbody and use that if it exists, that should work?

 

If I use the physics mover and just pass the existing position/rotation to the base mover controller, that should work also, basically it should end up not applying any or at most a negligible force.

 

Hmm on second thought that's probably not going to work, the forces I'm applying will get overwritten with your velocity updates and it will get all messed up.

I'll just hack into the character controller so it can get the data it needs from the platform rigidbody

 

The character is able to stand on a non-kinematic rigidbody without requiring any special component, but in this case, movement will always be one frame late, and the character can impede the rigidbody's movement. If you want everything to work perfectly, you will need a PhysicsMover.

It's a bit more complicated than that, and I am not 100% sure this will work well. If you look at KinematicCharacterSystem, you'll see that there is an extremely precise execution order that is required for interactions between characters and PhysicsMover. Figuring this whole thing out could end up being quite a massive undertaking (there is a section of the UserGuide that explains all of this).

Overall I still think converting your system to PhysicsMovers (if possible) would be the easiest way to accomplish this.

 

The platform itself can be kinematic, right now it's a child of the rigidbody group. That group is comprised of 2-3 rigidbodies joined with fixed joints, that individually have forces applied for buoyancy. Movement forces are applied to the group, and then adjustments are applied on remote objects since this is all networked.

So no way this is going to convert to using the physics mover.

The platform that the character moves on I can make it whatever I want including just not having it attached to the rigidibody group at all.

I think this will be easiest if I just handle it all on my end. I've done this before so I know all the caveats.

 

Hmm now that I think about it. The actual platform detached from my rigidbody group, then let the physics mover move just the platform. That should work cleanly.

 

So the physics mover to work in more complicated setups, like vehicles generally, needs to work a bit differently. The physics mover just fundamentally won't work with objects you actually want controlled with forces. It kind of defeats the entire purpose of using physics to start with.

The only way to do this that I know always works is the platform is just synchronized to some other object by calling MovePosition/MoveRotation in FixedUpdate. Versus trying to move towards a goal.

 

Yeah theoretically, if you make the PhysicsMover be a separate thing and simply have it copy a dynamic rigidbody's pos/rot, and have their physics layers arranged properly, that should work

 

That's what I'm doing now and the phsycis interactions are working fine, but having issues trying to keep the character stable without jittering. This is the velocity formula I'm using in the character controller. The target is just a fixed point on the platform and the intent is to make the controller stay there without any jitter. But I'm still getting a lot of jittering. Any ideas on how to improve this?

Code (csharp):

1.  
2. MoveInputVector = Vector3.ProjectOnPlane(moveInput, KinematicCharacterMotor.CharacterUp).normalized * moveInput.magnitude;
3. TotalVelocity = MovingPlatform.Rb.velocity.magnitude + MoveInputVector.magnitude;
4. targetVelocity = MoveInputVector.normalized * TotalVelocity;
5.  
6.  

 

Do you have examples showing fully animated humanoid characters using this? It would be nice to see how it handles an animated character over all sorts of terrain. In my past searches for the perfect controller there always seemed to be issues moving over uneven surfaces and this seems like it might be able to do that smoothly.

 

Normally, you don't need to add the moving platform's velocity when you tell the KinematicCharacterMotor what its velocity should be. By using PhysicsMovers, the motor handles all this by itself, and you only have to tell it what its velocity should be relatively to whatever it is currently grounded on.

So if you want to test what happens when the character is idle on a moving platform, you can just return a velocity of zero.

But perhaps I could be of more help if you can share a package demonstrating your setup

 

Right now I don't have anything ready/released to demonstrate animated characters, but here's a little work in progress of an example animated character I'm planning to add to the package:
https://i.gyazo.com/680ae4a84e66a8b82cd3d05036237bd8.mp4
https://i.gyazo.com/cecf83011d3dd6dd04bcfdf1981818c5.mp4

This package doesn't actually deal with animation at all, but I figured it would be helpful to have an example of animation handling (both with and without root motion). But as you can see in these videos, the velocity vector of the kinematic character controller, which we use to drive animation values, remains 100% constant even in very rough terrain. There are no weird velocity bumps/jitter

 

Looks great. Now I'm wondering if something like this might be able to be integrated with another 3rd person controller so that this system handles all the movement and the other system handles all the other things like animation, camera, etc. I''m referring to Ootii's Motion Controller.

 

I'm not using the physics mover, as I explained your physics mover won't work for vehicles controlled via physics.

If you reduce the problem it's basically how do you get the character controller to pin itself to a moving target at the same speed as the target. So that it never moves more then say 0.1 units away from the target and you don't get any visual jittering.

 

Unfortunately, my guess is that it would be very difficult to combine both of these things. I don't know the inner workings of Motion Controller well enough to actually know for sure, but I think it's safe to say that both of these packages are very complex systems with very specific ways of handling things, and that combining them may end up involving more work than just coming up with your own solution

 

OK, thanks.

 

To re iterate,the reason the physics mover won't work is because as far as I can tell, there is no way to make it just move with MovePosition/MoveRotation. It wants to move to the goal over time, which results in very noticable visual stuttering. My own physics mover just moves the platform using MovePosition/MoveRotation, which works nicely.

 

Oh my bad, I misunderstood

However, the PhysicsMover can move with something that is basically the exact equivalent of MovePosition/MoveRotation. When you specify a goalPosition and a goalRotation in your override of "BaseMoverController.UpdateMovement", you are basically telling the PhysicsMover to do a MovePosition and MoveRotation to there (among many other things that are handled in the background). You can look at ExampleMovingPlatform.cs for reference, or the "Creating a moving platform" part of the walkthrough

If you are not using a PhysicsMover, achieving jitter-less moving platforms might turn into a nightmare. This specific problem took me nearly half a year to solve. If I had to explain it, it would basically be the equivalent of explaining how to re-write this entire character controller from scratch. I wanted to hide all of this pain from the users by creating the PhysicsMover class, which handles all the complexity in the background, and only asks for a goal position and rotation. (you can see the "UpdateMovement" callback as something that asks "What pos/rot should I have right now?")

Again, since I'm not really sure I understand your setup and your needs, the help I can offer is limited

 

Ya I looked at all the code in PhysicsMover and ExampleMovingPlatform. I think the issue is that you start out by creating smooth movement using positions. Where as with a vehicle moved with physics, the starting point is the velocity of the physics object.

Using your physics mover and feeding it the current position/rotation of the vehicle results in stuttering in movement. Which if you think about it is kind of expected, because the formula to get smooth synchronized movement is just different if you start with velocity and copy the position, vs creating smooth position translations to start with.

At this point I'm thinking the best solution might not be the brute force one. It's when the controller is trying to stay right on top of the target that sorting out the correct velocity is an issue. So just anchoring the character transform once it arrives, and keeping it anchored until there is another move request, might be the simpler solution.

 

@snacktime
Here's an example of a PhysicsMover setup that follows a rigidbody. I think it would be good to restart the discussion from there
https://i.gyazo.com/944dda63d25c8eaece9e256057d7462e.mp4

Here's how everything is arranged:

• There is a "Cube" object which is a cube with a non-kinematic rigidbody on it. As you can see in this video, I move it with forces
• As a child of this "Cube" object, there is an object with a slightly inflated cube collider, and this object has a PhysicsMover and a "RigidbodyMover" script, which controls the PhysicsMover movement by making it follow the rigidbody of the non-kinematic cube
• The "Cube" object and its PhysicsMover child are on different layers that cannot collide with each other

Here's a picture of the whole setup: https://i.gyazo.com/8c8095bcd1fb665d7a71f2ee26db5cb2.png

...and the code for the RigidbodyMover

Spoiler: RigidbodyMover

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using KinematicCharacterController;
5.  
6. public class RigidbodyMover : BaseMoverController
7. {
8.     public Rigidbody FollowedRigidbody;
9.  
10.     public override void UpdateMovement(out Vector3 goalPosition, out Quaternion goalRotation, float deltaTime)
11.     {
12.         // Rigidbody position/rotation changes are always applied at the end of the frame,
13.         // so here instead of simply setting the goalPosition to the followed rigidbody position,
14.         // we also anticipate the extra movement from its velocity. Same goes for rotation
15.  
16.         goalPosition = FollowedRigidbody.position + (FollowedRigidbody.velocity * deltaTime);
17.         goalRotation = Quaternion.Euler(Mathf.Rad2Deg * FollowedRigidbody.angularVelocity * deltaTime) * FollowedRigidbody.rotation;
18.     }
19. }

With this setup, we have a PhysicsMover that perfectly follows a dynamic rigidbody, and the character can move on it without any jittering

 

Ok let me give that logic a try. Using deltatime should get rid of the stuttering of the platform itself.

 

Now I remember why I was avoiding that. But I might not have been correct in my assumption on something. Does velocity include rotation via MoveRotation? My vehicles are networked so I reconcile the physics simulation. And I'm still doing that reconciliation on rotation using MoveRotation.

 

Ok ya that approach with the physics mover appears to work well, once I set my physics rigidbodies to interpolate Thanks for the assistance.

 

awesome!

 

Hey amazing asset! I'm using this in a unet multiplayer game and I'm wondering should I sync input values or disable the kinematic cc on non owner characters and just send transform & interpolate it? keep up the great work

 

Both solutions would be valid, but syncing inputs (with periodic checks for pos/rot corrections) would surely give better results. The velocity/rotation handling is deterministic enough to accomplish this. It is only limited by floating-point errors, which is why it's still a good idea to check for corrections once in a while

In this case, the advantage of syncing inputs would be that clients would be more able to predict collisions and velocity projections, even if they didn't get a network update. (but I'm guessing you already know this since you asked the question).

 

Update 1.2.1 released. Contains two small but important fixes:

- Fixed a custom inspector issue with rigidbodies which caused rigidbody constraints to be invisible in the inspector
- Fixed MaxStepHeight of 0 causing issues with ledge handling

 

Looks like you uploaded the update as a complete project and not as an asset.

 

uh oh. I'll re-submit the package then. Thanks for pointing it out

 

Hi, I need something like this for my BoxCollider2D player, is there any plans to add 2D version?

 

Unfortunately, no 2D version of this is planned. However, I'm sure you could find something suitable on the asset store, such as 'Corgi Engine' or 'Rex Engine'

 

@PhilSA:

I purchased your solution a few hours ago. Testing it and reading the documentation has been an oddly emotional experience. You've managed to achieve what I have failed to achieve in 25+ attempts over the past 4 years. I've come close a few times, but never succeeded. To have spent so much time and effort, and yet end up using someone else's solution feels like giving up. However, your solution absolutely nailed it.

I know your victory was hard-won. I've read your posts on the forms (Thank you for helping to get ComputePenetration into our hands!). Also, your "Playground" level is a masterclass torturing typically character controllers. (And exposing functions via the Template pattern is inspired!)

As much as putting aside my own efforts in this area is difficult, the thought of moving onto new challenges is elating. So many of my ideas are now enabled by your creation. I really, truly, don't know how to thank you enough! Please, accept both my heartfelt congratulations, and my deepest appreciation!

I do have one question: Is it possible for your Character Controller to behave like a cylinder instead of a capsule on ledges?

This is a feature I implemented in my own scripts (casting/overlapping a box, then excluding colliders that are not also inside of a capsule radius taller than the box), and I preferred it only because it allows one to overlook the edge of ledges without feeling like the controller is clinging to them.

If this is possible within your solution, its features will be truly flawless for my purposes! If not, I am still excited to use your solution in my projects going forward.

Again, thank you so very much!

Be well!
- S.

 

Sadly this isn't possible right now. But since a bunch of people have requested it so far, I might start looking into it.

thanks for the kind words!

 

Thank you for the quick response.

Absolutely my pleasure!

I'll keep my fingers crossed, then, but in the meantime, I have ample areas to work on now.

Be well!
- S.

 

@PhilSA:

Good evening!

Instantiating a Kinematic Character controller runtime reveals to two unexpected quirks:

• It requires that the GameObject to which the KinematicCharacterMotor class is added be disabled until KinematicCharacterMotor.CharacterController value has been set; otherwise, it results in a NullReferenceException
• KinematicCharacterMotor.ValidateData() must be called manually; otherwise, it results in jitters and other unexpected movement instabilities

Neither of these are particularly difficult to fix once their solution has been identified, but it did take some digging to realize said solution.

Just mentioning these details here in case there might be value in officially documenting them, modifying your asset's approach so they are unnecessary, and for anyone else who might find it here in this forum post.

Thank you again and be well!
- S.

 

thanks for reporting this! A new version containing fixes for both of these things has been submitted for approval on the store, and should be released at some point this week.

Once this new version (1.2.2) releases, creating a character at runtime will look like this, and there will be no need to call ValidateData manually:

 

Beautiful! A much more elegant solution.

My pleasure. Thank you.

Be well!
-S.

 

@PhilSA:

I'm using a realistic 9.81m/s gravity force, and am allowing a maximum air movement speed of 1.5m/s.

After jumping against a steep 60 degree slope (Max Stable Slope Angle being 45), as long as I continue to move toward it, I'm able to slide up along the slope. I want to prevent this.

My first approach was to disallow air control when (!KinematicCharacterMotor.IsStableOnGround && KinematicCharacterMotor.FoundAnyGround), but KinematicCharacterMotor.FoundAnyGround returns false every other frame.

I'm not sure whether KinematicCharacterMotor.FoundAnyGround returning false in this case is intentional or not.

I tested a simple UpdateVelocity function where I placed the CharacterController in contact with the slope and applied a force exactly tangential to it, and FoundAnyGround accurately reported true each frame. Also, upping my Gravity force to >~20.0m/s resolves the issue, even given an increased jump force.

My preference would be to determine why FoundAnyGround is intermittently returning false. If you have any better solutions, however, I am definitely interested!

Thank you in advance. Be well!
- S.

 

This is definitely a bug that I never noticed before. I'll let you know as soon as I find a solution

 

@S_Darkwell
I started testing this a little, and while air-climbing steep slopes is definitely a problem that should be fixed, I wasn't able to reproduce the FoundAnyGround problem yet

Here's a video where I debug.log FoundAnyGround at every UpdateVelocity call:
https://i.gyazo.com/6c3cb6ac1beb3eaf2c566c4430287f8e.mp4

Disabling controls if (!KinematicCharacterMotor.IsStableOnGround && KinematicCharacterMotor.FoundAnyGround) also gives me consistent FoundAnyGround results

Do you have more precise steps to try to reproduce this problem?

 

@PhilSA:

Now I'm worried that the issue exists in my code!

Here is a minimal project that I believe illustrates the same issue. I haven't changed any of the KinematicCharacterMotor's settings.

Just use W to move forward, S to move backward, and Space to jump.

To reproduce what I believe is the same issue, hold the W key to move forward toward the ramp. Repeatedly press Space in rapid succession while continuing to hold W. After a few jump attempts, you should begin to ascend the slope. "Cannot find any ground!" is output to the log during the jump, which is expected. If you let go of W, though, again the ground cannot be found for a number of frames, which I wouldn't expect.

I believe(?) this illustrates the same issue. If not, I can Email you my actual project files so you can see the exact issue I'm experiencing.

Hope that helps!

Thank you so much!
- S.

 

@PhilSA

Okay. I believe whatever is causing the KinematicCharacterMotor in the above attached project to report false to finding the ground for a number of frames after ceasing input is what is causing my issue.

Since in my project I am zeroing out input when (!KinematicCharacterMotor.IsStableOnGround && KinematicCharacterMotor.FoundAnyGround) in order to prevent air movement from sliding the Character up the steep slope, it repeatedly recreates the same condition illustrated in the attachment, thus causing the motor to lose ground and enable air movement again.

- S.

 

@S_Darkwell
I can definitely reproduce the issue in the scene/script you sent me. I even replaced your whole UpdateVelocity method with this:

Code (CSharp):

1. public override void UpdateVelocity(ref Vector3 currentVelocity, float deltaTime)
2.     {
3.         currentVelocity = Input.GetKey(KeyCode.W) ? (Vector3.forward * 50f * deltaTime) : Vector3.zero;
4.  
5.         // Jump
6.         if (Input.GetKeyDown(KeyCode.Space) && KinematicCharacterMotor.IsStableOnGround)
7.         {
8.             KinematicCharacterMotor.ForceUnground();
9.             currentVelocity = new Vector3(0.0f, 3.25f, 0.0f);
10.         }
11.  
12.         // Gravity
13.         currentVelocity += new Vector3(0.0f, -9.81f * deltaTime, 0.0f);
14.  
15.         if (!KinematicCharacterMotor.FoundAnyGround)
16.             Debug.LogWarning(Time.frameCount + ": Cannot find any ground!");
17.     }

to simplify things a little, and the issue is still present (although now FoundAnyGround is false while you are moving against the wall).

I'll keep you updated on my findings. Right now I am not sure what's going on

 

Glad I was able to help you reproduce it!

Also, please know that the UpdateVelocity() I sent you was far from representing my actual code. Try not to judge my code based on that hacked-together bit I sent you.

I'll await your findings with anticipation.

Thank you and be well!
- S.

 

@S_Darkwell
I think I have a solution. Or at least, it worked on my side.

All you have to do is to go in KinematicCharacterMotor and find the line where we do

Code (CSharp):

1. _sweepMovementFoundGround = isStableOnHit;

(It's in "OnMovementHit")

just replace that line with:

Code (CSharp):

1. _sweepMovementFoundGround = Vector3.Dot(hitNormal, CharacterUp) > 0f;

This did the trick. If you can confirm that it fixed the problem, I'll add this fix to future releases