[Released] Kinematic Character Controller

@deiterate Your solution works like a charm. Thank you!

You probably already figured out a solution for this, but in case anyone else is trying this, you can use easing curves for the interpolation by evaluating the values you pass into the blend parameters (in this case the "Pass" parameter) along an AnimationCurve like so:

Code (CSharp):

1. public AnimationCurve interpolationCurve;
2.  
3. animator.SetFloat("Pass", interpolationCurve.Evaluate(gaitPass));

It seems that curves that extrapolate, such as an elastic curve, aren't possible due to limitations of the animator state machine. I suppose you'd have to take the extra movement into account when making your poses and scale the curve down to fit between 0-1. If anyone has a clever solution for this, I'm all ears. I'm just dipping my toes into Unity's animation tools so I'm probably missing something.

 

Can someone help me with this? It's a pretty noobish issue, but I cannot solve it myself for hours, so the thread is my last resort.
While following the walkthrough at #3 - jumping, I had this little error where my character sometimes doesn't jump while the walkthrough example character is very consistent.

The Red capsule is my character controller btw
I'm pretty sure I put the input handling at the update and even started copy-pasting the walkthrough script on my own character. still no luck so far. This was also the reason I bought the asset, I was having a hard time with the jumping on my old character controllers.
Thank you for helping me in advance!

 

I am presently handling animation parameter curves similar to what you are describing. I added a base animation parameter class that handles setting up hash index / animation layer index and normalizing the values to whatever min / max is set on them. I didn't find a more elegant solution for elastic curves other than making my poses more extreme and using the min / max normalization to tweak the ranges.

 

Just a guess, but could be an issue of input handling and character update handling being in different update loops (Update() & FixedUpdate()). Rather than handling input and character updating directly in your character controller I recommend the method shown in the examples using a Player class that handles all the updating in the correct order. It really clarifies how things are being processed and makes debugging much faster. It's a pattern that helped me a lot, anyway.

 

@deiterate Since your blend trees are set up to handle an axis of motion in both directions, how do you approach blending, say, lateral motion with the forward motion you detailed?

 

I ended up editing the walkthrough script exactly the same way as my own script. It's now fixed, but I really don't get why is that happening, my version of input handling and the myplayer.cs (removed the mouse controls) are exactly the same thing, just with the different namespace and class name.

here's the comparison of my script and myplayer.cs
https://www.diffchecker.com/U7snCa1F

and here's the comparison of my controller and myplayercontroller.cs
https://www.diffchecker.com/MxpFdnj6

maybe breaking the myplayercontroller.cs will give me an idea of why this is happening. but I still appreciate your reply and the future replies regarding this.

 

It's likely in your character controller. Could be input and character updates are out of sync if you added unity event functions (update, fixedupdate) to your script, or jump handling parameters like grounding grace time, grounding distance etc. Depends on your implementation.

 

Ohh! I got it It was the grounding grace time! It was set on 0 so that's why I'm getting those inconsistent jumps!
I realized it after it does the same thing again when I'm in the process of adding my character on it.
Thank you so much @OldLegWig for helping me

 

Hi all,

I just submitted KCC 3.0 to the store. Should be approved within a few days. Mostly this brings a pretty big performance speedup, removes the need to have a Rigidbody component on the character object, fixes incompatibilities with newer unity versions, and deprecates some Walkthrough samples (networking & navmesh). Details here:

Spoiler: v3.0 Release Notes

• Minimum supported Unity version bumped to 2018.3
• General performance improvements. Simulating 1000 characters on flat floor on a given machine went from 14.1ms (v2.3) to 8.7ms (v3.0). This is a 1.6x improvement
• Cleared some warnings
• Deprecated Networking and Navmesh examples in Walkthrough. This was replaced with simple tips on the subject at the end of the walkthrough document. The reason for this is that it was too complicated to maintain (external packages, deprecation of UNET, etc...) and not complete or comprehensive enough to be that useful either way.
• Removed “Unity” interpolation method (the built-in interpolation for rigidbodies) in KinematicCharacterSystem. Interpolation is now entirely custom. This has several benefits:
  • Makes all character moves more performant because we don’t need to move with rigidbody.MovePosition() and MoveRotation() anymore. Saves us several other checks/operations as well
  • Completely removes the need to call Physics.Simulate() (or to rely on the Simulate() automatically called every FixedUpdate by default) in order to make the character movement simulation work. This is especially good for networked games with rollback & resimulation because it makes resimulation less costly
• Added a “StressTest” scene to easily spawn any given amount of KCC AI characters and observe performance
• Added “ExampleCharacter” folder containing the example character prefabs & scripts, so all the other example content is more easily deletable
• Fixed issues with animated PhysicsMovers (ship, walkthrough moving platform, etc...) in recent Unity versions
• General cleanup, refactoring & minor fixes

Again, apologies for not being present for a long while. I don't have an excuse aside from being way overworked. I would ask anyone who has sent me a question in the past but didn't get an answer to please reply with "bump" to their PM, forum post or email, so I know they still need an answer to their question. (even if your question was very recent)

-

 

Good to hear, looking forward to the update And it's understandable, overwork and burnout can be killer! You should check out the Discord b2hinkle created: https://discord.gg/gk4eYkh

 

Bump.

The original question:
How can I make a surface that the characters slips? Or make a collider that's not detected as ground, but the characters does not pass through it?

 

The update sounds awesome! Cant wait to try it out, glad you're back!

 

You can do this in "ProcessHitStabilityReport". Here, set "hitStabilityReport.IsStable" to false for the colliders you'd like to not be stable on

 

You mean you want your character to "bounce off" another character?

You could do this if you do an "AddVelocity" for the bounce force in your character's "OnMovementHit". Something like this:


but keep in mind "AddVelocity" is part of ExampleCharacterController, so you might have to copy it into your custom character class if it doesn't have it

 

@PhilSA

Hey Phil,

I notice that the latest release only supports 2018.3. is there anyway to get this working in LTS 2017.4?

Was there some breaking change that required it or was it just simpler to get the package approved this way?

I make a point of never upgrading beyond the LTS releases but I'd really like to update this plugin to get the performance increases.

Thank you,

Niall

 

Fantastic news! I just tried stres test scene tho and units just fall through the floor.
[Edit] Actually same thing happens on CharacterPlayground scene, using 2018.3.5 on macOS

 

is this a fresh import of the package, or is it an upgrade from a previous version?

 

I'm pretty sure it works just fine with 2017.4
The 2018.3 target for this release is just that I don't "promise" to fix any issue that would come up specifically for a past version. But I don't know of any issue with 2017.4

 

It was fresh package import but on "non-fresh" project, just tried fresh-fresh on Win10 and all is ok, will try same on macOS later today.

 

For anyone wondering, simply setting the character to "Towards Camera" and setting the Orbit Camera distance to 0, you have an instant first person controller. Thanks for the most awesome asset!

 

Thank you so much for the update @PhilSA !
We really appreciate your efforts in maintaining the system.

I have a question to ask though.
Is it possible to make the computed rootmotion's delta behave like the usual rootmotion + rigidbody?

like for example:
my animation's rootmotion Y has "Bake into Pose" checked.

• the usual rigidbody+animator without OnAnimatorMove() will just choose to ignore the posed Y axis which will make the character use the gravity instead.
• However, by computing the rootmotion from the animator.deltaposition and the formula from the walkthrough (currentvelocity = rootmotion / deltatime) with animation's Y axis baked into pose will make the player stuck in the air. We can just choose to fix it manually in the code but that would be very hard to maintain when it gets bloated.

 

Bump. Hi Phil. Sent you a very detailed e-mail about a problem I am having regarding stepping up not working if you're jumping against a wall and your step height in that jump goes over the limit. Provided info and screenshots.

Curious if you had a chance to take a look

Thank you!

 

Answered via mail. This actually solved a stepping issue that a few people have mentioned in the past, where stepping doesn't work while mid-air

 

When I try Y Bake Into Pose in the walkthrough scene, with an animation that has Y root motion, it does not move the capsule up. It does move the visuals/mesh up, but does not translate to an y velocity

 

but does it use gravity too? or it stuck/slowly falling? because in my case it does that.
in stock rigidbody+rootmotion the player will fall if the animation has Y bake into pose checked.

 

Your above comments are from an old reply in this thread.

@PhilSA
I just downloaded your awesome asset and played the PlayGround scene. I didn't go in depth yet.
In that scene, I found that if I scale the whole ExampleCharacter in the editor, it scales back to (1,1,1) when I play the scene.

When you say "scaling is not allowed", do you mean even 1:1:1 scaling to the Kinematic Character Controller is not allowed?
Is this related to "no scaling parameter" for Physics.ComputePenetration ?
However, I found you did scale other primitive colliders (e.g. scaled box colliders as walls), which works correctly in the PlayGround scene. Would you explain this scaling topic a little bit to me?

 

@PhilSA I really like your Kinematic Controller, weirdly smooth controller. I did some quick tests on Character Playground scene.

For the red Concave terrain mesh, if Safe Movement [x], Player while in crouching mode, cannot climb up it (uncheck fix it though).

For the red Concave steps, even I unchecked Safe Movement, Player while in crouching mode, still cannot climb up it (set it to Convex Mesh collider, fix it). Is it intended behavior or a bug? Thanks.

 

@PhilSA
Does Physics.ComputePenetration take use of some hardware accelerations? Like GPU acceleration?
Previously, to make such a KCC like your asset, I actually implemented Physics.ComputePenetration in Unity with C# by myself, which is similar to Super Character Controller guy's work. Now, I am wondering that if a KCC with Unity's native Physics.ComputePenetration will be much faster?

 

Bump. kinda important...
Physics.IgnoreCollision() is not working between KCC collider and another rigidbody collider.
Can someone confirm?
EDIT: I was too dumb to see the walkthrough 9 - custom collision filtering.
I kinda solve my own issue by myself with quick and short not the best method, which is motor.collidablelayers()

but consider this solved.

 

@LezTusi If you mean ExampleCharacterController.IsColliderValidForCollisions() not working, it's because the true and false in the following code is reversed:

Code (CSharp):

1. if (IgnoredColliders.Contains(coll))
2. {
3.       return false;
4. }
5. return true;

As far as Physics.IgnoreCollision(), I haven't tested or used that static function with KCC at all, can you elaborate when and how you are trying to use it?

 

@LezTusi I realize now what you meant with Physics.IgnoreCollision(), there is a bug in the example character that incorrectly ignores colliders, which is what I thought you were talking about.

The way that the KCC does its own collision handling means that it currently cannot take advantage of that function in unity's physics engine, so far as I know. I can confirm that it does not work with the test setup I tried. The character controller does cache the physics collision matrix for its own collisions, but I believe that physics function adds a check between just those two colliders, which the KCC system wouldn't be aware of.

However, if you correct the character controller's IsColliderValidForCollisions callback, and add the rigidbody's collider to the character controller's ignored colliders list, that will let the KCC system know to ignore collisions with that collider.

I set both the Physics.IgnoreCollision() and added the rigidbody's collider to the character controller's ignored colliders list to get them to fully ignore each other.

 

hii, i used this kinematic character controller on my boucing ship, but it slides away?? is this normal or does it only work if i make my character child of the ship??

 

Whoa, missed the new release. Looks great, I'm excited to try it out!

 

The only scaling that's not permitted is on the KinematicCharacterMotor gameObject itself, because a lot of the calculations in there would need to compensate for it. Last time I checked, ComputePenetration does take scale into accout so that's not the reason for this limitation. Parenting the KCM object to a transform that has a non 1,1,1 scale is not allowed either.

However, any other object in the level can be scaled. And child objects (typically the meshes) of the KinematicCharacterMotor object can be scaled as well

 

That does seem like a bug. I will investigate

 

Physics.ComputePenetration uses some of PhysX's internal functions to do the job (they were there all along, just not exposed to users in Unity). It is not GPU accelerated but in most cases I would assume it's more performant -or just as performant- as trying to do it manually

 

Just to clarify, Physics.IgnoreCollision() does not do anything for KCC because it only affects regular collision/trigger detection between colliders. KCC uses queries like CapsuleCast and OverlapCapsule for all of its collision detection, so that's why this has no effect

 

If you want the character to stay on the ship just like in the example, your ship needs to have a PhysicsMover component and move exclusively via the PhysicsMover's update functions

See the Walkthrough section on creating a moving platform for more details

 

https://bintray.com/unity/unity-staging/com.unity.physics

I think I'm gonna get started on KCC v4.0

 

@PhilSA

Thanks a lot for your answers.

When you say "ComputePenetration does take scale into account", would you explain how it works with KCC?
I have a look at that API. It takes parameters of Collider, position, rotation, but... no scale or transform?
Thus, I guess it works like this: it takes the scale of gameObject.transform into calculating? If this is true, why it accepts parameters of rotation, instead of simply using the rotation of gameObject.transform directly?
Or, this API applies two rotations together, one is from the gameObject, another is from this parameter rotation as some extra offset?

 

Haha, I just came in here to check whether someone had posted about Unity's new ECS physics. Awesome!

 

can you share us some insight/point of view about ECS version KCC ? i saw a CharacterController demo along with unity.physics, quite smooth then...

 

@PhilSA
Hi Philsa,
Found your great asset and just one question before buy it.
e.g. There're a player and an enemy in the scene, both of them have colliders.
I wanna make they can "stop" each other like a wall and they should not "push" each other to out of their current possition.
The question is dose KCC can make it easily?

 

In the demo, the "pushing" effect is simply due to the fact that the character capsules are circular, so they deviate eachother's trajectories when they move against eachother.

But they can't effectively be pushed by other characters (unless you explicitly script that): https://i.gyazo.com/81b35f267228378863d36554b846c498.mp4

 

The CC in the UnityPhysics samples doesn't seem to be doing ground snapping or proper slope handling, etc..... Here's the character trying to move back and forth on a slope, for instance. Movement is pretty janky too in this case. I have yet to study it more in-depth but so far I think it's more of an example than a real solution

So far I'm in the really really early stages (I set up a new project with UnityPhysics, Entities package, HDRP, new Input System, Addressables, etc...) and it's going to take some time before I have something working, but I'm pretty sure I can make ECS KCC much better design-wise than its predecessor. My experience with KCC and my attempt at an ECS Physics Engine last year have taught me a lot, and there are definitely things I would do differently now. I'm gonna think about supporting "dynamic rigidbody" mode, and any collider shape, but no promises.

Performance-wise, let's say if UnityPhysics ends up being no faster than PhysX, we can still expect massive speedups because all the physics queries will be multithreaded. So if now we can have 2000 characters at 60fps, with ECS KCC that number could get multiplied pretty quickly based on number of CPU cores. Another big speedup will come from all the vector math that will now be compiled in Burst (and there's tons of vector math in KinematicCharacterMotor). Legacy math in Mono/Unity is very slow compared to what could be possible in Burst or C++

 

I'll admit I don't really know why ComputePenetration works with scales. Perhaps colliders are a special case and their scales are actually "baked" into their collider sizes as far as the physics engine is concerned.

 

Hi.
Thank you for your quick relpy.
Just watched your video and wanna know what kind of collier dose this asset support?
Just capsule? Can I ajust the collider size?
I mean that if my npc is an animal (not human style), can I ajust the collier size to fit, for example a pig?

 

Unfortunately, capsule is the only supported collider type, and it has to be an "upright" capsule too (in the gameobject's transform's localSpace).

 

This ECS lark sounds good. I imagine it would work with dots physics and Physx? Might even chuck my own and give it a try again if you sorted out the minor issues with jumping against walls and so on.

Did you have a chance to test it against terrains where the terrain has "walls" or slopes too steep to climb? can be quite ugly with lower heightmap res / larger scaled terrain, and maybe not possible to fix.

 

No idea at the moment. I'll have to see how much trouble it is to support both simultaneously, but atm I will prioritize UnityPhysics/Havok for the ECS version.

Could you remind me / re-explain what those issues were in more details?