T3D 1.1 FINAL - Cheetah - on collision with trees/foliage FPS drop - LOGGED (THREED-2004)

#1 This originally caused a complete engine lockup. The problem has been around for a few Torque engine iterations. If you have a vehicle in a level, you want to make sure you are using optimized collision meshes for environmental objects (like trees). Having a tree with a lot (tens of thousands) polygons using visible mesh collision is really going to hurt the CPU when a vehicle collides with it.

Quote:Also noticed that when you drive really fast and the cheetah turns over, you end up falling through the terrain like quick sand :)

Yeah, this is due to the mass of the Cheetah. It is way to heavy and will be tweaked in a later release.

#2 thanks for the reply Mich. I only brought it up as I'm working on a car and speed boat game idea at the moment, that may use the vehicle code base and wondered if there was a solution to a possible problem, but you've cleared that up.

#3 I dont think the quicksand issue is a mass issue.
I just ran through it a bit and watched was it does..

When it hits on its side, those wheels pass into terrain until it hits
the Collision box of the vehicle and stops there.
That leaves one set of wheels above ground and one set below.
It then drops over a bit and the side above ground properly sticks to
ground while the side below never comes up to grnd lvl.
Its only the Wheels that drop below the terrain, not the body box.

It's at this point it starts to sink.

*edit*
Just did some quick tests further towards the Mass as possible cause.
No real effect with just a Mass change. Its when I did a change to
the Center of Mass (Bringing it up to -0.15) that a noticed a funny
change.

It actually popped over twice from the half sunken position.
Each flip while at rest from the sunken position would sink on the
the other side lol. in the end tho at those settings, it popped
itself out of the ground.

Mass was at 100 at this point. It would need more tweaking to the
other forces to get it running nice at this mass tho.

#4 Just tried a simple Hack...
This causes it to corretc and right itself with the default
car settings (Cheetah) but needa proper fix to stop the wheels
from passing thru the terrain to begin with..

void WheeledVehicle::extendWheels(bool clientHack)
{
   PROFILE_SCOPE( WheeledVehicle_ExtendWheels );

   disableCollision();
...
...
         RayInfo rInfo;
         if (mContainer->castRay(sp, ep, sClientCollisionMask & ~PlayerObjectType, &rInfo)) 
         {
            wheel->surface.contact  = true;
            wheel->extension = (rInfo.t < ts)? 0: (rInfo.t - ts) / (1 - ts);
            wheel->surface.normal   = rInfo.normal;
            wheel->surface.pos      = rInfo.point;
            wheel->surface.material = rInfo.material;
            wheel->surface.object   = rInfo.object;
         }
			else
			{
				sp.zero();
				vec.zero();
	         currMatrix.mulP(wheel->data->pos,&sp);
				currMatrix.mulV(VectorF(0,0,wheel->spring->length),&vec);
				ts = wheel->tire->radius / wheel->spring->length;
				ep = sp + (vec * (1 + ts));
				ts = ts / (1+ts);
				if (mContainer->castRay(sp, ep, sClientCollisionMask & ~PlayerObjectType, &rInfo)) 
				{
					wheel->surface.contact  = true;
					wheel->extension = (rInfo.t < ts)? 0: (rInfo.t - ts) / (1 - ts);
					wheel->surface.normal   = rInfo.normal;
					wheel->surface.pos      = rInfo.point;
					wheel->surface.material = rInfo.material;
					wheel->surface.object   = rInfo.object;
				}
				else 
				{
					wheel->surface.contact = false;
					wheel->slipping = true;
				}
			}
      }
   }
   enableCollision();
}

This is NOT a fix, but at least stops it from sinking for now..

**edit**
Okay, doesn't fully fix a sink from a complete upside down position
Only if one or more of the tires has gotten below the terrain :(

#5 @S2P
Are you working from a clean 1.1 install? You shouldn't be seeing such a large performance drop when colliding with trees in the stock build.

#6 *this is a 1.1 final with only changes to allow { <-/-> a/d } keys for steering instead of mouse. *

This seemed to help a bit better without needing that extra raycast..

bool WheeledVehicle::buildPolyList(PolyListContext context, AbstractPolyList* polyList, const Box3F& box, const SphereF& sphere)
{
   PROFILE_SCOPE( WheeledVehicle_BuildPolyList )
...
..
         Box3F wbox;
         F32 radius = wheel->tire->radius;

			//Mythic DEBUG Wheel Sinking Issues
         //wbox.minExtents.x = -(wbox.maxExtents.x = radius / 2);
         wbox.minExtents.x = -(wbox.maxExtents.x = radius * 0.75);
...
..

The wheels tend to stay out of the terrain better.
Still will sink once fully flipped over tho..

#7 @John - on my test the whole vehicle eventually fell through after trying the CTRL key to right itself, which it didn't do once it was stuck there.

@Scott - on the stock build, no changes after install. I did not recompile it - not sure that would make a difference though. If you drive it right into the trees and then continue forwards, you will see a drop until it stops responding.

Edit: I'll do a video on it later. My graphics card is a Nvidia Geforce 9600 GSO - plus check the drivers later also.

#8 @John - thanks for the script - I'll check it out later.

#9 ive hit stuff with polysoup colission and it really makes my PC chug to a halt while working out whats going on... where as a simple colission box and it wasnt barely noticable atall even when hitting loads at once

#10 I've had this same issue with the cheetah when slamming into the DeathBall.

So what you're saying is no one bothered to give these items a simplier colision mesh?

I can understand not holding up the engine release to get the demos super fine tuned but mean while to people who don't understand that the demos aren't fine tuned and are looking at them to decide if they wanna buy the engine to see how it handles could be thrown off by this and may walk away towards another engine.

I figured it was the case that the demo's hadn't been fine tuned but it's nice to know I was thinking the right thing.

#11 A bit finer tuning of the wheels with my earlier hack..
Checks along the X axis instead as it has fallen on the side :)

....
..

				//	Mythic DEBUG 
				//	Damn Hax to keep em out of the terrain
				sp.zero();
				vec.zero();
				currMatrix.mulP(wheel->data->pos,&sp);

				// Move the Starting Ray Position Up by radius
				// Lets check along the X axis instead as they sink sideways :(
				// Adjust spring exstension to Zero for this
				//
				currMatrix.mulV(VectorF(-wheel->spring->length,0,0),&vec);
				sp.x += wheel->tire->radius / wheel->spring->length;

				F32 ts = wheel->tire->radius / wheel->spring->length;
				Point3F ep = sp + (vec * (1 + ts));
				ts = ts / (1+ts);
				rInfo;
				if (mContainer->castRay(sp, ep, sClientCollisionMask & ~PlayerObjectType, &rInfo)) 
				{
					wheel->surface.contact  = true;
					wheel->extension = 0;
					wheel->surface.normal   = rInfo.normal;
					wheel->surface.pos      = rInfo.point;
					wheel->surface.material = rInfo.material;
					wheel->surface.object   = rInfo.object;
				}
				else
...
..

This is just messing around with it a bit.
The real work needs to be done when checking collisions with
terrain and not letting it sink to begin with :)

#12 Your Gonna Luv this...
Forget all those changes above :)

CheetahCar.cs (Datablock for CheetahCar)
Change the Tolerances lol

Original FPS Example

...
..
   collisionTol = "0.05";        // Collision distance tolerance
   contactTol = "0.4";          // Contact velocity tolerance
...
..

Change it to:

....
..
   collisionTol = "0.1";        // Collision distance tolerance
   contactTol = "0.1";          // Contact velocity tolerance
...
..

Solved :) Will now Settle on the Top and no longer sink..

#13 sweet... now go have a beer :) then solve the fps collision issue lol

edit: I don't think the collision issue will be straight forward - don't suppose those changes fixes the fps drop?

#14 Again, you guys really should not be having that issue with collisions still. We're going to have to troubleshoot this one some in the lab to find out what's going on.

#15 @Scott - I'll provide any help/assistance/info if required.

#16 For those having the frame rate drop with collision can you guys post your system specifications, operating system, and what programs you have running in the background. Also is there a specific area in Deathball Desert that it happens more then other areas?

#17 In addition to what Chris asked for, can you provide the name of the mesh you are colliding with? If it is one you made, we need poly numbers.

#18 Mich, Scott, Chris, its not just a matter of polys or contact tol etc, it has something to do with how vehicles are set up in torque,

I dont know if its just that rigidbodies are crap when it comes to determining collision or what, but let me tell you what I did,

I have a shape, that I set up as a flyingvehicle, my dirigible, even in 1.1f it has collision problems, it will take a hit on fps if it collides with the default tree, or even lock up if it hits multiple trees.

Yet when I change my code to make that dirigible use the player code, it doesnt exhibit the same issues. Same shape, and settings in the datablock. I am not sure what it is. but it seems to be in how collision is calculated in the vehicles.

#19 @Donald - Perhaps this developer quote from Dave Wyand, who is responsible for removing the vehicle lockup problem, will be useful:

Quote:Currently, when vehicles and players update their triangle collision set, they define a collision check bounds that is larger than necessary to encompass the space they may move into. This cuts down on the number of times the triangle collision set needs to be rebuilt based on the object's motion. However, as this includes both static and dynamic objects, this collision set needs to be updated on a periodic basis so as to include any dynamic objects that have moved into the area.

The improvement here is to split out the generation of the triangle collision set between static and dynamic objects, which allows the sets to be updated according to their own rules. Static objects would retain the current method of only updating the collision set when the player/vehicle moves beyond the extra large check bounds. As most of the collision detection involves static objects (terrain, walls, trees, etc.) this can save a lot of calculations, especially if using a visible mesh for collision. The collision set for dynamic objects would be updated each tick to account their constant motion. As these objects usually have a simplified collision mesh, this gathering of dynamic collision triangles can be quite fast.

It appears that the scene masks are still in place to allow for this differentiation. Most of the work would be in maintaining the separate lists, as well as modifying the appropriate updateWorkingCollisionSet() methods.

#20 Mich, from that quote from Dave, I see what could be the issue, granted, I am not a code, so I may be off here, but the lockups and collision I have seen have been with static objects, and high rates of speed on the part of the vehicles,

And according to Dave's statement it seems that static objects (default tree?) "retains the method of updating the collision set when player/vehicles moves beyond the extra large check bounds" so is it possible that when a vehicles speed is great enough its world position is actually over running that check bounds? This would explain why everyone who has reported this issue of FPS drops or lock ups has done so and stated "when moving at high speed".

and would explain why this issue occurs with flying vehicles since they are usually set up with a higher max speed than wheeled vehicles? Its just a guess.