Basic Character Controller Questions & Issues

[cpugh]

Hi,

I am new to Newton and I'm evaluating it for use in my game engine. I like what I see so far in terms of accuracy / stability versus Bullet etc. plus I see the development and forums are very active, but I'm having a few troubles that I haven't been able to work out on my own so far and I was hoping that I could get some help here.

I am trying to construct a basic scenario where there is a falling box and a first person controller that allows you to navigate the environment, jump on, and push the box.

I started to write a kinematic character controller. Once I had the basics up and running I observed that the camera wasn't at the correct height. In the documentation it said that the capsule was along the X axis, so I use a rotation for the offset matrix along the z axis.

If I didn't apply the rotation, the camera was at exactly the capsule radius off the ground. If I rotated the collision any amount (even a random value) along the Z axis however I was getting the same incorrect height.

Code: Select all

//90 degrees rotation along the z axis, should make capsule upright
dQuaternion capsuleRot(dVector(0.0,0.0,1.0), 3.14 / 2.0);
dMatrix offsetMat = dMatrix(capsuleRot, dVector(0,0,0));
y = 5.0;
capsuleCollision = NewtonCreateCapsule(g_world, playerRadius, playerHeight, PLAYER_ID, offsetMat.data());


I was able to solve this problem and get the correct capsule rotation by applying the rotation directly to the body with

Code: Select all

NewtonCreateKinematicBody(g_world, capsuleCollision, &playerMatrix[0][0]);


It seems counterintuitive that I can't apply the rotation directly to the collision shape; in this instance I want to use a vertical capsule as the bounding volume for the character. Do I have a conceptual misunderstanding of what's going on here? Is this the best way to achieve what I want?

Additionally, I wanted to compare the feel of a kinematic character controller with one created using a dynamics object where the instantaneous velocity is set whenever the movement keys are pressed.

This required adding a constraint to the character to keep it upright, using the following:

Code: Select all

dVector upDirection (0.0f, 1.0f, 0.0f);
upVector = NewtonConstraintCreateUpVector (g_world , &upDirection.m_x, playerBody);


I was unable to find any further instructions indicating another step is required.

However, this seems to have no effect whatsoever. I even made the player object a box with no rotation applied just to be safe. When I start my demo the camera is at the correct height then my falling box hits the player and knocks them over flat on their back. Is the up vector constraint still supported? Or is there some other requirement I'm not meeting?

I would appreciate any answers to these questions, and I look forward to working with Newton.

-Chris

[Julio Jerez]

In newton after you do this:

Code: Select all

//90 degrees rotation along the z axis, should make capsule upright
dQuaternion capsuleRot(dVector(0.0,0.0,1.0), 3.14 / 2.0);
dMatrix offsetMat = dMatrix(capsuleRot, dVector(0,0,0));
y = 5.0;
capsuleCollision = NewtonCreateCapsule(g_world, playerRadius, playerHeight, PLAYER_ID, offsetMat.data());
body = NewtonCreateKinematicBody(g_world, capsuleCollision, &playerMatrix[0][0]);

The engine make a copy of the collision shape that you pass in, so you must destroy capsuleCollision
and get the actual body shape, like this:

Code: Select all

NewtonDestroyCollision(chassisCollision);
capsuleCollision = NewtonBodyGetCollsion (body)


then you can apply any rotation or scale you want to the collision shape.

however my recommendation is that unless you have prior experience whiting player controllers, is better that you use the player controller that comes with engine.
writing a players controller is kind a black art that has very little to do with actual rigid body dynamics and a lot more with programmers tricks, try to using the player controller manager that comes with the engine, it does exactly what you are looking for.

please Get 3.14 from Github and play the demos, look at BasicPlayerController.cpp
and AdvancePlayerController.cpp.

[cpugh]

Thanks for the response. I am running 3.14.

I saw the character controller demos. I can pull that code and work with that. I did not opt to go that route at first because it seemed like I would have to modify this code anyway (decouple it from demo framework, modify behaviors, eg, controlling direction while in air). I will look at using this as a base and follow back once I do.

However, both of my questions (applying vertical constraints to an object and understanding the collision volume rotation) are both general questions about the library that may apply to other places than the character controller only.

I'll start working on that but answers to these questions may still prove enlightening.

Thanks!
Chris

[Julio Jerez]

However, both of my questions (applying vertical constraints to an object and understanding the collision volume rotation) are both general questions about the library that may apply to other places than the character controller only.

Like I said you need to apply the transformation to the collision shape in the body not to the one you use to create the body. The body creation routine uses the collision that you pass in as the argument of a copy constructor to make a copy.

Also it is rare that people modified the collision shape of a body, the engine although it supports that kind of operation it is not designed to move object that way. When to do that the object representation on the broad phase is not notified, and you have to end up doing tricks like set wake up bodies so the broad phase get updated.
There are cases when this is fully supported like compound and scene collisions. by for simple shapes I do no recommend.

the engine expect you to modified the body transformation matrix.
that's the transform that joints, collision, impulses and forces act on.

finally you should use the constraints that are in the Custom joint library, the build in are legacy from 1.5 that are no use any more.

[Julio Jerez]

on this question:

Additionally, I wanted to compare the feel of a kinematic character controller with one created using a dynamics object where the instantaneous velocity is set whenever the movement keys are pressed.
This required adding a constraint to the character to keep it upright, using the following:

Actually in newton you do not have to do that. kinematic body has mass, so you can make your kinematic body push bodies but the body has not effect on him.
you can try this by playing the advanced player controller and either shoot bodies or go to the bridge and jump or walk on it.
The player interact with dynamics bodies as if he was dynamics but dynamics bodies to not interact with him. This is quite trick to get right using dynamics bodies and joints.,
this is why I suggest using the player controller in the joint library and learn from it.

Using a Joint to control a dynamics body as if it was kinematic is a huge mistake people has being making for almost 15 years.
First and foremost a player controller is expected to react instantaneously to velocity and rotation changes, this breaks the laws of conservation of momentum of rigid body physics because it requires huge forces or impulses to make it change velocity and that create lot of problem for the solver.
Second, most physics engines use integrative solvers to solve LCP systems, this mean when you apply the large impulse or forces to one body, they cannot propagate those changes fully down to all the bodies the player is in contact with in one frame. This leads to misbehaviors that are obvious to a person but that very few people can really explain.
Third even when you manage to tune the Joint, you get a system that is very unstable, a small change or one parameter cases large changes on the behaviors.
And finally you still get the problem that physics solvers do not never converge to an exact solution, they converge to a good enough approximation for the sleep system truncate the error. So what you get is a small jitter around the equilibrium point, your player is never a full rest.
In most cases for a gravity body the sleep code can deal with it, but of you are in first person view this is unacceptable and no one will be happy with your player.

Just some point form my experience.

[cpugh]

Hi,
I appreciate your detailed responses! This is very helpful. I'm saving everything in the event it is desired to put some of the explanations and steps into an article or tutorial once I'm finished with my tech demo.

I plan to address everything you posted; I had a late night at the office so I didn't have a chance to go through everything yet.

I did get as far as integrating the Newton character controller module into my demo.

It's in pretty good shape already though I need to work with it some more.

I made two modifications to the CustomPlayerController::PostUpdate method.

First, I changed the update logic to allow movement while in midair (I'm going for that classic first person arena shooter feel in my demo).

Second, I observed that when I pressed up against objects (the flat edge of the crate, or the surface of the Stanford bunny as a triangle mesh) and I keep holding down the forward key, the camera seems to jitter against it. I was able to correct this by changing the logic pertaining to D_PLAYER_CONTACT_SKIN_THICKNESS; This seems to be calculating a minimum distance away from contact points and when the camera advances in the integration loop moving that close and no closer.

My change simply makes sure that the resultant velocity is never backwards.

Code: Select all

  if (timetoImpact > 0.0f)
            {
                float deltaV = (timetoImpact * timestep) + (-D_PLAYER_CONTACT_SKIN_THICKNESS / sqrt(veloc%veloc)) ;
               
                deltaV = fmax(0.0, deltaV);

                matrix.m_posit += veloc.Scale (deltaV);
            }
            else
            {
                matrix.m_posit += veloc.Scale (timetoImpact * timestep);
            }


I'm not sure if this is the desired behavior but it did stabilize the camera motion when sliding against walls significantly.

The biggest issue I'm seeing so far is that the step height doesn't seem to have an effect.

Code: Select all

 m_controller = playerManager->CreatePlayer(playerMass, playerRadius, playerRadius * 0.5f, playerHeight, playerStep, playerAxis);


My understanding of this is that this parameter playerStep is for, eg, stair climbing. If I set this very low (or even zero) I seem to be climbing objects I should not be able to.

I have a tall crate that's a dynamics object; I can't climb it "easily" like a stair, but if I press and hold the forward key against it after a while the character will climb on top. The crate has a height of .8 meters, with a total player height of 1.8 meters from floor to top and I set the player step height to .14 all the way down to zero.

The Stanford bunny in my scene is much easier to climb but this is less obviously problematic since I'm guessing that parts of the object (the feet, etc) are acting like a ramp.

**The other thing that seems weird can be seen here:
https://www.youtube.com/watch?v=HLtHrDx ... e=youtu.be

I'm not exactly sure how the interaction with dynamics objects is implemented yet, but it seems that the character controller can push the box if you jump in the air or walk around on top of it but just holding the movement keys and running against it seems to have no effect. I'm not sure if this is the intended behavior or if there's something to configure.

I'll be back with updates once I get further!

Thanks!
Chris

[cpugh]

In addition to my previous post / edit I'd like to document the following bug:

https://www.youtube.com/watch?v=eL-QFg_ ... e=youtu.be

Pressing and holding the movement keys against an inclined polygon wall after jumping allows you to defy gravity and keep climbing up the wall. This is not the case for perfectly vertical walls.

This may be related to ramp detection? I'll look at this and see if I can't find a fix.

Edit : This is actually due to my changes allowing movement while in the air. I think I'm missing something.

-Chris

[Julio Jerez]

I am glad you are stress testing the player controller.

I am getting ready to wrap up 3.14 and start 3.15.
as soon as I complete the, the list of pending thong are
-complete the double
-complete the vehicle
-better coronoid destruction demos.

but this weekend I will review the player controller.
One thong I will do is that I will replace the interior collision shape from the convex hull that it use now to a thing capsule. I do not remember why I made a convex hull, by a thong capsule should yield smoother collision behavior.

The current behavior that you see in the controller come form my own experience and form some user input. So if you make a list of the thong you want to see, please do it and I see if I an accommodate that.

for the player controller fro newton 3.15 will be a full Character with self balancing capability, similar to what Euphoria does.
I will adapt Key frame animations and will and will also synthesize basics parametric stylized animation form parameters.
so the player will for example wall, run, jump, fall, and do all the basics thong a person do, from parameter. but if you have keyframe animation it will blend then by extracting the feature and added as force to control the player.

[godlike]

I have some improvements I'd like to throw into the mix since we opened this subject

A capsule will solve the sudden movement in stairs and other rough surfaces. In a test I was doing I found that the character couldn't push away rigid bodies of relatively low mass. Also crouching could be interesting but low priority really.

[Julio Jerez]

yes crouch is a good idea.

on this

A capsule will solve the sudden movement in stairs and other rough surfaces. In a test I was doing I found that the character couldn't push away rigid bodies of relatively low mass.

can you make a video so that I can see what you mean. the way I see the player should interact with all bodies according to the mass ratios. A light weigh object will be pushed harder than a heavy one.
if this is no how it behaves now please show me with a video.

[Crashy]

**The other thing that seems weird can be seen here:
https://www.youtube.com/watch?v=HLtHrDx ... e=youtu.be

I'm not exactly sure how the interaction with dynamics objects is implemented yet, but it seems that the character controller can push the box if you jump in the air or walk around on top of it but just holding the movement keys and running against it seems to have no effect. I'm not sure if this is the intended behavior or if there's something to configure.

While I'm re-testing the player controller, I'm still stuck to this issue (which I first described here: viewtopic.php?p=58222#p58222 )

Now I understand that the restraining distance is here to avoid the player kinematic body to penetrates other bodies. The counter part is that other bodies will never be aware of the contact, because player collision never truly interact with them.

If I force restraining distance to a negative value, the player can now interacts with other bodies, but of course, the resulting forces are totally wrong (IE: my 60kg player can push a box of 50000kg easily)

I still don't understand why this is working in the newton demos but not in my engine. But now I know I'm not the only one to have issues in this case.

[Crashy]

I think I've found something...

In the BasicPlayerController demo, the player controller is created like this:

m_controller = manager->CreatePlayer(PLAYER_MASS, radius, radius * 0.5f, height, height * 0.33f, playerAxis);

And the player cannot push the box

In the AdvancedPlayerController demo, the player controller is created like this

m_controller = manager->CreatePlayer(80.0f, radius*0.5, radius, height, height * 0.33f, playerAxis);

And the player can interact with other bodies, but the outer radius is smaller than the inner radius.

EDIT:
I've found a setup which seems to work fine:
inner radius: 0.5
outer radius: 0.35
restraining distance: 0.1

Thus the "inner" volume is pushing objects, and the "outer" volume + the restraining distance avoids player to penetrate/climb on objects(except if they're smaller than step size).
With this setup I can push a sphere of 50kg but I can't push a sphere of 50000kg, which is fine.

[Julio Jerez]

I am a little confused here, a body who is 50kg can never push a body who is 50000kg
how did that happens?

also when you set the restraint distance, I believe you can get collision notification in the player
ProcessContacts callback

Code: Select all

virtual int CustomPlayerControllerManager::ProcessContacts (const CustomPlayerController* const controller, NewtonWorldConvexCastReturnInfo* const contacts, int count) const;

in the demo does no do anything because I do not know what to do. I staimeted to be is a gameplay specific action.

this is wha at the demos does

Code: Select all

   virtual int ProcessContacts (const CustomPlayerController* const controller, NewtonWorldConvexCastReturnInfo* const contacts, int count) const
   {
      count = CustomPlayerControllerManager::ProcessContacts (controller, contacts, count);
      return count;
   }

but you can iterate over the contact array and apply you game logic.
does that solve the problem?

[Crashy]

I am a little confused here, a body who is 50kg can never push a body who is 50000kg
how did that happens?

Well, I think it doesn't really pushes it, but the body simply reacts to the facts it's penetrated the kinematic body.
I know about the contact callback, which is really fine.
What's strange is the naming of "inner" and "outer", because if I want to be able to push other bodies, I need to set an inner radius larger than an outer radius, like in the AdvancedPlayerController demo, which is quite confusing.
From what I understand, the "inner" shape is used to make other bodies collides the player, and the "outer" to perfom the convex cast and avoid the player to penetrates other bodies + generate contact related events.

[Julio Jerez]

What's strange is the naming of "inner" and "outer", because if I want to be able to push other bodies, I need to set an inner radius larger than an outer radius,

yes that is strange, the inner radius can not be bigger that the outer radios.

Maybe if you recreate you test case in the basics player controller I can help you out.
just place the building for a flatplane and place the objects you need to collide with there we can tune it to do what you want.