Bepu v2 Character Controllers

Discuss any questions about BEPUphysics or problems encountered.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Bepu v2 Character Controllers

Post by Norbo »

AllocateCharacter returns a reference to a struct. Without the ref keyword, it just grabs a copy. Changing this line:

Code: Select all

CharacterController character = characters.AllocateCharacter(characterCollider.Handle, out int characterID);
to

Code: Select all

ref CharacterController character = ref characters.AllocateCharacter(characterCollider.Handle, out int characterID);
fixes it.

Pretty easy to miss (as I did earlier in this thread!). Might make that return a pointer just to force awareness.
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

Yep that fixed it! Thank you!

I noticed I'm sliding a lot so I'll have to play with the configuration, but I also noticed that the visual representation of the character seems to be partially in the ground. Is the character's origin at his feet or at his waist?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Bepu v2 Character Controllers

Post by Norbo »

All convex shapes are centered on their center of mass, so a capsule character's body position is near the character's waist.
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

Norbo wrote: Sun May 26, 2019 10:32 pm a capsule character's body position is near the character's waist.
That's how it was when I was just applying velocity, before I added the built-in character controller stuff. Now the capsule is either sinking into the floor or BodyReference.Pose.Position is returning a Vector3 that doesn't represent the character's waist.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Bepu v2 Character Controllers

Post by Norbo »

If it's sinking into the surface by a very small amount, like 0.0003 units in response to -10 gravity, that's normal. Collisions are not perfectly rigid; the PairMaterialProperties output by the narrow phase callbacks control the rigidity.

If you're seeing much larger intersection, then I would suspect some form of visualization bug. In both the main demos and in the repro provided it is working as expected.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Bepu v2 Character Controllers

Post by Norbo »

Just a guess: note that the 'length' provided to the Capsule constructor refers to the capsule's internal line segment length. The radius is added on top of that. So a length of 1 and a radius of 0.4 would mean a distance of 0.9 from capsule center to capsule bottom.
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

Norbo wrote: Sun May 26, 2019 10:50 pm If you're seeing much larger intersection, then I would suspect some form of visualization bug. In both the main demos and in the repro provided it is working as expected.
The intersection is quite a bit larger, more like 0.25-0.4 units with -9.8 gravity. It doesn't seem to be a visualization bug, because when I first spawn in the character he falls a few units, lands on the cube below and stands there with his "feet" on top of the cube. It's only once I press a key for the first time and assign a value to the targetVelocity that he sinks into the block. He doesn't fall through, he just moves down as though the support he was standing on had shifted downwards.

I fixed the repro project with the ref keyword and tried it out there, but I noticed that as soon as I pressed a key (even only for a moment) the character's position started changing extremely rapidly (it hit x=15000 y=-200000 within ~10 seconds), so there's definitely still something wrong there. Maybe it's just the character's properties?
Norbo wrote: Sun May 26, 2019 10:55 pm Just a guess: note that the 'length' provided to the Capsule constructor refers to the capsule's internal line segment length. The radius is added on top of that. So a length of 1 and a radius of 0.4 would mean a distance of 0.9 from capsule center to capsule bottom.
I accounted for this.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Bepu v2 Character Controllers

Post by Norbo »

It's only once I press a key for the first time and assign a value to the targetVelocity that he sinks into the block.
In the repro, after it starts moving, the character falls over. If you want the character to never rotate, set the characterInertia.InverseInertiaTensor = default. You could also control the rotation in other ways (velocity setting, angular constraint, etc.).
as I pressed a key (even only for a moment) the character's position started changing extremely rapidly (it hit x=15000 y=-200000 within ~10 seconds), so there's definitely still something wrong there. Maybe it's just the character's properties?
The physics thread is running as fast as it can in a tight loop with no delays. It'll simulate much faster than real time.
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

Norbo wrote: Sun May 26, 2019 11:21 pm In the repro, after it starts moving, the character falls over. If you want the character to never rotate, set the characterInertia.InverseInertiaTensor = default. You could also control the rotation in other ways (velocity setting, angular constraint, etc.).
I totally overlooked that. That's what was causing the issue in my actual project as well since I'm only sending the character's position, not the rotation, to the clients. So when the character falls over, the visual representation simply shifts down while remaining upright.
Norbo wrote: Sun May 26, 2019 11:21 pm The physics thread is running as fast as it can in a tight loop with no delays. It'll simulate much faster than real time.
Oh, true :)

I have a lot of fiddling to do with all the values, but it looks like everything is working as intended for now.
Thanks again for all the help!
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

So I've been playing around with the various values and properties and I've noticed two things.

First, the character "drifts" after letting go of a key. While this is physically accurate behavior, it's a little hard to control and not how characters usually behave in games. It seems that no matter how I change the MaximumHorizontalForce property or how big or small I make the TargetVelocity modifier, there's always a very noticeable amount of drift.

Second, my capsule no longer slides up steps. Previously, when my character was controlled by direct velocity changes, it just slid up stairs, but now that I'm using the constraints-based approach this no longer happens (step height hasn't changed).

Maybe I just need to do some more fiddling, but do you have any pointers on resolving this stuff?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Bepu v2 Character Controllers

Post by Norbo »

First, the character "drifts" after letting go of a key. While this is physically accurate behavior, it's a little hard to control and not how characters usually behave in games. It seems that no matter how I change the MaximumHorizontalForce property or how big or small I make the TargetVelocity modifier, there's always a very noticeable amount of drift.
With a sufficiently high horizontal force, any 'drift' should be extremely small and related to numerical integration rather than a lack of stopping power. In the demos, increasing the horizontal force can make the character accelerate and decelerate instantly. If you see lengthy acceleration/deceleration times even with practically unbounded forces, there's likely something else going on. I'd probably need a repro again to identify it quickly.
Second, my capsule no longer slides up steps. Previously, when my character was controlled by direct velocity changes, it just slid up stairs, but now that I'm using the constraints-based approach this no longer happens (step height hasn't changed).
The character will only attempt to use surfaces as supports if the contact normal is not too steep. This is controlled by the CosMaximumSlope property. At 0, the character can only stand on perfectly flat surfaces (with respect to the character). With values near 1, it can climb up near-vertical walls. (Using a value of 1 would result in a singularity, so it's not allowed.) In terms of angle, 0 CosMaximumSlope corresponds to 0 radians, and 1 CosMaximumSlope corresponds to 0.5 radians (90 degrees).

The character cannot climb over any vertical obstacle taller than its radius, since such contacts would always have a normal slope beyond the supported range.
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

Norbo wrote: Mon May 27, 2019 9:08 pm a sufficiently high horizontal force
What kind of range are you talking about here? A value of ~50? 250? 1000?
Norbo wrote: Mon May 27, 2019 9:08 pm The character will only attempt to use surfaces as supports if the contact normal is not too steep.
Contact normals are not identical to the surface normal right? So the surface normal could be vertical but in the case of a stair the contact normal would be on an angle? I'm fairly certain the mental visual I have is correct, but it's hard to explain what exactly I'm picturing.
Norbo wrote: Mon May 27, 2019 9:08 pm The character cannot climb over any vertical obstacle taller than its radius, since such contacts would always have a normal slope beyond the supported range.
Based on the fact my velocity-controlled capsule was able to climb the steps this shouldn't be an issue, right?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Bepu v2 Character Controllers

Post by Norbo »

What kind of range are you talking about here? A value of ~50? 250? 1000?
For a character with a mass of 1, a force of 20 goes from a velocity of 4 to ~0 (1e-10) in 12 frames of 1/60f each. At a force of 240, it takes a single timestep to go from 4 to ~0.
Contact normals are not identical to the surface normal right? So the surface normal could be vertical but in the case of a stair the contact normal would be on an angle? I'm fairly certain the mental visual I have is correct, but it's hard to explain what exactly I'm picturing.
The contact normal will be a surface normal, but it may not be the normal of any face of a polygon. It could be on an edge or vertex of one shape. In the following, the normal is created by a vertex and the rounded capsule shape.
capsulestep.png
capsulestep.png (2.22 KiB) Viewed 79979 times
Based on the fact my velocity-controlled capsule was able to climb the steps this shouldn't be an issue, right?
Probably, unless the velocity was sufficient to shove it deeply into the step/wall. At that point, depenetration could shove it upwards instead of sideways, whichever direction is shallowest.

(Notably, using PositionLastTimestepper would avoid most external-velocity-caused penetration. Or using PositionFirstTimestepper with velocity modifications attached to a post-pose integration stage.)
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

Norbo wrote: Tue May 28, 2019 12:45 am For a character with a mass of 1, a force of 20 goes from a velocity of 4 to ~0 (1e-10) in 12 frames of 1/60f each. At a force of 240, it takes a single timestep to go from 4 to ~0.
Got it.
Norbo wrote: Tue May 28, 2019 12:45 am In the following, the normal is created by a vertex and the rounded capsule shape.
That's what I was envisioning.
Norbo wrote: Tue May 28, 2019 12:45 am Probably, unless the velocity was sufficient to shove it deeply into the step/wall. At that point, depenetration could shove it upwards instead of sideways, whichever direction is shallowest.
Hmm ok. I'll have to take another look at the step height compared to the capsule radius.
tomweiland
Posts: 99
Joined: Wed May 08, 2019 12:17 am

Re: Bepu v2 Character Controllers

Post by tomweiland »

So everything seems to be working properly now (still need to deal with stairs), but I noticed that there's no air control. Is there a built-in way to implement this?

Additionally, when the character stands on a moving object—such as a ship—and jumps, he doesn't have the same velocity as the moving object, meaning jumping is quite unpredictable in terms of where you'll land (sometimes not even on the same object). When a character stands, I'm assuming friction makes him move with whatever he's on top of. What would be the best way to go about giving him the same velocity as the object beneath him when he jumps?

Finally, I noticed that unlike v1, v2 has no ApplyAngularImpulse method. Is there a different built-in method that I'm not aware of? If not, what's the alternative? Should I just apply a force with an offset? That might get messy...
(I know this has nothing to do with character controllers, but I didn't think it was worth creating a separate topic for)
Post Reply