Version Roadmap

[Norbo]

A video may help. Was it in the very latest development version? It may depend quite a bit on the geometry it's hitting. There's also a known problem with contact refreshing which may be responsible for a part of what you're seeing. I'm tracking it down now.

[Spankenstein]

Was it in the very latest development version?

It was from the last update (4fe8ef781ea5) found at:

http://bepuphysics.codeplex.com/SourceC ... evelopment

I'm using the Character with the CharacterPlaygroundDemo class with the BEPUphysicsDemos project. ('Ctrl' + 'Shift' + '5')

[Norbo]

I fixed the bug I mentioned. While walking around the playground now (in the newest development version), I don't notice any unexpected significant slowing on walls or getting stuck.

Note that the speed of the character will slow down if it is trying to walk into a wall (partially or fully). It doesn't try to redirect the motion tangential to the wall to stay at max speed. Instead, it just removes the penetrating component of the velocity. The remaining tangential velocity is left untouched since the character has zero friction with the environment and no linear damping.

There are three remaining behavior issues, though. They aren't bugs, just earlier design choices which can occasionally cause hiccups with the character. Usually the hiccups are completely unnoticeable.

1) A contact with a normal opposing the character's motion can survive small offsets in the persistent manifold. This can occasionally make it difficult to walk on very tiny things that have a surface that can generate a normal against the character's motion. This is the most noticeable issue since it can halt your motion. Objects which are tall enough to warrant a step do not suffer this problem because the step-up process eliminates the old contact. This particular problem may be best solved by tuning a margin in the stepper.

2) Convex-mesh collisions use 4 contact points to avoid redundancies. When a convex-mesh collision:
-Has contacts with very different normals,
-Is colliding with many triangles,
-Has a small-area contact manifold,
the contact reducer may choose to rapidly change the involved contacts as they seem to all be about the same quality. This can cause a slight jitter while ramming yourself into a wall. It's usually very hard to see unless you have the contact display on. It's much less severe than #1.

3) With a similar base cause as #1, contacts in persistent manifolds can survive outside the involved shapes' geometry. This is most apparent when walking past the edge of a wall and there still exist contacts for ~.1 units too long. This can make going past obstacles occasionally less smooth than it could be. This is typically nearly impossible to notice in practice without having the contact display on.

My primary focus now is to find a good solution to problem #1. It may take the form of a fundamental change to persistent manifolds, or I may just retune something if it works well enough. I do have some ideas that could address the core behaviors in persistent manifolds, but their current versions are a little too expensive. I'll keep thinking

[Norbo]

There's also one other possible cause of oddities- the character playground mesh is full of very poor geometry Some of it is chock-full of degenerate triangles, and none of the important parts have proper connectivity information for smooth sliding. This was done partially on purpose (as in, it wasn't fixed when discovered ) because it offers a worst-case for some of the character behaviors. It helped find quite a few long-hidden bugs, too. The mesh will be cleaned up before v0.16.2 is released.

[Spankenstein]

Hi Ross,

I've had a chance to test the latest character controller 'c0f5c9749923' and I've noticed a few things:

- When jumping and crouching the camera behavior is odd and will not interpolate smoothly between stances in mid air
- In the character playground demo the character movement will jitter when pressed side on into the following obstacle:

[Spankenstein]

If I place a model in front of a camera using the following method:

Code: Select all

        public Matrix WeaponWorldMatrix(float xOffset, float yOffset, float zOffset)
        {
            Vector3 weaponPos = position;

            weaponPos += Right * xOffset;          
            weaponPos += Up * yOffset;
            weaponPos += Forward * zOffset;
            
            Matrix m = Matrix.CreateFromYawPitchRoll(MathHelper.ToRadians(-yawAccum), MathHelper.ToRadians(-pitchAccum), 0f);
            m.Translation = weaponPos;

            return m;
        }

and then control the camera using the 'CharacterControllerInput' class then the model jitters and doesn't move smoothly as I move the camera from side to side.

This video demonstrates what I am seeing: http://www.youtube.com/watch?v=xRNbCX1fRQ8

First I move to the right, then to the left.

[Norbo]

- When jumping and crouching the camera behavior is odd and will not interpolate smoothly between stances in mid air

I don't see anything unexpected. Does what you see happen every time? Note that the character's eyes lower relative to the body when it crouches and rise when it stands, so crouching/standing repeatedly while airborne will move your camera a bit.

- In the character playground demo the character movement will jitter when pressed side on into the following obstacle:

That mesh has missing geometry, and the non-missing part has topology not well suited to sliding. I put it there primarily to test the worst possible cases for stepping. The 'bumps' you feel while sliding on the edge is just normal contact generation behavior trying to cope with the (lack of) geometry, not a problem with any particular part of the character itself. Similar behavior should be visible in other situations to a lesser degree. I don't intend to fully address this in v0.16.2 since doing so requires an overhaul of persistent manifolds which still, in general, work quite well.

If I place a model in front of a camera using the following method:

It sounds like it's just using the wrong position.

-This could happen if the character's actual camera interpolates at all while the character.Body.Position is used to position the gun.

-It could also happen if internal time stepping is on (a value is being passed into Space.Update) and uninterpolated entity positions are used. Since updates occur based on elapsed time in internal time stepping, and no fractional updates can occur, you can end up with a 'remainder' of elapsed time after each frame which introduces a jittery appearance to movement. Interpolation buffers, not to be confused with the character's camera interpolation, take that remainder of elapsed time and compute an intermediate position for smooth movement. Check out the asynchronous update demo (http://bepuphysics.codeplex.com/wikipag ... umentation) for an example.

If the character's camera is implemented like in the demos, then aligning the weapon to it should eliminate any relative offsets. Of course, if internal time stepping is interfering, then both your camera and weapon will be in the wrong locations relative to the physical body. Your weapon won't move in screen space, though.

Another trick is to just draw the weapon in a first person perspective separately. That way you don't have to worry about its positioning in the real world. This is extremely common in FPS games.

Thanks for testing it out!

[Spankenstein]

Does what you see happen every time? Note that the character's eyes lower relative to the body when it crouches and rise when it stands, so crouching/standing repeatedly while airborne will move your camera a bit.

It does happen every time but it has more of a profound effect depend on which part of the jump trajectory the character is in. Should the crouching camera movement be ignored until the object has landed?

It sounds like it's just using the wrong position.

If I draw a wire box to denote the body position then that also jitters:

Code: Select all

game.WireShapeDrawer.DrawWireBox(input.CharacterController.Body.CollisionInformation.BoundingBox, Color.Green);

Your source code uses the same information to draw the box:

Code: Select all

e.CollisionInformation.BoundingBox.GetCorners();

but I guess there must be something different?

It could also happen if internal time stepping is on (a value is being passed into Space.Update)

It doesn't matter if I use internal time stepping or not:

Code: Select all

            //space.Update((float)gameTime.ElapsedGameTime.TotalSeconds);
            space.Update();

the weapon still jitters.

Another trick is to just draw the weapon in a first person perspective separately.

The weapon is drawn separately and last of all with the depth buffer turned off. Lighting calculations work with it this way and walls don't cull it.

[Norbo]

Should the crouching camera movement be ignored until the object has landed?

That's up to individual developers, I suppose- I actually like the effect. Camera interpolation is completely external to the character itself, so it's easy enough to tweak it to behave differently.

The weapon is drawn separately and last of all with the depth buffer turned off. Lighting calculations work with it this way and walls don't cull it.

Without regard to the rest of the jittering issue, if it's being drawn separately, then you can use a completely separate set of first person transforms/projections too. There should be no jitter at all if the weapon is set up properly in the 'first person' space.

I guess there must be something different?

Indeed, though I'm not sure what at the moment.

[Spankenstein]

then you can use a completely separate set of first person transforms/projections too

Absolutely. I thought it could be a bug or something that might be worth addressing, especially if I'm using the same data to draw the AABB?

That's up to individual developers, I suppose- I actually like the effect.

I'll add an option to prevent crouching in mid by modifying your source.

Thinking of options, have you got any plans to add a Box shape for the Character classes as an alternative to the current Cylinder shape? I find that the Cylinder behaves strangely with walls at 270 degrees to each other because of the circular nature of the collision area.

[Norbo]

Thinking of options, have you got any plans to add a Box shape for the Character classes as an alternative to the current Cylinder shape? I find that the Cylinder behaves strangely with walls at 270 degrees to each other because of the circular nature of the collision area.

What kind of behavior are you seeing?

I don't have any plans for a box-based character since that throws out certain useful assumptions built into the circular nature of the character. It could be modified to support it without extreme difficulty, but I can't include any more major changes/additions to the character in v0.16.2; other things are higher priority at the moment.

I thought it could be a bug or something that might be worth addressing, especially if I'm using the same data to draw the AABB?

While possible, it doesn't happen in the demo, and I don't really know what would be causing it from the engine side of things other than what I've already mentioned. Nothing inherent to the character itself should be able to cause it. More information would be needed to diagnose it properly.

[Spankenstein]

What kind of behavior are you seeing?

Speeding up of sliding collision response due to the curve. I can post a video tomorrow, if you are interested?

More information would be needed to diagnose it properly.

I'll post a link to some small code project showing the exact behavior (tomorrow).

Thanks for your help

[Norbo]

Speeding up of sliding collision response due to the curve. I can post a video tomorrow, if you are interested?

Assuming what you are referring to is the expected physical response, then I won't need a video. If this is the case, then you don't need to worry about the character speeding up beyond its maximum speed- the horizontal motion constraint has a maximum speed and will decelerate to match it if exceeded. The 'speedup' is just the character trying to get around as fast as possible while still staying within its limits. The circular nature actually helps smoothness and consistency:

boxvscylinder.jpg (16.37 KiB) Viewed 156319 times

Changing the orientation of the box based on the movement direction to make it consistent has problems of its own because a box is not rotationally invariant.

[chronicacid]

This new character system is so exciting!

Can you add the following:
1. Cliff Hanging
2. Double Jump
3. Jump with butt pound (like Mario)

Awesome work.

[Norbo]

Can you add the following:
1. Cliff Hanging
2. Double Jump
3. Jump with butt pound (like Mario)

I won't, but you can I'd like to keep the core character from getting too full of behaviors.

Double jump and mario-smash would be pretty simple to add without delving down into complicated logic. Right now, jumping is prevented if a couple of conditions are met. Modify the conditions with a jump count or something, and there's double jumping. Press a different button while airborne to apply a velocity towards the ground and you've got mario-smash.

Cliff hanging is a bit more difficult, but still very doable. The character's QueryManager exposes methods for ray casting against its immediate environment and performing contact queries. Of course, there's also the approach of just making the body a compound shape and putting a slightly larger capsule at the top of the character which would latch onto stuff. Analyzing the contacts of that sub body would then inform the character's movement.

Awesome work.

Thanks!