Checking if CharacterController Is Grounded

[_untitled_]

How do I check if the player is grounded (able to walk)? I can't seem to be able to find it.

[Norbo]

CharacterController.SupportFinder.HasTraction will tell you if it is both grounded and on a slope which is walkable. CharacterController.SupportFinder.HasSupport will tell you if it's touching the ground, regardless of whether or not it's on a walkable slope. If HasTraction is false and HasSupport is true, the character is sliding.

[_untitled_]

Thanks.
I've also noticed that jumping/falling is kind of weird in that the gravity is unrealistic (really slow) even though the gravity is set to 9.8m/s^2. The player movement also seems weird; if you quickly change the yaw of the player, it'll take some time to stop before continuing in the new direction. If the player is in mid-air and lands on a slope, he'll slide down the slope. Is there a way to "pull back" the physics and just have basic entity collision detection with input? I don't need any fancy stuff.

[Norbo]

I've also noticed that jumping/falling is kind of weird in that the gravity is unrealistic (really slow) even though the gravity is set to 9.8m/s^2.

Is your character very large? If gravity is 9.8, that implies the character should be roughly 2 units tall to be humanlike relative to gravity. If the character is taller than that, things will feel 'slow.'

Additionally, if your character is large, I imagine the CharacterController.HorizontalMotionConstraint.MaximumSpeed properties have been increased, but the default MaximumForce and other force properties on the HorizontalMotionConstraint aren't high enough. This will make acceleration and deceleration seem sluggish, just like gravity. Check the BEPUphysicsDemos usage of the CharacterController for reference behavior.

If the character is roughly 2 units tall and things still feel slow with ~9.8 gravity and default settings, the space may not be updating at the needed rate. Each time step covers Space.TimeStepSettings.TimeStepDuration of simulation time. Space.Update() without a parameter takes a single time step. Space.Update(dt) takes as many time steps as it can to reach the accumulated time (up to a configurable maximum which defaults to 3). A couple of common related issues include:
-calling Space.Update() an insufficient number of times for the amount of game time passing;
-calling Space.Update(dt) with an excessively large value that runs into the Space.TimeStepSettings.MaximumTimeStepsPerFrame every call; this is usually coupled with other scaling issues and often involves using gameTime.TotalMilliseconds instead of gameTime.TotalSeconds as 'dt'

Is there a way to "pull back" the physics and just have basic entity collision detection with input? I don't need any fancy stuff.

It's generally more work to make things less physical- avoiding natural physics implies that everything must be tightly controlled, dumping all the responsibility on you. It would require a greater understanding of the collision detection pipeline and the character controller in particular. It's doable, but I don't recommend it.

Instead, I would recommend just tuning the physical simulation to produce the results you want. Working within a consistent physical system helps avoid nasty corner cases.

[_untitled_]

I am setting the character to a height of 1.6, a mass of 70, and I'm running Update with dt = gameTime.ElapsedTime.TotalSeconds.
The player jumps barely more than 1 unit and "slowly" descends. It feels like the game is taking place on the moon.

And for the traction issue (quickly turning), how would I increase the traction/friction?

[Norbo]

I am setting the character to a height of 1.6, a mass of 70

A mass of 70 would explain the slow movement control. The default MaximumForce values are tuned for the default mass of 10.

The player jumps barely more than 1 unit and "slowly" descends. It feels like the game is taking place on the moon.

That doesn't sound like expected behavior. Is the CharacterController.Body.LinearDamping being set to anything above zero? Other than that, I can't think of anything off the top of my head that would explain it. I would recommend checking out the BEPUphysicsDemos usage of the character and doing comparisons to isolate where the behavior is coming from.

And for the traction issue (quickly turning), how would I increase the traction/friction?

CharacterController.HorizontalMotionConstraint.MaximumForce, MaximumSlidingForce (for when the character has support but no traction), and MaximumAirForce (when airborne).

[_untitled_]

A mass of 70 would explain the slow movement control. The default MaximumForce values are tuned for the default mass of 10.

Setting it to 10 fixed the "laggy" response problem. Out of curiosity, why 10? Isn't the normal human being 70kg?

That doesn't sound like expected behavior. Is the CharacterController.Body.LinearDamping being set to anything above zero? Other than that, I can't think of anything off the top of my head that would explain it. I would recommend checking out the BEPUphysicsDemos usage of the character and doing comparisons to isolate where the behavior is coming from.

It's the same compared to the demo. I guess I was too used to the quick jumping of my old AABB collision system.

CharacterController.HorizontalMotionConstraint.MaximumForce, MaximumSlidingForce (for when the character has support but no traction), and MaximumAirForce (when airborne).

Awesome!

I now have one final issue (perhaps the bane of all physics networking):
Right now, my position correction basically takes (currentPosition - predictedPosition) and adds that on to the server's authoritative position, since rewinding/replaying isn't an option with BEPU. Unfortunately, the inaccuracy of that method means that sometimes the player is moved into the terrain. This results in everything blowing up; the player starts getting pushed out not only on the Y axis, but on the X and Z axes as well, eventually collapsing into the player falling through the terrain. Is there any way to make the player only get pushed up, and not on the X-Z plane?

EDIT: Never mind, this is most likely my fault. I was simulating prediction failures by randomly adding jitter to the X and Z position every frame.

[Norbo]

Setting it to 10 fixed the "laggy" response problem. Out of curiosity, why 10? Isn't the normal human being 70kg?

The engine has no defined unit types, so the choices are somewhat arbitrary. Typically, in the demos, I just set a 'light object' to be around 1 unit in mass. Relatively 'heavy' objects tend to range from 5 to 20 units. To allow the character to push light objects easily and have some trouble with heavy objects, I put it at 10.

There is some benefit to picking such simple numbers, though. Most importantly, it's immediately obvious how heavy an object is relative to the light objects. This must be kept in mind when designing simulations to avoid mass ratio problems. If a heavy object depends on a light object, the solver will have trouble. In this context, 'heavy' just means 'heavier than the light object by an excessive factor'. For a heavy object to depend on a light object means the stress of the heavy object somehow passes through the light object. Some examples of bad mass ratios include a tank rolling over a tiny light crate, or a wrecking ball held by little low-mass string composed of individual light entities.

Much less importantly, there is also a SolverSettings.DefaultMinimumImpulse tuning factor. Very heavy objects will tend to undergo more solving iterations because of this threshold, while light objects will tend to early out faster. This rarely has a noticeable impact, but it can show up in extreme cases.

[_untitled_]

Here's a video of the "jumping" issue: (go to 0:38)
https://www.youtube.com/watch?v=WEx4Jp5bZV4

[Norbo]

I assume by the "jumping" issue you're referring to the anomalous bounces noted as a bug in the video (the actual jumps seemed to work as expected). I don't have enough information to speculate precisely; that's not caused by any known issue with the character or physics.

Perhaps the character is getting teleported into the ground and shoved out by position correction- though the character seems to accumulate more speed than it should in that case, and the character's vertical motion constraint should be able to keep it grounded regardless. It seems to lose traction at that point, preventing the vertical motion constraint from keeping the character attached. Or, maybe the vertical motion constraint is simply overpowered.

[_untitled_]

I assume by the "jumping" issue you're referring to the anomalous bounces noted as a bug in the video (the actual jumps seemed to work as expected). I don't have enough information to speculate precisely; that's not caused by any known issue with the character or physics.

Perhaps the character is getting teleported into the ground and shoved out by position correction- though the character seems to accumulate more speed than it should in that case, and the character's vertical motion constraint should be able to keep it grounded regardless. It seems to lose traction at that point, preventing the vertical motion constraint from keeping the character attached. Or, maybe the vertical motion constraint is simply overpowered.

I've noticed that the "flinging" issue mostly happens when the player jumps into a side of a block. Maybe the stepping up combined with the jump somehow flings the player?

(the actual jumps seemed to work as expected)

Any way to make the jumps go faster?

[Norbo]

I've noticed that the "flinging" issue mostly happens when the player jumps into a side of a block. Maybe the stepping up combined with the jump somehow flings the player?

A character cannot step while jumping, and stepping is an instantaneous teleportation that doesn't involve any velocity changes. Stepping is probably not the cause.

If jumping is always involved, that would explain why the vertical motion constraint doesn't help; it is only used when the character has traction, and jumping disables both support and traction until it finds a support again.

If there are any potentially interfering systems that introduce extra teleportations or impulses, try turning them off to see if the problem goes away. If it persists, try to replicate it in the BEPUphysicsDemos in isolation.

Any way to make the jumps go faster?

Increase gravity. If you want the character to fall faster but you don't want other stuff to fall faster, just apply your own acceleration to the character body directly (e.g. characterController.Body.LinearVelocity += new Vector3(0, extraAcceleration * dt, 0)).

[_untitled_]

Wouldn't increasing gravity also make the player jump to a lower peak? I want to the player to be able to jump to the same height, but get there (and fall) at a faster rate.

[Norbo]

Increase the JumpSpeed as well. CharacterController.JumpSpeed is how fast the character launches off the ground initially.

[_untitled_]

I am now able to reproduce the jumping issue. Holding "W" while jumping into a wall will cause the player to slide up and jump:
https://dl.dropbox.com/u/59540455/jump_bug.mp4

Similar behavior happens if you press "E" while jumping into one of the steps in the playground demo.