[Samples Project for 0.2.5-preview]Character controller issue.

This is my modified CharacterControllerUtilities that remove the trigger part and ClampToMaxLength.
And I do the first CalculateDistance outside of the CollideAndIntegrate because of i need to save the result to a DynamicBuffer, like this:

Code (CSharp):

1. var distanceHitsCollector = new DynamicBufferCollectorWithout<DistanceHit>(rigidbodyIndex, instance.contactTolerance, distanceHits[index].Reinterpret<DistanceHit>());
2.  
3.             ColliderDistanceInput input = default;
4.             {
5.                 input.MaxDistance = instance.contactTolerance;
6.                 input.Transform = isRotateAll ? transform : math.RigidTransform(originRotation, transform.pos);
7.                 input.Collider = (Collider*)(isHasCollider ? colliders[index].value.GetUnsafePtr() : rigidbody.Collider.GetUnsafePtr());
8.             }
9.  
10.             physicsWorld.CalculateDistance(input, ref distanceHitsCollector);
11.  
12. public struct DynamicBufferCollectorWithout<T> : ICollector<T> where T : struct, IQueryResult
13.     {
14.         private int __maskIndex;
15.  
16.         public bool EarlyOutOnFirstHit => false;
17.  
18.         public int NumHits => hits.Length;
19.  
20.         public float MaxFraction { get; }
21.  
22.         public Unity.Entities.DynamicBuffer<T> hits;
23.  
24.         public DynamicBufferCollectorWithout(int maskIndex, float maxFraction, in Unity.Entities.DynamicBuffer<T> hits)
25.         {
26.             MaxFraction = maxFraction;
27.             __maskIndex = maskIndex;
28.             this.hits = hits;
29.         }
30.  
31.         #region IQueryResult implementation
32.  
33.         public bool AddHit(T hit)
34.         {
35.             if (hit.RigidBodyIndex == __maskIndex)
36.                 return false;
37.  
38.             hits.Add(hit);
39.        
40.             return true;
41.         }
42.    
43.         #endregion
44.     }
45.            

I try the original CharacterControllerUtilities.cs,and get the same result.

 

This is the original CharacterControllerUtilities i use from the github.

 

Hi,@petarmHavok ,I can repo this issue in the cc demo.
I add two line in CharacterControllerAuthoring.cs line 210:

Code (CSharp):

1.  
2.                 // Calculate actual velocity with respect to surface
3.                 if (ccInternalData.SupportedState == CharacterSupportState.Supported)
4.                 {
5.                     CalculateMovement(ccInternalData.CurrentRotationAngle, stepInput.Up, ccInternalData.IsJumping,
6.                         ccInternalData.LinearVelocity, desiredVelocity, surfaceNormal, surfaceVelocity, out ccInternalData.LinearVelocity);
7.                 }
8.                 else
9.                 {
10.                     ccInternalData.LinearVelocity = desiredVelocity;
11.  
12.                     ccInternalData.LinearVelocity.y -= 10000.0f;
13.                     stepInput.MaxMovementSpeed = float.MaxValue;
14.                 }
15.  

 

Hi,@petarmHavok ,is it a bug?
I need to release my game next week.
Can give me some suggestions or temporary solutions?

 

Hey, I'll take a look soon, and I'll let you know as soon as I figure something out!

 

Alright, I see some strange behavior (including tunneling) with the velocity set to -10000. I'll definitely investigate that. But your cases from the game didn't include velocities this high, right?

 

Yes,but my cc penetration frequently when walking.maybe it's because my physics systems run in fixed update and step time is large.

Maybe similar to "high velocity".

 

Other systems are not relevant for CC (unless you want it to push dynamic bodies), the question is what do you set to CharacterControllerJob.DeltaTime? By default, it's UnityEngine.Time.fixedDeltaTime. Even if you have this fixedDeltaTime set to something like 0.25, that's still around 2.5m/s per frame of gravity effect. So if your character is falling down for like a minute, that's 150m/s, still a lot smaller than 10000m/s.

 

I guess the times of "penetration recovery"(4 frame per sec) less than cc demo,so It looks more strange.
look like the video in #47 .

 

If you have doubts about the penetration recovery velocity, I can try to help with that.

First, make sure SimplexSolver.ClampToMaxLength is public.

Then, locate ResolveConstraintPenetration() in CharacterControllerUtilities.cs and add SimplexSolver.ClampToMaxLength(1, ref newVel); before you assign newVel to constraint.Velocity.

This should give you a max penetration recovery velocity of 1m/s. And furthermore, it will remove the need for setting MaxMovementSpeed which was causing you issues in the first place.

Let me know if this is any better. You can also play with values, I've put 1m/s as a good indication, but you can go higher or lower if it suits you.

 

I figured out one tunneling fix, you are probably hitting this as well.

In CharacterControllerUtilities.cs, locate

hit.Fraction * math.length(displacement)

as a distance that is passed in to the CreateConstraint() function and replace that distance with

math.dot(-hit.SurfaceNormal, hit.Fraction * displacement).

It does the trick in the repro case you provided in the samples with velocity of -10000. Let me know if it works for you!

 

This is good news,I will try right now!

 

Hi,@petarmHavok .it looks very better than before, no "penetration recovery" now.
But I need more time to make sure tunneling has been fix,I will make more test cases during the next few day.

 

Thanks for letting me know! Glad it helped! Please report back once you tested it further...

 

Hello, we copied the character controller and added it in our project and noticed that the velocity of the player is frame-dependent.
So if the FPS decrease the player moves slowly, while when the FPS are high the player moves at a higher velocity.
What should cause this problem?
Has been the problem noticed by someone else?

We are using Unity Physics (not Havok)

Thank you,
Marco

 

Unity Physics expects a fixed time step, but is currently run frame-rate dependent (this is due to waiting for upcoming changes to ECS). To fix this you can either constrain Unity Physics to run at a fixed rate or you could modify the character controller to take frame time into account.