Vehicle collision issues

#81 :-) I had planned on it. Of course, even at 50 I could sometimes pass through dif's.

No lockups, though!

#82 FYI I got around to doing my integration testing, and it appears that it's the other values that make the big difference. Even at integration=4, those simple datablock changes make all the difference in the world.

Namely:

collisionTol = 0.6;
contactTol = 0.6;
bodyFriction = 0.6;
bodyRestitution = 0.1;

#83 There's more to the bugs than simple datablock values will fix, unfortunately. There are fundamental flaws in both the collision detection and the collision resolution code for rigid bodies.

#84 Yeah, I'm only at about 99% fixed with that, which is not as good as it sounds, of course.

Oh well, if I manage to sell my game, I may just have to port it to another engine :-P

#85 Be very cautios with bumping the integration up alot. To put it very simply, a vehicle with integration of 50 will require 50 times more power than a vehicle with an integration of 1.

#86 Thanks for that, and quite right. I got about a 10 FPS boost when I went back down to 4 :-)

#87 Earlier in this post is a Rigid::ResolveCollision method posted by Akio which I used in Wheelracer with great success.

Here are the datablock values I used

drag = 0.6;                // Drag coefficient
   bodyFriction = 0.6;
   bodyRestitution = 0.4;
   minImpactSpeed = 5;        // Impacts over this invoke the script callback
   softImpactSpeed = 10;       // Play SoftImpact Sound
   hardImpactSpeed = 35;      // Play HardImpact Sound
   integration = 4;           // Physics integration: TickSec/Rate
   collisionTol = 0.2;        // Collision distance tolerance
   contactTol = 0.2;          // Contact velocity tolerance

#88 @Duncan - Did you have to make any additional changes to get it to work correctly for all aspects?

According to QuangKim there were a few issues with it.

#89 I did find other problems/bugs which caused vehicles to get stuck but I made a work around because I never got to the actual source of the problem.

I noticed that the castray used for the wheels, and thus used for keeping the vehicle collision hull off the ground, would often fail to recognize the ground and the vehicle would 'fall', make contact with the terrain and get stuck due to the ground-friction component of the onCollision code in vehicle.cc. I took out the ground friction because Wheelracer was a ball and thus its wheel was always in contact with the ground and did not require the ground-friction.

Most four wheel vehicles don't notice that sometimes the wheel cast-ray fails to find terrain when it should, but a single wheel vehicle crashes when it occurs (about once every 15 seconds) and I solved it by having 5 castrays to locate terrain below, front,back,left,right (at 45 degree angles) I did notice that the 45 degree cast rays were 99% successful at 'seeing' the terrain compared to the straight-down castray which lazy by comparrison.

Once the vehicle collision hull makes contact with ground, a different calculation is applied and the hull gets 'sticky' with its ground contact. Even after the castray wakes-up and sees the ground, the 'collision contact' calculation takes precendance over the wheel physics and I had to add additional up-force to the collision contact code to bump the vehicle up if it was in a situation where the wheel was in contact with the ground AND the collision hull was in contact with the ground.

As I said, it's a work-around. Sequence seems to be:
(1) cast ray fails when it should not (perhaps angle the castray to solve this)
(2) collision hull then contacts ground
(3) 'something' then applies a sticky force between collision hull and ground
(4) the ground sticky force is stronger than the wheel upwards physics force and vehicle bogs down
(5) work-around, bump vehicle up to overcome sticky force

So there's two areas to debug. The castray and the ground 'sticky' force.

I looked into it but my understanding of the collision code is limited, as was my time, so I went for my hacky solution.

#90 Just a quick note...I'm not really qualified to comment, but I've noticed that actually _lowering_ integration seems to help. Presumeably reducing the number of times the collision code is called?

It helped with some of my RigidShapes a LOT, and seems to help aircraft some as well.

Nothing like a real fix, but interesting, I thought, nonetheless.

#91 If anyone is interested I've posted up some fixes we wrote for vehicle collision here at Sickhead Games.
www.garagegames.com/mg/forums/result.thread.php?qt=63305

#92 Hmmmm... .... BFT?

#93 Haha, I thought too what BFT could mean... :-) thanks for the link.

#94 @Duncan--that looks really, really good. So. When will it be released?

:>

#95 Cool..several weeks, eh? That's like a split-second in software development land!

#96 @Duncan--Since you say you've fixed vehicles getting stuck in your kit, does that mean your kit comes with engine source code that fixes it?

#97 I've watched this topic a long time. I'd just like to add my 2c.

Multi-Player prediction - when a human client is network lagged, all other clients see the lagged client at the position that the lagged client started to lag, not at the position that the server SHOULD put them as a result of physics engine. Why?
e.g. Lagged players hover in mid-air, thus breaking the game's physics rules.

IF indeed the server does know where the client should be (on the ground, probably constantly moving forward). Why does the server choose to send the incorrect position to all other players.

Could this be related to vehicle lag.?

#98 @TerroX, I doubt it's to do with the vehicle stuff, or the player collisions. Probably something to do with the updates between client/server. I'd suggest getting the game into a test case with that issue, and setting a breakpoint inside Player::processTick to nail it down (I think).

#99 @Ross, I don't think any of our coders are going to track it down. I just know it happens and it seems illogical. Probably something to be changed in the core. Tribes 1 did it the other way, lagged players went in a straight line and lagged clients found themselves somewhere else when they unlagged. Tribes 2 does what TGE does. Maybe there is just a flag for this setting.