[Released] Kinematic Character Controller

@PhilSA:

Apologies! I applied your proposed fix, but unfortunately, I'm still having that same issue.

In the next few minutes, I'll send you a link to your support Email (as listed on the asset store) so you can download my project. At this point, it's really just some Character Controller basics and setup framework.

The slope immediately to your right when you start is the one that you should not be able to slide up.

Hope that helps!

Thank you again and be well!
- S.

Edited: Sent! Hopefully that will help you with your diagnostics. Thank you again.

 

Got it. I'll take a look at this later today

 

Much appreciated, sir!

Thank you.
- S.

 

Update 1.2.2 released:
- Fixes made to allow creating character objects at runtime
- Made character rigidbody and capsule non-editable through HideFlags

 

@PhilSA:

Thank you for all of the assistance via Email regarding my Character Controller climbing steep slopes! Indeed, the issue with entirely within my own code, and I've resolved it now. Thank you!

I've updated my run-time instantiation code. The new approach works flawlessly. Thank you!

Now, I just have to keep my fingers crossed that other users are interested in a cylindrical Character Controller simulation!

Thank you again so very much! Be well!
- S.

 

How do I manually execute when the character controller updates? It looks like it is all handled in KinematicCharacterSystem.FixedUpdate, with no way to separate it out for just one character. I need to be able to rerun inputs for one character only on the client for client prediction for multiplayer networking.

Also, what would be the ramifications of making CollidableLayers modifiable? I have different playable races, each with different collision layers, but they are currently all on the same layer. So setting physics layers isn't an option with that setup. Coming from Super Character Controller I was able to set the collision layers per controller, so I designed it around that.

 

You would basically re-run the same things that are run in the KinematicCharacterSystem.FixedUpdate, but just for the character(s) that needs to be simulated (if you have several characters to simulate, it's better to do them all at once for performance)

The Kinematic Character System In-Depth section of the User Guide explains what all of this is and why they are necessary

But in short, if you want to make your own simulation, you can basically copy/paste the contents of KinematicCharacterSystem.FixedUpdate, and just remove the entire "if(UseInterpolation)" part. For a single character, it would give you something like this:

Code (CSharp):

1.  
2.  
3.         private void SimulateCharacter(KinematicCharacterMotor characterMotor, float deltaTime)
4.         {
5.             int moversCount = PhysicsMovers.Count;
6.  
7.             // Update PhysicsMover velocities
8.             for (int i = 0; i < moversCount; i++)
9.             {
10.                 PhysicsMovers[i].CalculateVelocities(deltaTime);
11.             }
12.  
13.             // Character controller update phase 1
14.             characterMotor.CharacterUpdatePhase1(deltaTime);
15.  
16.             // Simulate PhysicsMover displacement
17.             for (int i = 0; i < moversCount; i++)
18.             {
19.                 PhysicsMovers[i].SimulateAtGoal();
20.             }
21.  
22.             // Character controller update phase 2
23.             characterMotor.CharacterUpdatePhase2(deltaTime);
24.         }

You can exclude the simulation of PhysicsMovers if you want to, but keep in mind this may introduce deviations between your custom simulation and the real simulation if your character would've interacted with any PhysicsMovers during its movement.

 

Great, thanks! I'll give that a shot and see how it goes.

I edited my other post above with another question before you had replied, did you notice it?

 

CollidableLayers acts just like rigidbody collision layers. So let's say you decide to remove the Default layer from CollidableLayers, the character will go right through all Default layer objects.

If I understand correctly, modifying it should give you what you want

 

Alright thanks. Just wanted to make sure since it's marked as private set currently.

 

I should probably make it public in the future. No real reason for it to be private

 

Which one of the velocity properties should be used to control an animator blend tree?
Right now I'm using this, but it doesn't work well when climbing stairs.

Code (CSharp):

1.  
2.         var motor = _characterController.KinematicCharacterMotor;
3.         var velocity = motor.Velocity;
4.         var fwdSpeed = Vector3.Dot(velocity, transform.forward);
5.         var rightSpeed = Vector3.Dot(velocity, transform.right);
6.  
7.         _animator.SetFloat("SpeedForward", fwdSpeed);
8.  

I could isolate the vertical speed component as well and add that, but it wouldn't help much. Since that would also make the character play a forward/backward animation when falling/climbing.

On the ground it works ok, but on stairs: https://streamable.com/7ykii

Is there any built in smoothing for stairs maybe? (Smoothing movement on the Y axis)

 

Here's a quick test I did for animation + stairs. I use only the KinemaitcCharacterMotor.BaseVelocity magnitude directly to drive the animation (BaseVelocity is better than Velocity because it excludes moving platforms velocity):
https://gyazo.com/3319953d25d8917d722c9938cecfb3f2.mp4

To be more clear, my run animation blending is driven by a "MovementAmount" parameter that goes from 0 to 1. That MovementAmout is determined by (.BaseVelocity.magnitude / MaxMoveSpeed)

I think the issue in your code snippet is that you exclude vertical motion completely with that dot product, but the velocity when going up stairs will necessarily have a vertical component, hence why the animation is stuttering.

The strategy to adopt here would be to make sure animation handling is different when not stable on ground

 

When I reset the players position and rotation for client prediction rerunning inputs, would it be bad to also reset the BaseVelocity in the motor? Of course making it a settable property as well.

 

You're absolutely right, BaseVelocity and IntRgbdyVelocity should be settable as well. I'm taking note of this for the next update

I'll also add a "SetPosition" and "SetRotation" to make things more clear for when you want to place the character at a specific position. Many people don't know whether they should do this via transform.position or rigidbody.position or rigidbody.MovePosition, etc, etc..... The real way to do it is with transform.position, but it's understable that people can have doubts regarding this

 

I may consider shifting my priorities to making a networking example before I continue with anything else (the FPS/Platformer/Adventure game examples with animated characters). From the looks of it, it would surely make me realize that a few minor changes like the ones mentioned above are necessary.

Support has taken up the large majority of my time lately but it's starting to get a little bit calmer now that updates 1.2.x have been released. I should have the time to tackle this soon enough

 

@PhilSA

Of course, you are completely right, I feel so dumb now haha.
I solved the problem using the obvious solution. For anyone wondering what that is.
Here's the code along with some comments.

Code (CSharp):

1.  
2.         var motor = _characterController.KinematicCharacterMotor;
3.         var velocity = motor.BaseVelocity;
4.  
5.         // Movement magnitude of z (forward) and y (up) axis combined
6.         var zxSpeed = Vector3.ProjectOnPlane(velocity, transform.right).magnitude;
7.  
8.         // Since we only have the magnitude, we need to determine if we're moving forwards or backwards
9.         var isForward = Vector3.Dot(velocity, transform.forward) >= 0;
10.         if (!isForward)
11.             // And then adjust the sign if needed
12.             zxSpeed = -zxSpeed;
13.  
14.         // We also want to know about our "left right" movement
15.         var rightSpeed = Vector3.Dot(velocity, transform.right);
16.  
17.         _animator.SetFloat("SpeedForward", zxSpeed);
18.         _animator.SetFloat("SpeedLeftRight", rightSpeed);
19.  

Though it seems you're using the blend type 2D Freeform Cartesian, right? Because using only an absolute value like that doesn't give the animator a direction at all, so it wouldn't even know whether to go forward or backward, or if it should strafe...
My problem is solved, just curious how that works in your example.

 

The animation in that example is just handled with an overly-simplistic 1D blend between the idle and runningForward anim. (I only did this as a quick test)

I have not yet decided if I want to use Mecanim or the Playables API directly for my examples. My personal preference in a serious project would be Playables API by far, but it may not be as accessible as Mecanim

 

Great, thanks!

 

So I finally got things converted over enough to be able to test it in game, and the client prediction is very jittery. In KinematicCharacterController.CharacterUpdatePhase2 line 638 it sets the final position using the rigidbody. If I change that to the transform instead the jitter goes away. Thoughts?

 

This could get pretty complicated....

Using a transform move instead of a rigidbody move doesn't make any difference aside from the fact that there will be no interpolation. So your characters will always move at 50 fps (the physics rate by default)

My guess is that the jitter happens because some changes get written into the transform at some point during the simulation code, which causes the transform to be marked as dirty, and which then conflicts with the rigidbody moves.... I will have to make some tests this week for this. I'll PM you and post back here once I've cleared things up

 

Okay sounds good, thanks.

 

Maybe I'm dumb, I'm not sure. I'm trying to find a solution on making my character rotate when moving the joystick, similar to that of a mario game. however I'm running into some strange bugs. such as if I press my horizontal axis exactly on 1 then it will not rotate, I physically have to rotate it first, as well as I can't even rotate if I don't have something in there using a quaternion lerp to force it to move on the forward axis away from the camera. :|

Perhaps you have an API somewhere that I missed?

 

I think I may have found the cause, and it's an error on my part; just try adding this to the ExampleCharacterController:

Code (CSharp):

1.  
2.         private void Awake()
3.         {
4.             _smoothedLookInputDirection = KinematicCharacterMotor.CharacterForward;
5.         }

If this doesn't solve it, then I might need some more clarifications on how to reproduce the bug

 

I tried so many methods I ended up with this ugly thing, but I'm still trying to figure out how to get it clean and .. not this

made it work, simplified to this

Code (CSharp):

1.  
2.             if(fullRotation)
3.             {
4.             _smoothedLookInputDirection = Vector3.Slerp(_smoothedLookInputDirection, _lookInputVector + KinematicCharacterMotor.CharacterRight * Input.GetAxis("Horizontal"), rotationSpeed*Time.deltaTime);
5.             currentRotation = Quaternion.LookRotation(_smoothedLookInputDirection, KinematicCharacterMotor.CharacterUp);
6.             }
7.  

 

@Jdfskitz
In that code snippet, you modify the transform position directly, which will surely cause trouble with physics/stuttering at some point. And overall this isn't really how you should use UpdateRotation. UpdateRotation expects you to modify the "currentRotation" Quaternion and then the KinematicCharacterMotor will take care of applying that rotation correctly

But here's something that might guide you in the right direction:

1. Take the ExamplePlayer and ExampleCharacterController exactly as they are when you download the package
2. In ExamplePlayer, there's a line where we set inputs on the character. I think it looks like this (it might vary depending on the version of the package):
   
   Code (CSharp):

   1. Character.SetInputs(cameraOrientedInput, camDirectionProjectedOnCharacterPlane);
3. Try changing that line to this instead:
   
   Code (CSharp):

   1. Character.SetInputs(cameraOrientedInput, cameraOrientedInput.normalized);

Now if you try out that character in the CharacterPlayground scene, you'll have a character that rotates towards its move direction. All we did is that we told the ExampleCharacterController to rotate towards its move direction instead of rotating towards the camera direction

 

lol, thank you very much. I feel like an idiot xD I've spent so much time on this. I got it though.

 

Hello! I'm making a game, where whole world (including physics) could be slowed down with exception for certain characters, such as protagonist and bosses.

I've managed to modify your plugin a bit to get desirable results, but there is one problem: when I change timescale and physics timestep - at that same moment my character jitters on the moving platforms and can even be thrown away. I guess it has something to do with collision handling (changing CharacterRigidbody.maxDepenetrationVelocity didn't help).. Motor's _baseVelocity just suddenly raises when I set timeScale back to 1 and fixedDeltaTime to 0.02 while standing on a mover. Could you give some advice - where to dig to fix this issue?

Things I've changed: added a float timeScaleInfluence to a Motor, changed the way characters receive forces from the moving objects, so the less timeScaleInfuence - the less movement is applied to a character, otherwise they's slide on top of the movers. + Customized deltaTime inputs in the characterController.

 

Do you have any intention of supporting character shapes other than a capsule? It would be nice to have a shape closer to a box for quadrupeds.

 

This will not be supported, because it would require a completely different character controller in many aspects. With a capsule, you can make all sorts of assumptions and optimizations that would be invalidated if multiple shapes were supported. However, after having worked on a boxCollider-based quadruped character controller for several months in the past, I would not use a box if I had to do it again. Box-based characters have too much trouble with ledge and slope handling. Instead, I would use two capsules that follow each-other, with an additional capsule to make the bridge between them

Okay, I managed to implement this successfully on my side and here's what I did:

1. Create a 'Timescale' float variable in the KinematicCharacterMotor
2. In the CharacterUpdatePhase1 ,2, and 3 methods, add a line where you multiply the deltaTime by the TimeScale. Like this:
   
   (make sure this is done before anything else, in all 3 methods)
   At this point, you have proper timeScale control over individual characters, but moving platforms are still a problem
3. In CharacterUpdatePhase1, there is a block of code where we do Interactive Rigidbody handling:
   
   Expand those two regions and look for the 3 places within these lines where we used the local "deltaTime" variable. Replace them with "Time.fixedDeltaTime". (basically we're saying that the moving platform's deltaTime must be used instead of the character's). Make sure you replace all 3 deltaTimes.

And that's pretty much it. Modifications to forces and inputs should probably not be added. I haven't tested very extensively so let me know if you find any problem

 

OK! It works almost perfectly! The only place where some tweaking needed - when I jump off the mover in slow-motion, my character flies off like baseVelocity was added with un-slowed velocity of mover.

By the way: is it possible to use GetVelocityForMovePosition() like CharacterController.Move() ?

 

I think I got it; there are 2 more modifications to make:



In the same code section as before, you must add a " / Timescale" to velocities when landing on an InteractiveRigidbody and when un-grounding. See pictures above

Yup that is the intended purpose. Use it in "UpdateVelocity" to calculate the velocity you would need to move to a position on the next update

 

And now it works just as expected!

My case differs from yours a bit, so my code looks more like this:

Code (CSharp):

1.  
2. // Conserve momentum when de-stabilized from an interactive rigidbody
3.                 if (PreserveInteractiveRigidbodyMomentum && StableInteractiveRigidbody == null && _lastStableInteractiveRigidbody != null)
4.                 {
5.                     _baseVelocity += _stableInteractiveRigidbodyVelocity * Mathf.Lerp( Time.timeScale, 1f, timeScaleInfluence );
6.                 }
7.  
8. if (StableInteractiveRigidbody != null && _lastStableInteractiveRigidbody == null)
9.                 {
10.                     _baseVelocity -= Vector3.ProjectOnPlane( _stableInteractiveRigidbodyVelocity, CharacterUp ) * Mathf.Lerp( Time.timeScale, 1f, timeScaleInfluence ) ;
11.                 }

I globally change timeScale with fixedDeltaTime, and define how much certain characters ignore slow-motion.

 

So was looking at the profiler with a bunch of moving platforms. The controller physics is topping my cpu list. With 50 characters 44 moving platforms, between raycasts, OverlapCapsule, and CapsuleCast, it's hitting upwards of 1800 calls in a frame. Averages just above 600.

Just wanted to see if that sounded right.

 

600-1800 casts per frame for only 50 characters doesn't sound normal (unless your game runs at like 10 fps, in which case you would see the results of 5 FixedUpdates every frame)

Normally, you get roughly 2 CapsuleCasts and 1 OverlapCapsule per character per update:

If your character is actively moving against a corner or against very high-resolution collision geometry, then this number can go up a bit (1-2 more casts/overlaps per character), but your numbers still don't seem normal. I know from past discussions that you might also be dealing a lot with moving platforms, so I double-checked what happens if I put my 50 characters on a moving platform; and the amount of casts stays the same

I have a few questions in order to begin solving this:

• What version of Unity are you using?
• What does your scene look like, in terms of collision geometry?
• Has the KinematicCharacterMotor script been altered?
• Can you post a picture of the KinematicCharacterMotor inspector of one of your characters?
• If you put your 50 characters in a basic scene (such as the CharacterPlayground scene), do you still see an unnatural amount of CapsuleCasts?
• Can you take a screenshot of the profiler with the expanded FixedUpdate task?
• In Edit > Project Settings > Time, how much is your "Fixed Timestep"?

 

Here is I think 57 character controllers in game just standing on land.


What I noticed is my raycasts are much higher.





The spikes I was seeing before, I just forgot about the behavior of fixed update, I'm sure I was seeing it hit more then once.

I tested this again using ships which involves the moving platforms. Accounting for fixed updates hitting at the same time the numbers look close to what the controllers just standing on ground look like.

 

@snacktime
My bad. I unintentionally had "step & ledge handling" set to false on all of my characters except one. Here's the real profiler frame for 51 moving characters:


so that means the numbers you are seeing are probably normal. The CharacterSystem FixedUpdate may be at the top of your profiler page, but that just means there's nothing else in your scene that single-handedly takes more time than handling movement for 50+ character controllers at once.

On my machine, this takes 1.35 ms per frame in total in editor mode; so that means roughly 0.026ms per character. In a build this goes down to 0.88 ms total (0.017 ms per character)

 

Is it possible that the grounding code doesn't work well with client prediction rerunning inputs? I'm using this to check if a player has landed in the falling state, but I'm getting lots of jitter for client prediction
!Motor.WasStableOnGround && Motor.IsStableOnGround

 

I'll soon get to the point where I can implement client prediction/lag compensation myself in a walkthrough example and answer you more clearly (I've been busy with setting up a basic networking environment for the example with NetworkTransport until now),

but for now, I can only tell you how things should be done in theory:

1. Recieve the character state from the server and apply it
2. for each inputs that you've registered locally since then...
   1. Set inputs on the character controller
   2. Call CharacterUpdatePhase1 (with Time.fixedDeltaTime as parameter)
   3. Call CharacterUpdatePhase2 (with Time.fixedDeltaTime as parameter)

However, if you did this as I described and still get jitter, I have two theories:

1. There's more stuff in the KinematicCharacterMotor that needs to be reverted to the previous state, aside from position, rotation, and velocity. You probably need to revert a lot of the state information too, such as IsStableOnGround and WasStableOnGround. I think I'll probably put all of these important things in a "CharacterState" class, so that it will be more clear what you need to
2. There very well my be something interfering with interpolation when you re-simulate like that, and this may be the cause of the jitter. Especially if you are on Unity 2017.2 or above, since they changed a lot of stuff related to that (AutoSyncTransforms).

 

Yeah, I'm already doing that. I use Bolt for networking, which takes care of a lot of the internal logic related to client prediction. I also had my client prediction working pretty well with Super Character Controller. I'm on 5.6.2. It does sound like there's probably additional state data that needs to be synced.

 

Rotation Inquiry -->

problem solved.

Code (CSharp):

1.                 currentRotation = Quaternion.LookRotation(AssignedCharacterController.WorldspaceCharacterPlaneMoveInputVector);
2.  

figuring it out little by little

now I just have an issue where when I let go of the joystick his rotation resets

 

Is there a way to get the diff of the changes to the KinematicMotor or other classes?

Maybe git access or something? I made some changes for my game and I'd like to see the fixes/updates/changes directly so I can apply them to my own version.

 

It would be possible to use this: https://www.diffnow.com/
and just compare the vanilla version from the previous update with the next

The changes I've made so far in KinematicCharacterMotor are very simple (changed some private's for public's, added SetPosition/Rotation methods, etc...), so I don't think the upgrade would be a lot of work

 

Ah, I never noticed that I forgot to add rotation to the NoClip mode! But yeah, it's really just that there was nothing that told it to rotate

 

any ideas on what I could do to prevent it from snapping back?

 

Right now you're making it rotate towards its move input vector. When you let go, that vector will be zero, and that's why the reset happens. To solve this, only modify rotation if the move input vector isn't zero

 

Got it! thank you!

 

Hey.
Just bought it now and ran the example scene. It was very stuttery. I had to turn off Auto Sync Transforms and set my fixed timestep to 0.001. Smooth as butter after that.
You might want to add a warning to Unity 2017 users to do this otherwise some might get a bad first impression. So far so good.

 

I will definitely check this out. Normally, things should be working smoothly with or without autoSync, and with any fixedTimeStep (even if it's 1 second), but I wonder if the last update broke this. What version of unity are you using?

 

@Rademanc
ok so I'm back from doing tests in 2017.2f3 and 2017.3b10, with a fixed timestep of 0.02, and with autoSyncTransforms on and off.

And I haven't been able to reproduce the issue yet. We might have to dig a little deeper to find out what's going on, so here's a few questions:

1. Did you import the package into an existing project? If so, do you still have the problem is you try importing it in a completely new/empty project?
2. Which OS are you running the Editor on? (Win/Mac/Linux)
3. What is the "target platform" that is currently set for your builds
4. Which specific version of Unity are you using?
5. Do you think the stuttering might look like this issue, or is it more obvious than that?