[Released] Kinematic Character Controller

Thanks, good to know!

Also is there a reason why if you apply gravity to the character while it is grounded, it constantly moves around? You can repro this if you go to the example controller script and add gravity while the Motor is grounded. The character won't ever return to a velocity of zero after moving.

I'd like my character to slide down steep slopes even if they are stable, so would like to be able to apply gravity to them while grounded

 

That's caused by the sticking-to-ground mecanism of the cc, which makes it always reorient its velocity on the ground slope when grounded.

To do what you want to accomplish, you'd have to manually calculate the end velocity that would move your character down the slope

But I will investigate ways to make the reorientation optional, or to find a way around it

 

That's fine, I can always adjust it manually depending on slope Thanks again

 

This is working for flat ground but once I start to go up and down the stairs the velocity spikes causing major jittering on my blend tree. Any suggestions?

Anyone else animating based on velocity rather than input that wants to work together on ironing out a good animation setup?

 

Turns out this was trickier than expected! I projected the gravity to the ground normal so it only applies the necessary forces on the character. However I have different types of slopes, some curved, others straight, and as you said, when then character comes off a slope they reorientate their velocity to that new slope, so they still move around on the ground.

What I did try as a workaround, was force the controller to recalculate its velocity by using ForceUnground() but this is a bit of a workaround. It would be nice to have an exposed property for this so when the ground normal is Vector3.up I can remove any existing velocity

 

You might need to apply some sort of lerping/smoothing on the value you pass to the animator. Otherwise, I'm pretty sure most game will just use ramps instead of stairs for this sort of thing (for colliders, I mean. Mesh can still be stairs)

 

I'll definitely add something to let users control this

 

Hey Phil!
My project has been coming along really well thanks to your awesome character controller! I'm beginning to really get the hang of it. Thank you again for making such an awesome asset!!

One of the things I want to implement next is the ability to swim up waterfalls. I picture it working like this: If you stand within a trigger area near a waterfall and hit "shift" I'll have the character be able to "climb" the waterfall by jumping repeatedly. If you don't continually jump/swim up it, you'll fall back down. If you release shift, you'll pop out of the waterfall (back to default state). I'm wondering how would you suggest implementing this? Here are my thoughts:

1. Create a new waterfallSwimming state
2. Create a waterfall mesh with a trigger around it. I'm thinking something simple like this for the mesh:

3. If the character is within the trigger and holds shift, have them snap to the surface of the waterfall mesh..
4. Have the character movement confined to the normals of the waterfall mesh in waterfallSwimming state.
5. If they hit jump, add an upward impulse along the waterfall mesh normal. otherwise, have a weak gravity force pulling them gently down. Don't limit the amount of jumps they can do
6. If they release shift, return them to default state

I think the only part I'm not 100% sure how to do is step 4 and 5. Would it be similar to the Basic Movement walkthrough? I want the character to stick to the waterfall but retain their 'up direction' parallel to the waterfall, not perpendicular (they should not be walking horizontally up the waterfall, but climbing it)

I posted this here because I think others might have similar questions if they want to implement free climbing into their game, etc.I wanted to get your thoughts since you are the master *bows respectfully

Thanks again for all your help!

 

This sounds like a bug, I will add it to my todo list

 

This may become.... complicated . It's the kind of thing that can easily take months to develop in typical game productions

I think this would be somewhat similar to the ladder example, except instead of moving up a straight line, you are moving within a mesh surface (almost like a navmesh, in a way). That and also there is a force pulling you down, but that's the least of our concerns for now.

I think what you could do is something like this:

• At each BeforeCharacterUpdate in that state, raycast from the center of your character capsule towards your character forward, which will be pointing to the waterfall
• That raycast will hit the waterfall mesh and give you a point and a normal. It will also give you a distance, which we will use later in UpdateVelocity to stick to the mesh
• With some quaternion/vector math, remember the rotation your character has to be in in order to fit that normal. You can apply it later in UpdateRotation
• In UpdateVelocity, when you move up, you'll be moving only in the up direction of the rotation you just calculated.
• Moreover, still in UpdateVelocity we'll use the distance we got from our raycast to evaluate our current distance from the waterfall mesh. If our raycast had a distance shorter than the capsule radius we need to move back. If it is greater than our capsule radius, we need to move forward. Here we'd use "GetVelocityForMovePosition" tu place our character at the adequate distance from the waterfall hit point

That's my vague idea for how I'd approach this, but I'd have to actually try to implement it to really be able to give you a proper answer. An example for something like this may come later down the road, but I can't make any promises

 

Hello.

I developed a character with kinematic character controller.

Few day ago, I updated kinematic character controller version 2.0.0.

New features are great and stable.

But I had a problem with a ledge distance checking.




My character float in the air.

Image Link : https://imgur.com/qmJtHyY

And I added ledge distance checking. code to the KinematicCharacterMotor.cs

like this

Code (CSharp):

1. .........................
2.                // Ledge handling
3.                 stabilityReport.LedgeDetected = !isStableOnStep && (isValidStepOuter != isValidStepInner);
4.                 if (stabilityReport.LedgeDetected)
5.                 {
6.                     stabilityReport.IsOnEmptySideOfLedge = isValidStepOuter && !isValidStepInner;
7.                     stabilityReport.LedgeGroundNormal = isValidStepOuter ? outerStepRayEndNormal : innerStepRayEndNormal;
8.                     stabilityReport.LedgeRightDirection = Vector3.Cross(hitNormal, outerStepRayEndNormal).normalized;
9.                     stabilityReport.LedgeFacingDirection = Vector3.Cross(stabilityReport.LedgeGroundNormal, stabilityReport.LedgeRightDirection).normalized;
10.                     stabilityReport.DistanceFromLedge = Vector3.ProjectOnPlane((hitPoint - characterBottom), atCharacterUp).magnitude;
11.                 }
12.             }
13.  
14.             stabilityReport.StepDetected = isStableOnStep && !isStableOnNormal;
15.  
16.             // added Code!
17.             ledgeTestStable = !stabilityReport.LedgeDetected
18.                 || (Vector3.Project(_baseVelocity, stabilityReport.LedgeGroundNormal).magnitude < MaxStableOnLedgeVelocity
19.                     && stabilityReport.DistanceFromLedge < MaxStableDistanceFromLedge);
20.  
21.             // Final stability evaluation
22.             if ((isStableOnNormal || isStableOnStep) && ledgeTestStable)
23.             {
24.                 stabilityReport.IsStable = true;
25.             }
26.  
27.             CharacterController.ProcessHitStabilityReport(hitCollider, hitNormal, hitPoint, atCharacterPosition, atCharacterRotation, ref stabilityReport);

this code is copied previous version kinematicCharacterMotor.

But It doesn't work.

How to solve this problem. Help me please.

Thank you

 

Hi,

I really like your asset, it fixed a lot of issues I had with my physics based controller. However, I noticed a small issue and I'd like to know if there's a solution to it. I started from the Character Playground ExampleCharacterController and modified it heavily to make a first person controller. Now, I noticed that when you have a slope that becomes steeper gradually, on the sides of a mountain on a terrain for example, the controller will stop quickly when the slope becomes too steep. I can actually feel the character move exactly along the vertices on the limit where the slope becomes too steep. It also jerks a lot when you continue to try to move towards the slope. It would seem that would be the expected behaviour, but it feels a bit broken when you play it.

I tried on your ExampleCharacterController in your test scene by extruding a steep hill on the green terrain in the scene, and it does it there too. Just make a hill that becomes gradually too steep for the ExampleCharacterController, try to go up the hill, and you'll see what I'm talking about.

Is there a solution that could smooth this out at the edges of the slope? Thanks!

 

In v2.0, the ledge handling has been moved into the ExampleCharacterController to allows users more control over this. You could try reverting the KinematicCharacterMotor to its default and using the ledge handling found in ExampleCharacterController (just look for where the "MaxStableDistanceFromLedge" variable is used)

 

I haven't played around with this much, but you could try doing additionnal raycasts in UpdateVelocity to gain more info on your surrounding ground. Like maybe 4 raycasts around the GroundingStatus.GroundPoint that would tell you if you're near a steep slope. If you do find a steep slope, you could find ways to reorient the velocity to avoid it

Otherwise you could also try making the MaxSlopeAngle really high (like 89) and manually handling "sliding down steep slopes" in UpdateVelocity

 

Hello how its working? it can working with rigidbody + capsule collider ?

 

It uses a kinematic rigidbody and a capsule collider (this can't be changed)

 

Would you have an estimate on when the next update will be released? The one to fix the issue with determinism when launching off slopes (here) and the ability to let users control the velocity reorientation on slopes when grounded (here). Both are small niggly issues I'm having with the controller at the minute

I'd also like to say thanks for the continued work on this asset, so far it's excellent, well worth the price, and I can't imagine ever needing to use another controller after this

 

I will probably have it ready within about 2 weeks

 

Thank you PhilSA.

I fixed my problem!

 

I tried to find the solution here but I couldn't really find it anywhere. I would like my character to automatically climb up 0.5m steps or so, and climb 1.5 steps on an input. I tried different combinations of Max Step Heights and Step And Ledge Handling Method, and I couldn't get anything that works like imagine, I seem to be limited by the slope angle. Is there a way to do something like this?

If not, I guess I'll make a script that checks for a step in front, and modify the velocity accordingly. I just thought maybe you'd have tips/features that could help me to do so.

 

Nevermind the first part of my previous post, I successfully made Max Step Heights work. however, it's quite instant, and I probably will have to do something better, some kind of different state where I add a climbing velocity if I detect a ledge in front of me.

Edit: I'm at a point where I would need to know the height of a ledge in ProcessHitStabilityReport without getting on top of it automatically. Is that possible?

 

You could get the height of the hit relative to the character like this:

Code (CSharp):

1.  
2.         public override void ProcessHitStabilityReport(Collider hitCollider, Vector3 hitNormal, Vector3 hitPoint, Vector3 atCharacterPosition, Quaternion atCharacterRotation, ref HitStabilityReport hitStabilityReport)
3.         {
4.             float hitHeight = Vector3.Project(hitPoint - Motor.TransientPosition, Motor.CharacterUp).magnitude;
5.  
6.             // .....
7.         }

But if for example you are standing on a ledge and want to know how deep the ledge is, you'd have to do a raycast for this. You can start that raycast at the hitPoint + (HitStabilityReport.LedgeFacingDirection * 0.01f) to make sure the ray is on the "empty" side

 

Your method works, but up to 1 meter or so with a MaxStepHeight of 0.5. Looking at the Motor code, it seems to be linked to the starting point of the sweeps. I could boost MaxStepHeight, but then I'll start climbing everything almost instantly, which isn't great in a First Person game.

I guess I'd need to hack into your code to separate MaxStepHeight and something like MaxSweepHeight, and make everything to work. Don't worry, I understand why it isn't like that already, what I need is an edge case use of your system.

I guess for now I'll do a simple sphere cast in front of me, and I may try to do something better down the line.

Thanks for your help!

 

Has any seen strange behavior in 2018 with controllers getting stuck? controller on relatively flat surface just stops. Input vectors are set correctly, it thinks it's grounded it all looks good but just stops moving. If I manually move it in any direct just a tiny bit, it unsticks.

 

Does this only happen in 2018?

 

Is there anyway to change how far it can hang off a ledge before sliding off?

 

In the ExampleCharacterController, it is controlled with "MaxStableDistanceFromLedge"

 

Pretty sure. The code didn't change in that area since I was on 2017 a week ago, but I was working with some logic where I would notice it more , so possible it's not 2018 specific.

 

I should be able to take a look at it shortly

EDIT: Fixed!
As of right now there's one last thing I want to fix, and then I'll be ready to release 2.1

 

Controller gets stuck when rubbing against surfaces with a very narrow angle. For example if you point towards a wall only very very slightly (nearly parallel) while touching it, character can get stuck. PhilSA is aware of this.

If this is the same problem you're experiencing, then it's a not a 2018 problem.

 

Is that one last thing the character wall sticking we talked about in PMs?

 

Actually this should be fixed now, as well as the stepping bugs you showed me. Both issues were related
( https://i.gyazo.com/4c81455a21fa9a06f676b93406fc176b.mp4 )

I am testing a bit more and preparing the final package tonight for release

I can PM you an early version of the 2.1 package in a few hours if you wish

 

I can verify that the fix works if you like.

 

Hi! Thank you for making this great asset and supporting it so well

I'm having some issues when using Root Motion to move my characters. When they are moving fast (but not unreasonably fast) they will have inconsistent behavior when walking of ledges, up stairs and in slopes. The velocity will be inconsistent and sometimes the character will launch upwards. The lower the frame rate the more often the problem occurs and the more severe it is.

I was able to replicate the problem in your Root Motion example by using one of my own faster moving animations and setting the target frame rate to 15:

https://imgur.com/a/5Srlx

 

Hi!
Thank you for this great asset!

I have one question, so in my game the player has to avoid certain obstacles and some of my characters have kind of unusual (non humanoid) shapes and therefore the capsule collider is kind of problematic.
E.g. An animal with a long tail, so there should be a collisoin if the tail actally collides with an object, but of course no collision if only the "air" above the tail is hit. (which would be an issue with an usual capsule collider)
This is probably an extreme example, as one probably would need something like a mesh collider (which might kill performance completely), but even a simple(?) box collidier would be quite nice.
I know that you wrote that the capsule collider is required, for good performance, but maybe you have an idea how to fix my issue?

 

Unfortunately this character controller is very heavily built around the notion of an upwards capsule, and changing that would be a complex task.

Typically, characters that have an elongated collision shape can be awfully complex to pull off well, and will require a very customized solution. When you rotate a upwards capsule around its Y, it never changes collisions because the capsule is perfectly circular. However, when you rotate a non-circular shape, the collider can rotate into another collider, and this causes a lot of problems.

All I can suggest is this vague idea for an implementation:

The front capsule would be a regular KinematicCharacterController, and the other two capsules would be regular kinematic colliders. Then I'd simply write a script that does the following:

• makes the other two capsules follow the front capsule at all times (as if they were "pulled" by the front one)
• makes the back capsule stick to the ground, so that the animal can adapt its posture to slopes
• makes the other two capsules detect collision information, so that the main KCC capsule can be told that it has to decollide in a certain direction because the back capsule is overlapping with something, for example

 

If anyone notices they can kind of get a 'boost' over a wall that should be too high to jump over ordinarily, the following is a case in which it may happen:

Given a step height of 1, if you are jumping against a 2-high wall, brushing it at say a 45 degree angle, and while you are airborne, you move above a 1-high platform (while still in the air), the step logic will kick in and kind of boost your jump over the wall having decided that there is only 1 unit between the 1-high platform and the 2-high wall. Essentially this will allow you to jump over a wall in a single jump that you shouldn't ordinarily be able to jump over. This would be especially problematic if, for example, the lower 1-high platform was something that would kill the player if they touched it (electrified surface? lava?). Players may find little glitches in your level design to exploit.

There is an easy fix.
In the post grounding update, if you have just become airborne, disable step handling logic (Motor.StepHandling = None) and reset it when you are once again grounded. This will prevent the little glitchy behaviour that arises in particular scenarios.

Hope this helps someone .

Cheers.

 

I just grabbed 2.1 and maybe I've configured something wrong but launching off ledges doesn't seem to be quite deterministic. Attached is an image of my characters velocity (black) and upward orientation (red) as they launch off the slope along with the controller settings. This test was done in the CharacterPlayground with the Example Character scripts. Is there anything I can do to improve this? In this kind of scenario I was hoping the velocity direction would be the same each time you launch from a ledge, and align with the ledge you just launched off.

I also tried other settings, like changing Max Stable Distance From Ledge to zero but doesn't seem to improve it

 

Your settings look fine. Perhaps there's a difference in the tests we're making?

https://drive.google.com/open?id=1LgATv0wMb-UseiDCRIWrdpDJFTWshuTI

In this video, I am making sure the velocity and direction of the character going on the slope is always 100% the same. When leaving ground, I draw the velocity line in green, and when landing, I draw the red line. As you can see, in the same conditions, the lines are always exactly the same. At the end, I try another trajectory to demonstrate the difference

 

Yeah in my example I was going up the slope at different velocities, which results in different launch angles. Shouldn't the launch angle always be the same, and always be the same as the slope it just launched off? In your final example in the video, you go up the slope at a different speed which results in a very different launch angle. The slope is about 45 degrees so your trajectory should be 45 degrees too.

It currently feels like at lower velocities it sticks to the edge of the slope and launches at a different angle

 

uh oh...

I found a really embarrassing mistake in my code, and that's why this isn't working as expected (I have an "InnerNormal" and an "OuterNormal" in my grounding statuses, but it turns out they were never properly assigned)

I'll be repackaging and reuploading this now. Sorry!

Here's the behaviour with the fix. Exit velocity is always aligned with the slope:
https://drive.google.com/open?id=1i76eMEZYIJylCn5lH8CzZlQ2i_qaTkHv

 

It wasn't a game breaker by any means so no worries, thanks for the quick fix

 

Hello I've been playing around with the online demo and I found something that seems to be a bug. When the character is moving an object (basically the big blue cube specifically) and that object gets stuck, if I try to rub against the object, it seems to get me stuck as well unless I move away from the object as if the friction of the blue cube just suddenly went to infinity.

I had a similar issue where if I run along the edge between the checkered floor and the red mesh, I would occasionally get stuck as well.


Another thing. How well would this system work lets say if the character was moving really fast?

 

Are you using 2.1? I ask because there were some bugs that were fixed in 2.1 that may or may not relate to your problem.

 

Well I haven’t bought it yet so I’m just using the version that’s in the website demo. My guess is that is the old version since scrolling up it seems you guys addressed some very similar and potentially the same issues.

 

Thank you very much for taking time and aswering!

If I can ask you a follow-up question:
As I am quite new to Unity (and game programming in general) I have to ask for some clarifications.
So, as you said, my goal would be to make the KinematicCharacterController behave as it didn´t (only) have a capsule collidier, but additional collidiers/ another collider shape.
Did I understand it correctly, that you suggested that I should add new GameObjects to my scene, to which I would add a Rigidbody and my preferred collider. And these new GameObjects should not be "sub objects" of the KinematicCharacterController, but completely on their own?
Then I would write a Script to make these objects follow the kinematic character controller.
And I would set these rigidbodys to kinematic (as I control their movement via the mentioned script) and I would set them to "isTrigger", and handle some collision event (like "onCollisionEnter") and then I would use these collision infos to adjust the behaviour of my KinematicCharacterController object - e.g. it should handle that collision.
So you called this collision handling "decolliding", what do you mean with that?
Or in other words, can you explain me how to do this (or link a tutorial)?

I totally understand that my questions are outside of normal support, but I honestly don´t know who I should ask such a specific question otherwise.

Thank you!

 

That's right; I just forgot to update the WebGL demo and this is fixed in the store version. I'll take care of that soon

 

If you try running into a very thin wall at a speed of literally "Mathf.Infinity", the character will properly detect the collision and won't go through the wall.

The only cases I know where extremely high speeds could be problematic are:

• Running into tight corners or concave geometry ( like this case, but faster )
• Ground snapping when going over a slope won't necessarily work all the time if you're going really fast

These are potential improvements for the future, but not priorities for now

 

That's right. The three colliders/rigidbodies would be separate, and not parented to eachother

The collision events would have to be handled with Physics.OverlapCapsule and Physics.ComputePenetration instead of the OnCollisionEnter or OnTriggerEnter callbacks. With the default OnCollision callbacks, you'd always be one frame behind (this is kind of a complicated subject)

On every FixedUpdate, you'd

1. detect if the capsules are overlapping with anything, by using Physics.OverlapCapsule and Physics.ComputePenetration
2. manually move them so that they are not colliding with anything anymore (this is the "decollision" part)

basically you are handling the physics 100% manually, and making sure colliders don't go through eachother

There is unfortunately not much info on the subject because this is a relatively new addition to the Unity API, and not something people typically dare to bother with, but this page has a code example: https://docs.unity3d.com/ScriptReference/Physics.ComputePenetration.html

 

this fix is on the store now