Has anyone fixed vehicle-vehicle collisions?
by Sam Redfern · in Torque Game Engine · 10/25/2005 (12:05 pm) · 10 replies
I have spent quite a bit of time hacking the vehicle collision-resolution code in order to get collisions between vehilces working reasonably (do a quick search and you'll see this is not a new problem!)
I was wondering whether anyone has fixed this issue to their satisfaction?
In a nutshell:
The collision method for 2 rigid bodies is commented out in current TGE, since it frequently leads to an infinite loop in the resolveCollision method. As it stands, the collider vehicle acts like it hit a brick wall, and the other (collidee?) vehicle acts like nothing has happened. Even with this approach, the code frequently gives crazy results since it can take several iterations to resolve a collision, with forces simply adding up.
My own hacks have tried various things. At the moment I'm exiting the resolveCollision method after a number of iterations, and also forcing both vehicles to not accelerate by more than 5m/s following a collision. And various other bits & pieces...
Has anyone else done something better than this? -- it's hard to believe you're all living with the current mess that is Vehicle::resolveCollision?
thanks
Sam.
EDIT: oh yeah, some other things my hacks do:
* I have variable integration rates so that faster-moving vehicles get more detailed simulation (some of the problems manifest themselves at higher speeds because of coarse integration)
* When the iterative collision-solver fails, the vehicle rewinds to its pre-collision position, and the missing timestep is made up at the end of the current tick.
I was wondering whether anyone has fixed this issue to their satisfaction?
In a nutshell:
The collision method for 2 rigid bodies is commented out in current TGE, since it frequently leads to an infinite loop in the resolveCollision method. As it stands, the collider vehicle acts like it hit a brick wall, and the other (collidee?) vehicle acts like nothing has happened. Even with this approach, the code frequently gives crazy results since it can take several iterations to resolve a collision, with forces simply adding up.
My own hacks have tried various things. At the moment I'm exiting the resolveCollision method after a number of iterations, and also forcing both vehicles to not accelerate by more than 5m/s following a collision. And various other bits & pieces...
Has anyone else done something better than this? -- it's hard to believe you're all living with the current mess that is Vehicle::resolveCollision?
thanks
Sam.
EDIT: oh yeah, some other things my hacks do:
* I have variable integration rates so that faster-moving vehicles get more detailed simulation (some of the problems manifest themselves at higher speeds because of coarse integration)
* When the iterative collision-solver fails, the vehicle rewinds to its pre-collision position, and the missing timestep is made up at the end of the current tick.
About the author
#2
Yes, that's something I tried a while ago. But I found the impulses were very unpredictable since it seems to take a varying number of collision iterations to actually satisfy the engine that the vehicles are no longer colliding. Do you find this a problem?
10/25/2005 (12:25 pm)
Brian,Yes, that's something I tried a while ago. But I found the impulses were very unpredictable since it seems to take a varying number of collision iterations to actually satisfy the engine that the vehicles are no longer colliding. Do you find this a problem?
#3
10/25/2005 (9:06 pm)
The Zap source code has an interesting solution involving partial ticks. 
#4
10/25/2005 (10:10 pm)
Where can one find the Zap source code? CVS? where's CVS again? nevermind found it. 
#5
10/26/2005 (1:25 am)
Thomas, and where did you find it? Always type your solution. 
#6
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=8867
10/26/2005 (3:53 am)
Akio has enhanced collisions that make vehicle to vehicle collisions great, as well as the physics overall, and when you run into dynamic shapes. www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=8867
#7
We are experiencing a big problem tough, its actually a huge problem. If we can't get past it, then we might as well stop development. Its described here: www.garagegames.com/blogs/2137/8550
And yeh, i saw Akio's .plan, but no source, so its nice to see someone is doing some nice things, but it doesn't help us.
10/26/2005 (4:37 am)
For the game I'm currently working on i used an impulse based collision system. I made the script so there's only 1 impulse (even tough the engine executes multiple oncollision callbacks),and it works alright.We are experiencing a big problem tough, its actually a huge problem. If we can't get past it, then we might as well stop development. Its described here: www.garagegames.com/blogs/2137/8550
And yeh, i saw Akio's .plan, but no source, so its nice to see someone is doing some nice things, but it doesn't help us.
#8
The problem you describe may just be something I have dealt with myself.
My game is not realtime: every 30 seconds or so, time runs forwards 1 second and then stops again. This means I *really* notice situations where the client and server don't agree on things, because I clearly see the warping applied to vehicles that should otherwise be stationery.
Anyway... it turns out the order in which objects are simulated is critical to the exact sequence of collisions, etc. Yet the client and server tend to have the objects ordered in reverse to each other. This often leads to them disagreeing, and therefore the simulation done by the client getting over-ridden and warping (your juddering) happening. What I have done is added linking information to the vehicles, i.e. so that they know the correct order in which they should be simulated. There is a function then for re-ordering the list of objects for simulation so that the client order and server order agree.
Then again, this might not be the cause of your trouble!
I'll dig out the code if you like...
10/26/2005 (6:20 am)
Ward:The problem you describe may just be something I have dealt with myself.
My game is not realtime: every 30 seconds or so, time runs forwards 1 second and then stops again. This means I *really* notice situations where the client and server don't agree on things, because I clearly see the warping applied to vehicles that should otherwise be stationery.
Anyway... it turns out the order in which objects are simulated is critical to the exact sequence of collisions, etc. Yet the client and server tend to have the objects ordered in reverse to each other. This often leads to them disagreeing, and therefore the simulation done by the client getting over-ridden and warping (your juddering) happening. What I have done is added linking information to the vehicles, i.e. so that they know the correct order in which they should be simulated. There is a function then for re-ordering the list of objects for simulation so that the client order and server order agree.
Then again, this might not be the cause of your trouble!
I'll dig out the code if you like...
#9
10/26/2005 (3:28 pm)
Yeh, if you want to share.... i'd love to try it out and see if it helps.
#10
10/26/2005 (5:26 pm)
I meant I found CVS :) i'm still a noob. 
Torque Owner Brian Richardson
It's a hack but it allowed me to move on with prototyping. I would get huge CPU stalls when 4 or 5 vehicles ran into each other, but with this hack, things just keep moving because I'm avoiding the bad case.