Vehicle collision issues

#61 Akio - don't misunderstand me, I'm not complaining that you "advertised" your solution here, or that you're charging for it.

Heck, I'd pay for a solid vehicle collision fix, but my design calls for cross-platform compatibility, so that pretty much precludes your particular solution. =\

Stefan: email sent. =)

#62 I actually have the library distribution in all platforms, however, I was informed I can't sell this.

Zannendesu.

#63 I agree Markus, after all it's a bug, not a feature.

Any results will be shared, of course. But right now there's no magic solution, just some hacking that does work, but not always. Need more time to work on it.

EddieRay: I sent a copy of my email to Kirby, to you as well.

#64 Stefan - I sent you another email.

Your previous message never came through.

I just love technology. =P

#65 Akio, my game has many engine modifications throughout, is this likely to be a problem with your fix, since you're only offering it as a .dll? thanks..

#66 Here are some tips on resolving the collision issues. Information described are same as what I wrote in the 'merge process' section in the dll package, but w/ a little more detail.

tsshape.h

struct ConvexHullAccelerator {
   S32 numVerts;
   Point3F* vertexList;
   [b]S32 numFaces;
   Point3I* faceList;[/b]
   Point3F* normalList;
   U8** emitStrings;
};

tsshape.cc
Add the face list information in void TSShape::computeAccelerator(S32 dl) near the vertex list allocation.

accel->numFaces = cf.mFaceList.size();
   accel->faceList =  new Point3I[cf.mFaceList.size()];

  [i]//get the face list[/i]
   for (i = 0; i < cf.mFaceList.size(); i++)
   {
      accel->faceList[i].x = cf.mFaceList[i].vertex[0];
      accel->faceList[i].y = cf.mFaceList[i].vertex[1];
      accel->faceList[i].z = cf.mFaceList[i].vertex[2];
      accel->normalList[i] = cf.mFaceList[i].normal;
   }

shapeBase.cc
Instead of recalculating the convex feature based on the normal, pass the entire facelist created in tsshape.cc. This change alone should provide drastic improvement in the collision and should prevent objects from sinking or passing through the terrain.

Re-pasting my Rigid::resolvecollision routine. Someone commented that this code wouldn't work, so use your own discretion. It's what I have in my demo.

bool Rigid::resolveCollision(const Collision &col)
{
    Point3F v,r;
    getOriginVector(col.point,&r);
    getVelocity(r,&v);

    F32 n = -mDot(v, col.normal);

    if (n >= 0.0f)
    {
        [b]// based on "Physics for Game Developer"[/b]
        Point3F a1,b1,c1;
        mCross(r,col.normal,&a1);
        invWorldInertia.mulV(a1,&b1);
        mCross(b1,r,&c1);

        F32 f4 = mDot(col.normal, c1);
        F32 impNum = n * (1.0f + restitution);
        F32 impDenom = oneOverMass + f4;
        Point3F t1, tangent;
        mCross(col.normal, v, &t1);
        mCross(t1, col.normal, &tangent);
        tangent *= -1.0f;
        tangent.normalize();
        F32 Vrt = mDot(v, tangent);

        F32 mu = 0.2f;                   // friction

        if (mFabs(impDenom) > 1e-3f)
        {
            F32 impulse = (impNum / impDenom);
            Point3F impulsenoFriction = impulse * col.normal;
            Point3F impulsefrict = impulsenoFriction + (mu * impulse)*tangent;

            if (mFabs(Vrt) > 0.0f)
            {
                applyImpulse(r,impulsefrict);
            }
            else
            {
                applyImpulse(r,impulsenoFriction);
            }
        }
    }
    else
    {
        return false;
    }

    return true;
}

Additional info: it may be better off re-writing the entire convex collision routine using your own trimesh collision routines. If you don't have one, then you start w/ code that's available.

Merry Christmas:)

#67 Thanks mate! Looking forward to trying this out when the kids give me a break from playing lightsabres!

#68 Thanks Akio, I continue looking into your tips.
After days by days debug, I observed that:
1) rigid.resolveCollision is correct. ( work ok, regardless physics aspects)
2) vehicle.resolvecollision loop is correct too.
I think the problem now is collision points. (maybe Akio know all of the problem ;->).
For Example A collide with B.
Collision point.normal return from the getCollisionInfo is not correct.
in A.resolveCollision, some normals have the direction into the object B.
So A can go throught B but only sometime -> unstable.
I test with my vehicle collision, I enable rigid.resolvecollision(....,otherRigid).
Wow swiming in the convex soup is very difficult but I have no way.
Let's go. ;->
Happy new year all my friends!!!
Best wishes for Torque and everyone.

#69 I'm sure the resolvecollision fix is good, but it has some syntax errors in it.

For one:

Quote:
bool Rigid::resolveCollision(const Collision &col)

I'm also not sure why it says ShapeBase, because it's in rigid.cc.

#70 Stefan: he didn't actually give any code for shapebase, he merely described what should be done there.

#71 Gotcha Sam, thanks.

#72 Ok, after mess with Torque Collision code, I realize some things:
1) Torque's collision procdure seems ok in:
- Detect collision based on GJK (convex object).
- Resolve collision based on impulse calculation.
---> I think all of them work ok.
2) So there are some problems with collision for example object going through other objects...
- This is some words in the rigid body tutorial:
from http://www.d6.com/users/checker/dynamics.htm#articles
"...Another addition made to the system, is dealing with OVERLAP. This is simply to stop objects sinking into each other, since the IMPULSE CALCULATION used is very INACCURATE low velocities. To solve an overlap, it's simply a matter of pushing the objects away from each others along the normal of collision, by the collision depth amount. That of course, applies only if an overlap is detected."
--> this is the lack of argorithm that need some hack.

So in vehicle resolve collision, if you drive the vehicle at hight speed the collision is ok, at low speed the vehicle can go through orther vehicle.
Then I add some code like that: ( into resolve collision loop in resolvecollision in vehicle.cc)
a->mRigid->linPosition+=c.distance/2*normal
b->mRigid->linPosition-=c.distance/2*normal
To stop a sinking into B, and the result better. A never go through B but this solution is only good for 2D not for 3D.
This is only the observation of current Torque code. To improve Torque collision, we have to look int to ODE or some better physics solution like the one of Akio.

Torque have good physics base code, we still continue improving it, so please share you ideal for newbies like me, and hope that we will have a better engine.

Thanks. ;->

#73

Quote:
So in vehicle resolve collision, if you drive the vehicle at hight speed the collision is ok, at low speed the vehicle can go through orther vehicle.

I have to jump in here and say that, in stock Torque, this is not entirely true... in fact, I experience the exact opposite of this behavior.

As previously stated, my vehicles move at speeds < 200 and, at top speed, I can punch through terrain and interiors/ buildings as if they weren't even there.

At slower speeds, collision seems solid and reliable. =\

#74 Kirby: if that's what you're experiencing at high speeds, does increasing the vehicle's integration rate fix it?

#75 I can't help much because I'm a scriptor but I can say, Please Please fix this even a bit and I well be happy. I'm using players where vehicles should be used in my game because of the current vehicle problems and it would be a lot better to use vehicles.

#76 Sam,

No. IIRC the maximum applicable integration is 4 (larger numbers get ignored?) and while there may be a marginal difference, it's not enough to make a difference at the speeds at which my hovers operate.

I have a log full of physics changes that have resulted in, more often than not, collisions with terrain responding properly, though occasionally I can get through.

Interiors are another matter entirely. =\

#77 I have been working on a prototype with vehicles, using upscaled models to get better tesselation from the terrain without losing water support. Since the vehicle moves like a slug being so big, we are working with an increased $timescale, artifically upscaling the time, and making the physics look like a normal sized world.

We had the vehicle fall trouch/get stuck on the terrain, DTS shapes and other vehicles a lot, and tried setting the integrations to high values, but that causes undesirable results. But I settled some values that allow the physics to work properly without borking the collisions with a mere 2 iterations.

The key datablock fields to tweak are collisionTol , contactTol and bodyRestitution. Since our vehicles are large in Torque units, increasing the collisionTol solved most go-through problems, and increasing the bodyRestitution solved the get-stuck problems.

The Torque vehicles are very nice, and work very well. I'm impressed with the results in our prototype (I think the physics alone might get our game sold). They're just a PITA to setup correctly, and expect spending a day or two tweaking the datablock values to get they moving as you want.

#78 What is the final resolution to the problem? I have used the code from Martin's second post, and made the necessary datablock changes, yet I still get stuck in the terrain, am able to fly through it, and collisions still crash the application.

#79 If anyone's interested, I just added the datablock values Martin Hoover started with, and integration=50 in TGE 1.5 and the problem seems 99% solved.

Still not 100%, but a heck of a lot better than 2%!

I suppose 50 is a ridiculous integration value...or is it?

#80 That might be a bit over the top, see how low you can get it without issues.