Serious vehicle collision problems
by John Vanderbeck · in Torque Game Engine · 10/26/2003 (6:20 am) · 18 replies
I have modified Bravetree's Jetbike to be a hover vehicle, but i'm having some nasty collision problems at high speed.
At low speeds, everythign works fine (though hard to control ATM), and the hover craft properly aligns itself with the terrain normals. However, when I ramp up the speed and start jettig around complex terrain, inevitably I end up flying right THROUGH a steep slope of land and end up under the terrain. This seems to happen most when moving either over water or flat land then runnign into steep terrain.
Any suggestions or ideas on how to solve this? This is going to be a serious problem for us down the road. Seems to be an SDK bug, but i'm not going to jump to conclusions.
At low speeds, everythign works fine (though hard to control ATM), and the hover craft properly aligns itself with the terrain normals. However, when I ramp up the speed and start jettig around complex terrain, inevitably I end up flying right THROUGH a steep slope of land and end up under the terrain. This seems to happen most when moving either over water or flat land then runnign into steep terrain.
Any suggestions or ideas on how to solve this? This is going to be a serious problem for us down the road. Seems to be an SDK bug, but i'm not going to jump to conclusions.
#2
10/26/2003 (6:25 am)
Never played T2, but our game calls for high velocity vehicles..hmm.. this could be a problem.
#3
10/26/2003 (7:02 am)
All the vehicles seem to have collision problems. Flyers also go through the terrain and rarely seem to detect dts.
#4
10/26/2003 (7:39 am)
So then this would be classified as a bug? Is it a known bug? Is it being fixed? This is kind of a major thing.
#5
10/26/2003 (7:54 am)
It's not classified as a bug nor being worked on, It's kinda a 'feature' of torque and there are no plans (at least not for now) to change the way collision is handled, of course if your game needs it you could go ahead and fix it and then send it back to GG as a patch.
#6
10/26/2003 (7:57 am)
I'll have to see what I can do then. I'm not familiar enough with Torque right now to fix it though. Oh well. Bummer.
#7
I never tried to fix it, but I don't think it would be easy at all. But eventually, I'll have to see what I can do, at least with wheeled vehicles.
10/26/2003 (8:55 am)
@John: Yeah, i know, it's a hard task :\I never tried to fix it, but I don't think it would be easy at all. But eventually, I'll have to see what I can do, at least with wheeled vehicles.
#8
Also, most flips of the car seem to get it stuck half in and half out of the terrain. Since I'm not using the vehicle logic in my game, it hasn't been a big concern. I only mention all of this in case you want to try and duplicate it.
Also, keep in mind that Torque has the recorder logic built in. The FPS demo lets you save a recording and play it back. If you want, try hooking that into the racing mod and then you can at least reproduce the bug and start looking for answers.
-Nerseus
10/26/2003 (10:00 pm)
I think I saw another post where someone had a similar problem only not going as fast. I can duplicate it fairly easily using the race mode in TorqueDemo by going downhill and aiming for a dent in the landscape. By dent I mean a place where the landscape is going mostly downhill, then levels out a bit and then slopes back down. At the edge where it turns from a slope to leveling out, aim the nose of the car there and you can usually go right through.Also, most flips of the car seem to get it stuck half in and half out of the terrain. Since I'm not using the vehicle logic in my game, it hasn't been a big concern. I only mention all of this in case you want to try and duplicate it.
Also, keep in mind that Torque has the recorder logic built in. The FPS demo lets you save a recording and play it back. If you want, try hooking that into the racing mod and then you can at least reproduce the bug and start looking for answers.
-Nerseus
#9
10/27/2003 (2:04 am)
Id assume this problem is due to the fact that if, in between frames, you are going fast enough that the collision mesh moves all the way (or even part way) through the terrain in the span of a single frame (ie before the colision detection can find out). The only way I can see to fix it is to either increase the number of collision checks or something. This is all just what I assume, ive never actualyl looked into torques collision code before.
#10
10/27/2003 (2:48 am)
Are you sure you have integration defined in your datablock? If not... well then you'll have serious collision problems indeed.
#11
10/27/2003 (4:45 am)
Umm ... I'm still learning torque so I can't be positive if I do or not. How do you define integration?
#12
Added "intergration=4" and it works!
10/27/2003 (4:54 am)
Gah..A whole day of trying to make this work and it was somethign this simple. Guess everyone assumed I did.Added "intergration=4" and it works!
#13
What would happen if you up the integration to over 4 though? like 6 or even 10.. I guess it would make the cpu impact bigger, but also safer collision checks.
10/27/2003 (6:51 am)
Hehehehe. Well even with integration sometimes you will still be able to get through, but it's less probable with that setting. The engine defaults integration to 1 when not set, maybe it would be a good idea to change that default. What would happen if you up the integration to over 4 though? like 6 or even 10.. I guess it would make the cpu impact bigger, but also safer collision checks.
#14
One thing i've discovered through is hovers really work best on smoother rolling terrain, and less so on sharp terrain like in the Stronghold mission. The sharp angles tend to make it bounce around too much.
But at least, so far, i'm not fallign through terrain anymore which is a big step forward. My only question would be what is the CPU impact of having a bunch of vehicles runnign around with higehr than default integration settings.
10/27/2003 (7:22 am)
Well so far with a settign of 4 i'm not falling through terrain. I'm occosionally having the controls go wild though, but i'm still tweaking the physics.One thing i've discovered through is hovers really work best on smoother rolling terrain, and less so on sharp terrain like in the Stronghold mission. The sharp angles tend to make it bounce around too much.
But at least, so far, i'm not fallign through terrain anymore which is a big step forward. My only question would be what is the CPU impact of having a bunch of vehicles runnign around with higehr than default integration settings.
#15
Basically, go back to rev 1.1.2 and that will remedy the problem you're having. (Assuming you're on a newer branch.)
The trade-off (there's always a catch) is that occasionally, your player entity will get stuck during hard collisions with an "odd" trajectory.
Haven't found a way around that yet. ;)
10/27/2003 (7:40 am)
Ran into this a while back myself - being that I'm working with high speed hover's too.Basically, go back to rev 1.1.2 and that will remedy the problem you're having. (Assuming you're on a newer branch.)
The trade-off (there's always a catch) is that occasionally, your player entity will get stuck during hard collisions with an "odd" trajectory.
Haven't found a way around that yet. ;)
#16
In general vehicle collisions where highly improved in the latest changes.
10/27/2003 (5:52 pm)
@Kirby: I think that it didnt work for you in newer versions because you weren't setting the integration value either, since that's new code.In general vehicle collisions where highly improved in the latest changes.
#17
I solved this problem by doing a number of castRay's from some points on the bike from the last tick to the current tick. Like from the front of the vehicle at the last tick to the front of the vehicle at this tick. It's difficult to simulate a good collision response with this method (I'm still working on it) but you could put in a check like this after the normal collision check as a "late-out" to make sure that you caught everything. Then you could possibly loop back and do the collision check again with a higher integration value.
I just thought of this, but a good solution might be to do the normal collision check like it is now and if that check doesn't catch anything do some bounding box point castRay's (or an extruded box check) like I said above, and integrate this as well, and if that catches a collision then double the integration value and redo the collision check at that level. You could loop this until the proper integration value for the situation is reached. It's possible that this might loop around a bunch of times and really slow down the simulation but you should be able tweak it and/or cap the looping for your particular situation.
10/31/2003 (6:08 pm)
I ran into this same problem when I was first working on the GravRally bike code. Afaik, the issue is exactly like Dylan said. As I understand it integrating the collision will step through the motion through the frame. For 4 it will check at 1/4, 2/4, 3/4, and 4/4 delta between the frames. So the higher the speed the higher the integration value you will need in order to catch everything at high speeds. I solved this problem by doing a number of castRay's from some points on the bike from the last tick to the current tick. Like from the front of the vehicle at the last tick to the front of the vehicle at this tick. It's difficult to simulate a good collision response with this method (I'm still working on it) but you could put in a check like this after the normal collision check as a "late-out" to make sure that you caught everything. Then you could possibly loop back and do the collision check again with a higher integration value.
I just thought of this, but a good solution might be to do the normal collision check like it is now and if that check doesn't catch anything do some bounding box point castRay's (or an extruded box check) like I said above, and integrate this as well, and if that catches a collision then double the integration value and redo the collision check at that level. You could loop this until the proper integration value for the situation is reached. It's possible that this might loop around a bunch of times and really slow down the simulation but you should be able tweak it and/or cap the looping for your particular situation.
#18
Let's say you have a box (your bounding box), Now take the bottom square on the box, where Y is the forward vector and X is the sideways vector.
For ease of understanding, draw a rectangle real fast, longer in the Y direction like a bike would be (this could be thought of as top view).
Where the X's are, is where he draws a ray down, to collide with the terrain, and from that intersection he calculates the required normal so that your base is parallel with the ground, and based upon this normal, he calculates the amount of torque required to rotate the object.
So, what I've just done is given you a really long explination of this:
If you move too fast and your bounding box runs through the terrain, then you cant cast the ray down, and you dont rotate to follow the terrain.
11/03/2003 (2:02 pm)
You need to understand how Tim wrote the code for the alignment with the terrain.Let's say you have a box (your bounding box), Now take the bottom square on the box, where Y is the forward vector and X is the sideways vector.
For ease of understanding, draw a rectangle real fast, longer in the Y direction like a bike would be (this could be thought of as top view).
+---X---+ | | | | | | | | | | | | +---X---+
Where the X's are, is where he draws a ray down, to collide with the terrain, and from that intersection he calculates the required normal so that your base is parallel with the ground, and based upon this normal, he calculates the amount of torque required to rotate the object.
So, what I've just done is given you a really long explination of this:
If you move too fast and your bounding box runs through the terrain, then you cant cast the ray down, and you dont rotate to follow the terrain.
Torque Owner Chris