Character Controller + 6DOF

[OdinLongBeard]

Hi, I'm a little stuck on what needs to be done to convert the CharacterController class to support 6DOF movement for a new project I've started.
I've been using BEPU (great physics engine btw!) for a while now, but this one problem has eluded me for days.

Any pointers or code examples would be a great help a lot!

[Norbo]

An explanation can be found on this post: viewtopic.php?f=4&t=1659&p=11486#p11486

I always planned to make it easy to change the down direction, and this is a fairly common issue. I think I'll just make the needed modifications, should be up sometime today.

[OdinLongBeard]

Wow, thanks for the quick response Norbo!

That post explained everything I needed to know in a really simple way. Much to the point that I feel a little stupid for not figuring that out sooner.

Thanks a lot for the help!

EDIT:

I think I'll just make the needed modifications, should be up sometime today.

That would definitely help anyone else out there who happens to get stuck on getting a 6DOF character controller working.

[Norbo]

The CharacterController should now support 6DOF motion: http://bepuphysics.codeplex.com/SourceC ... changesets

The control scheme is a little different now. The HorizontalMotionConstraint.MovementDirection is interpreted according to the view direction, which is set on the Character.ViewDirection. So, a move direction of (0,1) corresponds to 'walk where the camera is looking'. This works in 6 degrees of freedom.

To reorient the character, set the Character.Down property (as opposed to directly changing the character's orientation, which should be left untouched). The PlanetDemo now uses it, though it's hard to tell since the camera's up vector is locked.

Watch out though: setting the Character.Down property is a form of teleportation. It changes the orientation discontinuously. Any collisions with the character will get smooshed out. This should usually be ok, but there may be some cases where controlling the orientation with an angular motor would be more robust.

I haven't yet adapted this for the SphereCharacterController. The changes required are a subset of those required for the cylindrical version. I'll get to them tomorrow.

[OdinLongBeard]

The changes seem to work fine in the planet demo, but sometimes (randomly) I get a NotFiniteNumberException when the demo sets the down vector of the character controller.

Heres the stack trace:

Code: Select all

  
 at BEPUutilities.MathChecker.Validate(Quaternion q) in D:\c# projects\SDKs\bepuphysics_4100150a55e2\BEPUutilities\MathChecker.cs:line 128
   at BEPUphysics.Entities.Entity.set_Orientation(Quaternion value) in D:\c# projects\SDKs\bepuphysics_4100150a55e2\BEPUphysics\Entities\EntityBase.cs:line 84
   at BEPUphysicsDemos.AlternateMovement.Character.CharacterController.set_Down(Vector3 value) in D:\c# projects\SDKs\bepuphysics_4100150a55e2\BEPUphysicsDemos\BEPUphysicsDemos\Alternate Movement\Character\CharacterController.cs:line 74
   at BEPUphysicsDemos.Demos.PlanetDemo.Update(Single dt) in D:\c# projects\SDKs\bepuphysics_4100150a55e2\BEPUphysicsDemos\BEPUphysicsDemos\Demos\PlanetDemo.cs:line 68
   at BEPUphysicsDemos.DemosGame.Update(GameTime gameTime) in D:\c# projects\SDKs\bepuphysics_4100150a55e2\BEPUphysicsDemos\BEPUphysicsDemos\DemosGame.cs:line 388
   at Microsoft.Xna.Framework.Game.Tick()
   at Microsoft.Xna.Framework.Game.HostIdle(Object sender, EventArgs e)
   at Microsoft.Xna.Framework.GameHost.OnIdle()
   at Microsoft.Xna.Framework.WindowsGameHost.RunOneFrame()
   at Microsoft.Xna.Framework.WindowsGameHost.ApplicationIdle(Object sender, EventArgs e)
   at System.Windows.Forms.Application.ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FDoIdle(Int32 grfidlef)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)
   at Microsoft.Xna.Framework.WindowsGameHost.Run()
   at Microsoft.Xna.Framework.Game.RunGame(Boolean useBlockingRun)
   at Microsoft.Xna.Framework.Game.Run()
   at BEPUphysicsDemos.Program.Main(String[] args) in D:\c# projects\SDKs\bepuphysics_4100150a55e2\BEPUphysicsDemos\BEPUphysicsDemos\Program.cs:line 13

The PlanetDemo now uses it, though it's hard to tell since the camera's up vector is locked.

Except that the character no longer slides off the planet when you reach the "sides".

[Norbo]

Alrighty, new version.
1) That crash should be fixed.
2) I forgot a couple of areas where the movement direction needed to be updated. Stepping and much of support finding was pretty broken- it should work now.
3) SphereCharacterController has been updated to match.

[OdinLongBeard]

Alrighty, new version.
1) That crash should be fixed.
2) I forgot a couple of areas where the movement direction needed to be updated. Stepping and much of support finding was pretty broken- it should work now.
3) SphereCharacterController has been updated to match.

Everything appears to work fine now. I haven't ran into that crash in the new version.

[OdinLongBeard]

This might sound dumb but, I can't figure for the life of me how to get the camera to "align" with the character in the planet demo.

I was trying to get it so the yaw and pitch is relative to the orientation of the camera/character, but I've failed so far.

Its probably something simple I'm overlooking but, I'm having math overload at the moment. Any pointers would be greatly appreciated.

[Norbo]

The demos camera is just a maximum-simplicity hardcoded up vector camera. To get it to work as expected with arbitrary character up vectors, you'll need a 6DOF camera.

For a true 6DOF camera that reconstructs the world matrix from Yaw and Pitch each frame like the current camera does, you'd need to maintain a basis. In the current camera, that basis is implicitly Matrix.Identity. As soon as the up vector changes, though, the orientation represented by the matrix will be need to be changed to match. There's some trickiness here since an up vector alone does not fully specify an orientation. You'll have to decide how you want to manage the transition.

You could also abandon the 'from Yaw and Pitch each frame' construction. Instead, just maintain the orientation directly. For example, if you want to yaw the camera by 10 degrees, just yaw whatever the current transform is by 10 degrees around the current upvector. This is easy enough when you have a free-floating camera with no constraints, though it does get a little more complicated when you want to introduce the idea of pitch limits again. For pitch limits, you could do something like measuring the current pitch, checking the desired pitch, clamping the pitch change within the allowed limits, and then applying the restricted rotation.

[OdinLongBeard]

Ok, I've given it another shot over the last 2 days and I still can't figure out how to get the camera to align to the character properly.

At first i tried using the transform of the character controller then add the camera's yaw and pitch to it later, which sort of works, until I go near an up vector of 0,0,1 or 0,0,-1 then the camera starts to spaz out and flip around like crazy.

I then tried to roll my own camera math, using a negated version of the char controllers Down vector, as the camera's up vector. Using this method I at least managed to get the camera to align properly when strafing, but had no way to align "forward", so it was always pointing at Vector3.forward, rather than a forward aligned to the sphere surface. I have no idea how to calculate the forward vector from just an Up vector.

I then tried crossing the Up vector with Vector3.forward to get the Right vector, then crossing that with the camera's up vector to get some kind of forward vector that (i hoped) would make it align. I ended up with the same spazzing effect whenever I went near 0,0,1 or 0,0,-1 again, which after hours of testing I realized (dumb mistake) was due to the Up vector being crossed with Vector3.Forward and resulting in an un-normalized up vector.

EDIT:
Here is what I have currently for calculating the camera's world and view matrices (note: I took out the code for applying the relative Yaw/Pitch values for now, while i get the alignment stuff to work):

Code: Select all

Vector3 right = Vector3.Normalize(Vector3.Cross(Vector3.Forward, upVector)); //<---- Problem here when upVector is close to being equal to Vector3.Forward or Backward.
            Vector3 forward = Vector3.Cross(-right, upVector);
            Matrix upRot = Matrix.Invert(Matrix.CreateLookAt(Vector3.Zero, forward, upVector));


            WorldMatrix = upRot * Matrix.CreateTranslation(Position);
            Vector3 camLookat = Position + forward;
            View = Matrix.CreateLookAt(Position, camLookat, upRot.Up);

This sort of thing is currently way beyond my knowledge (at the moment) and any further help would be greatly appreciated, even though you've already helped me a lot already.

[Norbo]

I went ahead and modified the camera and some other bits to support arbitrary up vectors, but it appears codeplex doesn't want to hear about my pushes. It'll be uploaded as soon as codeplex stops having a tantrum.

[OdinLongBeard]

I went ahead and modified the camera and some other bits to support arbitrary up vectors, but it appears codeplex doesn't want to hear about my pushes. It'll be uploaded as soon as codeplex stops having a tantrum.

Ah, thats great!

I'll hold off on throwing my brain at the code I have at the moment then. Thanks yet again Norbo.

[Norbo]

Looks like it's working again!

[OdinLongBeard]

Looks like it's working again!

It all works perfectly now. Originally I was doubting whether or not I chose the right physics engine for the task. But once you started adding 6DoF support to the demos, all doubt was cleared. I'll get a video up of what it is I've started on sometime later today.

As a thank you for all your help, and for BEPU, I threw $5 at your Donate button on Codeplex and my screen magically absorbed it. Who knows, it might turn into a beer when it reaches you.

EDIT:
As promised, a video of what I'm doing with your 6DoF upgrades:



It stutters a bit when loading chunks in the video, but apparently it was because I had Fraps locked to 30 FPS (Doh!), which itself forced the game down to 30 fps instead of the usual 400 FPS+.

[Norbo]

Nice job!

As a thank you for all your help, and for BEPU, I threw $5 at your Donate button on Codeplex and my screen magically absorbed it. Who knows, it might turn into a beer when it reaches you.

Thanks