Custom Player controller

[Mumbles]

Hello all.

I'm looking towards building a player controller. I know, there is one already in the joint library, but it has a few features missing that I really want in my controller. Basically, it's about not letting the controller climb up steps or ramps with absolutely no speed loss.

I'm looking toward the idea of a customisable speed penalty for the following sort of situations

Ramp: Shallow gradient .. moderate gradient .. steep gradient .. absolutely unclimbable.
Steps: Low height .. moderate height .. large height .. absolutely unclimbable.

With examples being.
Ramp shallow penalty: 10 degrees, 0% min slowdown, 15% max
Ramp moderate penalty: 45 degrees, 15% min, 60% max
Ramp steep penalty: 65 degrees, 60% min, 100% max

Small step penalty: 10 cm, 0% min slowdown, 15% max
normal step penalty: 30 cm, 15% min, 66% max
tall step penalty: 60 cm, 66% min, 100% max

The idea also would be that the penalty would be reversed if the controller was going down a slope rather than up. The penalty would apply to steps whether going up or down, because which normal person would sprint down a flight of steep steps at full speed?


But this is all just planning, because currently the controller isn't moving around the way I would like it to. The player controller is currently a cylinder with an upvector joint attached to it. I was warned that the upvector would cause the body to spin... And that's exactly what's happening. But this only happens whilst the body is on the floor - in space it moves around correctly. So my first real question is, why does it spin, even when no torque is applied during the callback? My other question is, that I'm looking at using a 6dof joint from the joint library but I can't find any official documentation for the joint library, so I'm a little nervous about using it because I don't know if I would be giving the wrong parameters.

Does the joint library player controller use just raycasts, or does it use upvectors/6dof joints? It might help me get an idea on where to start with it.

Thanks...

[Edit] Currently, the world and controller have separate materials applied, and the elasticity between them is 0. Everything else about the materials is default values.

[Mumbles]

Yesterday I was completely stuck, not knowing what was wrong, but as soon as I posted, I had an idea.

It took me a while to figure out the 6DOF custom joint, but I eventually got it, and now I wonder why I found it so hard to understand, turned out to be really easy. It had the same spinning problem though, so I didn't completely solve it.

Eventually, I tracked found that the spinning behaviour was because of the friction between the two materials, kinetic friction in particular. I turned the friction down to 0.05f which made that spinning go away. But that caused another obvious problem. When I stop pressing 'W' to body continues to slide for a long time. I can't decide what would be best to do about that. Would I:
1-> Increase the linear damping for the controller body?
2-> Decrease the amount of force given to move the body?
3-> A different idea that I've not thought of?

The problem is that each idea has it's own problem:
1-> The damping must be the same for all axes. This means that with a higher damping, the controller starts to fall like it has a parachute (I have the gravity at -9.81665 I forget where I got that number from). I tried scaling the gravity and body damping up by 10 (so linear damping is now 1.0 and gravity is now -98.1665). But then gravity seemed far too strong. I turned the gravity back to -9.81~ and it was too weak, and could need seem to find an acceptable gravity force for 1.0 damping.
2-> I found applying a force of 4 for movement to be too slow, and 5 to be slightly too fast. But they both take far too long to stop.
3-> I'm not very clever, so I can't think of any other ideas.

Has anyone else had this issue, because I know most people use the player controller provided in the joint library

[Julio Jerez]

the player controller is a his own joints.
the closest basci joint ot teh player controller is the up vector.

the controller does not uses raycast exactly, insteead use conve cast to predict futore position,
the trick for makng physcs bodies that act as if they are kenematoc bodies is to use teh secund less populat callback of a joint

basically teh joint has a call back called
virtual void SubmitConstraints (dFloat timestep, int threadIndex);
this is called by the solver to calculate all the foces action on the body.

Starting with newton 2.0 there is a secund call back teh is call after teh solve calculate of the forces on teh bodies and calculate teh net velocity.
// register the callback called afte all velocities are calculated
NewtonUserJointSetFeedbackCollectorCallback (m_joint, KinematicMotion);

this call back allow the application to make modification to the final velocity of teh body attack to teh joint.
Thsi function also let the application knows what forces the joint applied to the bodies that is atached to, in the same frame rather before integration the body position.
as oppose to old In 1.5 where thsi was only avalible in the next frame.

for example if a body is in free fall, when it hi the floor for the first time the solver will apply an impulse to change the velocity of the body.
but the application will read zero force in the frame.
with this callback the application can read what force was applied to the body to generate the impulse chnging velocity in the same frame.

It is in this function that the player controller do the ajustment to the enviroment whne the physics behavoir is not what is desired.
it does that by using convex cast (in teh case of teh SDK cntroller) or by using Ray cast, to adjeust the velocity and evne teh position of the body.

[Julio Jerez]

But this is all just planning, because currently the controller isn't moving around the way I would like it to. The player controller is currently a cylinder with an upvector joint attached to it. I was warned that the upvector would cause the body to spin... And that's exactly what's happening. But this only happens whilst the body is on the floor - in space it moves around correctly. So my first real question is, why does it spin, even when no torque is applied during the callback?

I too though tha tteh 6dof was eassy to use, but it tunr out I am alone on that, Glad you figure out how it works becaus eit can be very handy for many oteh uses.
for a player controller however I will still use the up vector and to correct the spinnig problem by pluging a
post update call back just like the code for the layer cntroller joint in the SDK.

here is the beggning of the code to spinnig on Player controller in the SDK, teh first thong it does is to correct the angular velocity after all force are applied.

Code: Select all

void CustomPlayerController::KinematicMotion (dFloat timestep, int threadIndex)
{
   dFloat turnOmega;
   dFloat turnAngle;
   dMatrix bodyMatrix;

   // handle angular velocity and heading
   NewtonBodyGetMatrix(m_body0, &bodyMatrix[0][0]);

   dVector upDir (bodyMatrix.RotateVector (m_localMatrix0.m_front));
   dVector frontDir (bodyMatrix.RotateVector (m_localMatrix0.m_up));

   dVector heading (0.0f, dCos (m_heading), dSin (m_heading), 0.0f);
   heading = m_localMatrix0.RotateVector(heading);
   turnAngle = (frontDir * heading) % upDir;
   turnAngle = dAsin (min (max (turnAngle, -1.0f), 1.0f));
   turnOmega = turnAngle / timestep;

   dVector omega (upDir.Scale (turnOmega));
   NewtonBodySetOmega(m_body0, &omega.m_x);
               ...



I case you are wondering if that defeat the porpose of the SummitConstraint callback, the answer is not it does not.
SummitConstraint callbakc is very important, because it is in that fuction that the engine figure out what forces tha body will
apply to other bodies. an also what force oteh bodies are applyin to that body.

for example say the body is on a moving body, submint constraint will detect that other bodies are applying reaction forces to just body.
therefore you body will receive some velocity just because of physic interation with other bodies.

making the correction of the body velocity in submint constraint can cause umpredicatble result,
because you will be chnagghn teh momebtum o fone body in teh midle of teh reaction force calculation.

doing the correction in the PostSubmint constratint after the solver calculate the velocity and update the velocity of all bodies in contact with you body
will prevent that you action modify teh reaction of oteh bodies.

a typical example is say the body collide with a wall.
the body will bounce back or penetrate teh wall for a litle.

changing velocity in submit contraint may cause the body to penetrate the wall of even an explosion.
but in post submit constraint you can use ray cast or convex cast to see if the body bounce of if it penetration the wall and you can teleport the body or caculate a velocity to place the body in teh desired position.
doing tah way will no aleter teh state of other bodies.

[Mumbles]

Sorry, I've not tried that out yet. I noticed a problem with the way I was adding forces. My method of converting local forces to global forces was not working properly. That has been solved now, but this means I'm only now looking at the callbacks you mentioned. Hopefully I should understand it, because it sounds like what I am looking for.