Character Controller

[Julio Jerez]

after you create the controller ther is a parameter call restraing distance

m_controller->SetRestrainingDistance(0.1f);

to what value did you ste thta?
the behaviuor for push bodies is no defined, teh controoler try to be smart about, but I beleiev that I nee to let that to the user.
try setting the restraining distance, see if that works, and if not tell me what do you expect the behavior to be, I can add that quiclly.

as for floor intepenetarion I did not see any penetration on that video.
your picking and drag code seems to be changing the body position, is that what you are doing?

[skarab24]

Ok, I set it the same :

Code: Select all

_PlayerController->SetRestrainingDistance(0.1f);


Between, it works really good with Sphere rigid bodies, I guess it's some precision problems.
For a cube it should allow to make it slides if its mass is less than controller, but it mays be tricky depending of surfaces...

edit: Yes, the gizmo changes matrices, but i double checked it doesnt do any modification when not active.

[skarab24]

Ok, for now the mass of rigid bodies doesn't influence the "pushing behavior" of the controller, right ?

[Julio Jerez]

the mass of the righ body does not affect teh playe yes, but the mass of player does affect the rigid body.

and you should not move bodies by setting te matrix, later I will post a pirce of code that will show you how to do it by setting the velocity.

ther if code that does by change the force, by that's to complex so I will chanage it to be velocity based.

[skarab24]

Ok, thanks!

And I modified this :

Code: Select all

dgFloat32 dgCollisionInstance::ConvexRayCast (const dgCollisionInstance* const convexShape, const dgMatrix& convexShapeMatrix, const dgVector& localVeloc, dgFloat32 minT, dgContactPoint& contactOut, OnRayPrecastAction preFilter, const dgBody* const referenceBody, void* const userData, dgInt32 threadId) const
{
   if ((GetCollisionPrimityType() != m_nullCollision) && (!preFilter || preFilter(referenceBody, this, userData))) {
      //if (m_scaleIsUnit) {
         dgFloat32 t = m_childShape->ConvexRayCast (convexShape, convexShapeMatrix, localVeloc, minT, contactOut, referenceBody, this, userData, threadId);
         if (t <= minT) {
            if (!(m_childShape->IsType(dgCollision::dgCollisionMesh_RTTI) || m_childShape->IsType(dgCollision::dgCollisionCompound_RTTI))) {
               contactOut.m_shapeId0 = GetUserDataID();
               contactOut.m_shapeId1 = GetUserDataID();
            }
            contactOut.m_collision0 = this;
            contactOut.m_collision1 = this;
         }
         return t;
      //} else {
      //   dgAssert (0);
      //}
   }

   return dgFloat32 (1.2f);
}


ConvexRayCast seems to handle non-uniform nicely for now, will see if something break later on.

[skarab24]

In case it interests you, here is the resulting game of my tests.
Non-uniform scale everywhere, but no skew/shear, will try to add some later on.

[Julio Jerez]

am I suppose to see something there?

[skarab24]

Sure, collisions work fine, but it still have the moving box problem, way better than 3.x, but still some problems, sticking to Newton 2.x for now, since the behavior is way better.
Hope to have working 3.x later on...

edit: I'm a bit fed up now, I have past time to customize 2.x to have triggers and things working a bit, will do more testing on 3.x / switch when I got more time, sorry to sound bad ass... Just tested other physics engine, even the bullet's controller is far way down (read: crappy) from this. fed up. be back later, thanks for you help!

[Julio Jerez]

you need to stay with 3.11
The way to fix the problems is by working on then not by going back and forward.

can you post a video of the player shown the behavior you want to change?

[skarab24]

Yes you are right. To explain a bit, I had wrapper working for both 2.x and 3.x, but pushed by time I had taken the one requiring less dev, you know.
I'll remove the 2.x wrapping, and stick to 3.x.

Basically I think I need to implement some collision callback for the player controller, this to be able to detect triggers and interact with rigid bodies. In this case it will be fully customizable (applied force, "big push", slide or roll depending of forces, etc...). Thanks!

[Julio Jerez]

make the youtube movie so that I can see the problem that you are running into.

That way I may be able to help you to solve it.
if you do no show me what you want them, I can only go by what I think people want. and some time that two goal may diverge.

Make a youtube movie splease..

[skarab24]

Sure, but hard to do a video since it's "really specific behavior".

In real life, just imagine you have a big cube (with light mass) in front of you :

- you push it with low "velocity" : the cube just slide with the same velocity, or stay depending of surface
- you push it with medium "velocity" : the cube may slide fast or roll depending of the surface "rugness" (material "static friction" ?)
- you push it with high "velocity" : it begins to rolls then eject...

Yes, depending of character rotation/normal as well.

All those parameters depends of the character "force/mass" vs rigid body mass, and surface contacts, and some user tweaking.
Your character controller is the best I've seen in a physics engine, but having some "contact processor" handling those kind of things would be awesome.

(just remember Doom3, you were able to make a box slide, or even roll it if I remember correctly)

[FSA]

I've also written the proposal with the CollideCallback. I think Julio said that he will implement it when he has done other stuff.

[skarab24]

Ok, using same trick I did for Newton 2.5 to get triggers seems to work on the 3.x svn.

But, is it possible to get this : "dgCollisionInstance::ConvexRayCast" fixed/implemented for non-unit scale support ?

[skarab24]

And here is the video showing what happens if i bypass the scale checking : http://youtu.be/64rQt0WEGoM
Not sure if those problems come from this, between.