Game Development Community

Problem with Vehicle Collision

by Mike Kuklinski · in Torque Game Engine · 03/31/2004 (9:19 pm) · 14 replies

Well, every time a VEHICLE collides with another object that is collidable, be it a shape or interior, once in a while, usually 50% of the time, the game will permanantly hang. Now, I can shoot stuff, and no hang, but collide vehiclewize, hang.

The only stuff we have changed:

No Terrain
Physical Zone with zero gravity stretching most of the map

here is the vehicle datablock (note its a space vehicle):

datablock FlyingVehicleData(Hellcat)
{
spawnOffset = "0 0 2";
category = "Vehicles";
shapeFile = "~/data/shapes/vehicles/hellcat.dts";
multipassenger = false;
emap = true;
envMapIntensity = "0.5";
useEyePoint = true;
drag = 0.0;
density = 0.0;
mountPose[0] = sitting;
numMountPoints = 1;
isProtectedMountPoint[0] = true;
cameraMaxDist = 0.5;
cameraOffset = 0;
cameraLag = 0.0;
cameraRoll = true;
explosion = dralthiexplosionemitter;
explosionDamage = 10.5;
explosionRadius = 15.0;
maxDamage = 60;
destroyedLevel = 59;
isShielded = true;
energyPerDamagePoint = 160;
maxEnergy = 280;
rechargeRate = 0.8;
minDrag = 0;
rotationalDrag = 30;
maxAutoSpeed = 0;
autoAngularForce = 10;
autoLinearForce = 0;
autoInputDamping = 2;
integration = 6;
collisionTol = 0.2;
contactTol = 0.1;
maxSteeringAngle = 2;
horizontalSurfaceForce = 13;
verticalSurfaceForce = 5;
maneuveringForce = 2400;
steeringForce = 300;
steeringRollForce = 10;
rollForce = 0;
hoverHeight = 45;
createHoverHeight = 45;
maxSpeed = 60;
jetForce = 3000;
minJetEnergy = 28;
jetEnergyDrain = 2.8;
vertThrustMultiple = 3.0;
mass = 30;
bodyFriction = 0;
bodyRestitution = 1.0;
minRollSpeed = 2000;
softImpactSpeed = 3;
hardImpactSpeed = 15;
minImpactSpeed = 10;
speedDamageScale = 0.06;
collDamageThresholdVel = 23.0;
collDamageMultiplier = 0.02;
minTrailSpeed = 10;
trailEmitter = ContrailEmitter;
forwardJetEmitter = FlyerJetEmitter;
jetSound = thrust;
engineSound = engine;
softImpactSound = armorhit;
hardImpactSound = armorhit;
triggerDustHeight = 4.0;
dustHeight = 1.0;
damageEmitterOffset[0] = "0.0 -3.0 0.0 ";
damageLevelTolerance[0] = 0.3;
damageLevelTolerance[1] = 0.7;
numDmgEmitterAreas = 3;
minMountDist = 2;
checkRadius = 5.5;
observeParameters = "0 0 0";
shieldEffectScale = "0.937 1.125 0.60";
};


Bitte hilfe :(
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Associate Matt Fairfax
PopCap
#1
04/01/2004 (5:13 am)
This might be helpful...

Quote:
The culprit might be the iterative solver in the vehicle collision code (Vehicle::resolveCollision). It's based on Baraff's algorithm but places Coulomb friction inside the iteration step (inside Rigid::resolveCollision), which frequently causes a dramatic increase in the number of iterations required to derive a solution, sometimes overcalculates (or was that undercalculates? :/ ) restitution, and in the worst case produces float errors and astronomically incorrect values for force. The former two cause CPU chugging and non-intuitive physical behaviour, but the lattermost produces an astronomical value for linVelocity causing a gigantic bounding box to be calculated in Vehicle::updateWorkingCollisionSet, so that Convex::updateWorkingList tries to add a massive number of terrain polys to the working list (TerrainBlock::buildConvex). ALT-TAB back to your debugger when you get a freeze, DEBUG->BREAK-ALL, then you'll probably need to switch to the main thread, and you'll probably find the main thread at Convex::getType which was called from TerrainBlock::buildConvex.

At this point check the vehicle's values for torque and force, and the size of the bounding box being used to build the working set. You should see float errors (probably in torque) and ridiculous values for force and linVelocity, and a bounding box that's probably spanning multiple terrain blocks.

If that isn't what is happening, ignore the following :) . You can just fine tune the datablock parameters until the freezes go away (keeping bodyFriction low appears to work well, because it stops the Coulomb friction from destabilizing the iterative solver), but I actually broke the Coulomb friction calculation step out of the Rigid::resolveCollision, calculate it in a separate step in Vehicle::resolveCollision, and then let the Baraff iterative solver do its work (the friction must be done first, because otherwise it will invalidate the iterative solver's results!). I never could find a reference justifying placing the Coulomb friction inside Baraff's iterative solver (if anyone has a reference, I'd really appreciate it), and so far my techique eliminated the CPU chugging, overbounce, and engine freezes, and produces intuitive behaviour. Plus, I can use fairly high values for bodyFriction and not be limited to simulating everything as if it had the friction coefficient of Teflon on Teflon.

I still have problems with the vehicle sometimes missing collisions, but it usually happens at high speeds so I suspect the bounding box used to calculate the collision working set might be undersized, but I have no justification for that other than 'educated guess'. That problem is lower on my list (much lower than fixing the engine freeze, anyway).

If you think this is your problem and you'd like, I'll send you a patch or sample code.

But there are other conditions that cause force or torque to destabilize (but they cause similar engine freezes).

-- Brad Shapcott

Torque Owner John Vanderbeck
VanderGames
#2
04/01/2004 (6:55 am)
That's some nice information Matthew. I just ran into what I think is the same thing a little bit ago. I rammed one of our vehicles into the inside corner of a DTS and locked the whole game up :(

I can't seem to reproduce it htough, but next time it happnes i'll check this and see if its the same thing.

Associate Kyle Carter
#3
04/02/2004 (8:22 am)
Did this ever get into HEAD? :)

Torque Owner John Vanderbeck
VanderGames
#4
04/02/2004 (7:41 pm)
@Ben

Theres a lot of big physics words in that paragraph that I don't understand, however I just ran into a collision freeze so I broke in and dug around. My understanding of the above is that the root of the problem stems from Rigid::resolveCollision() being called from within Vehicle::resolveCollision(). I can say that as of about a week old HEAD version, this is still the case. I'm looking at the code right now.

It never seems to get out of Vehicle::resolveCollision() and Rigid:resolveCollision() seems to just get called over and over and over ad nauseum.

I seem to have run into a situation where I can reproduce this every time. I forgot to add spawn locations to a new map, so the vehicle spawns in the middle of nowhere and falls to the ground. When it hits, it tilts up bouncing then locks. It did it 3 times in a row.

So what i'm going to do is try pulling this routine out like is mentioned above and see what happens.

Torque Owner Brad Shapcott
#5
04/03/2004 (2:21 am)
Quote:
So what i'm going to do is try pulling this routine out like is mentioned above and see what happens.

@Mike: bodyRestitution = 1.0 needs to be changed to some value less than 1.

@ John:

Only the friction calculation is removed from inside the loop. But you can scratch-test if this is your problem by setting bodyFriction to 0. Because the Baraff algorithm without friction always removes energy from the physical system (assuming bodyRestitution is less than 1) it is guaranteed to terminate, although it can be in exponential time (though it is usually linear).

Tweaking collisionTol also helps, usually by setting a higher value. Higher values of collisionTol also seem to help with missed collisions (I've been using 0.6, the default is 0.1). Also try tweaking contactTol. The Baraff algorithm may terminate earlier with higher values -- although if the calculations are 'running away', the setting of contactTol doesn't matter.

The phenomena occurs more frequently in collisions involving terrain because they generate more collision points, giving the Baraff algorithm more to chew (and choke) on. If you turn on debug graphics with $GameBase::boundingBox = 1; you'll notice a lot of collision points (little blue boxes) being generated where the collision hull is in contact with terrain.

@All:

Someday I hope to have my code changes into a decent enough state to make a resource or even merge into HEAD. Especially I'd like to try using the analytical method Baraff mentions since it would really help with the common case of a vehicle colliding with terrain head-on. But right now I just have that code 'mostly working' with plans to revisit later while I work on something completely different.

Torque Owner Mike Kuklinski
#6
04/03/2004 (4:58 am)
I had already changed bodyRestitution. No real change. Also, I have no terrain, as I said.

Torque Owner Rex
BrokeAss Games
#7
04/03/2004 (5:35 am)
...ah, that explains what happened when I started fooling with BODY RESTITUTION; the vehicle when spawned would bounce and continue bouncing in a decaying sequencel; ie, the bounces would get smaller and smaller until the vehicle appeared to simply be vibrating...thanks, sorry to intrude. My wheel speed is extremely low, prolly keeps the hang from occuring, I can 'feel' small collisions with some Fx grass replications as I chug across them....Thanks again for explainations on some of the pertinent variables. :)

Torque Owner John Vanderbeck
VanderGames
#8
04/03/2004 (7:00 am)
@Brad
I wasn't very coherant when I wrote my above post. Sorry for that. I was at the tail end of a coding session, ready to go to bed, when I went to test something else and ran into this.

I just checked the datablock for this vehicle and it had a bodyFriction of 0.0 and a bodyRestitution of 1.0

I changed bodyRestitution to 0.5 and i'm going to try this again.

Just to clarify what you are referring to...

Torque Owner John Vanderbeck
VanderGames
#9
04/03/2004 (7:04 am)
Lowering bodyRestitution (I first did 0.5 then 0.1) does make a difference. It casues it to "bounce" a bit first instead of hard locking. There is a noticeable framerate loss when it does. It is faster with a bodyRestitution of 0.1 than 0.5. However, with that change after it bounces a bit it falls through the terrain.

I think though, and please correct me if i'm wrong, that this just illustrates that I am indeed facing the problem you refer to?

Would pulling out the section I bolded in the code above help to fix this?

I would be very interested to see the change you made in this regard.

Torque 3D Owner Frogger
#10
04/03/2004 (8:03 am)
WOW! It really does! Although it does mess with the framerate, especially near /in interiors.

Torque Owner Brad Shapcott
#11
04/03/2004 (9:24 am)
@John:

This is one of the public forums, so if you move your post over to a private SDK area, I'll respond.

I think GG doesn't like seeing source code in the public areas.

Torque 3D Owner Bruce Wallace
#12
04/03/2004 (9:34 am)
I've just recently came across this problem as well with a flying vehicle. The model is fairly large and when it is left to float to the ground, as soon as it touches the ground its hard to even observe with a framerate of 1-4.

I may have to see if I can fix hoverheight that seems to have been broke since the vehicle changes awhile ago. Because it slowly slides itself across the ground with micro bounces that kill framerate.

Does anyone have any other ideas on what may be able to be done about vehicles resting on terrain? I've tried tweaking the datablock and will continue to do so. The information in this thread has given me some ideas.

I really don't want to resort to telling my modeler that the landing surface is too big to rest on and that he has to start over.

Good information here, thanks.

Torque Owner John Vanderbeck
VanderGames
#13
04/03/2004 (10:07 am)
@Brad
Crap! I didin't realize I was in the public forums :( I almost never come here.

Torque Owner Juan Aramburu
#14
06/10/2006 (12:58 am)
Can anyone help here? I'm having the problem of our Wheeled/Flying Vehicle bouncing around too much & way too fast (sometimes never exiting that for loop described by Brad).