T3D 1.1preview-Bug, Vehicle Collision locks up program. - RESOLVED (THREED-1779)
by Donald Teal · in Torque 3D Professional · 05/01/2011 (2:09 pm) · 23 replies
Win 7 64bit,
Geforce 8600 dual SLI
T3D 1.1 preview stock FPS example
Okay here is the issue, Vehicle collision has been crap for a long time, in all versions of T3D with flying vehicle collision being worse than wheeled vehicles. But with 1.1 preview vehicle collisions have gotten worse.
It has gotten to the point where any high speed collision with any object will cause the T3D program to lock up.
To replicate, in the FPS example, modify the defaultcar.cs to give the buggy more force and less mass. this will allow it to go faster. Then get a good straigh run at the dead tree in FPS example. when it collides more often than not it will lock up T3D.
It is easier to see with a flying vehicle.
Suggested fix:
Prevent it from locking up.
Geforce 8600 dual SLI
T3D 1.1 preview stock FPS example
Okay here is the issue, Vehicle collision has been crap for a long time, in all versions of T3D with flying vehicle collision being worse than wheeled vehicles. But with 1.1 preview vehicle collisions have gotten worse.
It has gotten to the point where any high speed collision with any object will cause the T3D program to lock up.
To replicate, in the FPS example, modify the defaultcar.cs to give the buggy more force and less mass. this will allow it to go faster. Then get a good straigh run at the dead tree in FPS example. when it collides more often than not it will lock up T3D.
It is easier to see with a flying vehicle.
Suggested fix:
Prevent it from locking up.
About the author
#2
05/02/2011 (11:07 am)
Well, you did crash.... 
#4
05/04/2011 (3:36 am)
This sounds like the old friction-not-computed-properly bug rearing it's head once again. 
#6
05/04/2011 (12:15 pm)
@Donald Teal: I've been assigned to your ticket here at GarageGames. I was wondering if you could be a little more specific on your values that you've set to cause this issue. Also which force are you referring to? JetForce? Thanks.
#7
Using 1.1Preview I edit the defaultcar.cs to give the buggy like 30000 engine torque and 30000 jet force. and i drop the mass down to 150
then when i load up the project I create a new terrain and make it flat. then I edit the terrain so that there is a LONG straight stretch that slopes up. just like a jump ramp you see at daredevil shows. Then at the end of the ramp just hanging in the air i put a dead tree from the vegitation folder. that way when you get speed you fly through the air and hit the tree. then i place the buggy at the end of the track and mount the buggy and speed down the track. fly through the air and hit the tree, usually it takes a few trys to hit the tree but when you do it locks up and I have to kill the project in torsion.
Now if you have a flying vehicle its easier to see all you have to do is fly with the slightest of speed and collide with anything and you will get a lock up
That enough detail? :P
05/04/2011 (4:48 pm)
Okay Chris, its much easier to see with a flying vehicle but let me explain what i do to get it to happen with the default buggy.Using 1.1Preview I edit the defaultcar.cs to give the buggy like 30000 engine torque and 30000 jet force. and i drop the mass down to 150
then when i load up the project I create a new terrain and make it flat. then I edit the terrain so that there is a LONG straight stretch that slopes up. just like a jump ramp you see at daredevil shows. Then at the end of the ramp just hanging in the air i put a dead tree from the vegitation folder. that way when you get speed you fly through the air and hit the tree. then i place the buggy at the end of the track and mount the buggy and speed down the track. fly through the air and hit the tree, usually it takes a few trys to hit the tree but when you do it locks up and I have to kill the project in torsion.
Now if you have a flying vehicle its easier to see all you have to do is fly with the slightest of speed and collide with anything and you will get a lock up
That enough detail? :P
#8
05/05/2011 (10:16 am)
@Donald Teal: Thank you for providing me with the additional detail that I've requested. Unfortunately I was not able to reproduce the issue that you are having with our current build. Would you mind sending me the level in question for further testing? My email is Chris@garagegames.com. Thank you for your patients. 
#9
or drive into 2 other cars..
or drive into anything that uses a collision mesh...
05/05/2011 (1:12 pm)
make a cliff, set the default car speed to double, half the weight, drive fast off the cliff....or drive into 2 other cars..
or drive into anything that uses a collision mesh...
#10
05/05/2011 (3:58 pm)
@Donald Teal: I was able to reproduce the issue only after adding additional values to the datablock.
#11
make a cliff, set the default car speed to double, half the weight, drive fast off the cliff....
or drive into 2 other cars..
or drive into anything that uses a collision mesh...
??
05/05/2011 (4:25 pm)
did youmake a cliff, set the default car speed to double, half the weight, drive fast off the cliff....
or drive into 2 other cars..
or drive into anything that uses a collision mesh...
??
#12
05/05/2011 (4:48 pm)
@Deepscratch: I was only able to reproduce your above steps by editing MaxWheelSpeed value as well.
#13
and the other steps I recomended?
did you
make a cliff, set the default car speed to double, half the weight, drive fast off the cliff....
or drive into 2 other cars..
or drive into anything that uses a collision mesh...
as well?
05/05/2011 (5:23 pm)
so you set the default car speed to double,and the other steps I recomended?
did you
make a cliff, set the default car speed to double, half the weight, drive fast off the cliff....
or drive into 2 other cars..
or drive into anything that uses a collision mesh...
as well?
#14
were you able to reproduce the lock up? the Level itself doesnt matter. But yes you can get it to occur if you edit other parameters in the datablock. SOme combinations of parameters cause it to happen more than others. I havent tried to keep track of which does what cause I have been focused on flyingvehicles instead of wheeled and only tested the buggy cause I was getting fustrated with the lock ups and wanted to see if it happened with wheeled vehicles too. I will admit it does not occur often with wheeled vehicles. but with FLYing vehicles it happens all the time
05/05/2011 (5:26 pm)
@Chris. were you able to reproduce the lock up? the Level itself doesnt matter. But yes you can get it to occur if you edit other parameters in the datablock. SOme combinations of parameters cause it to happen more than others. I havent tried to keep track of which does what cause I have been focused on flyingvehicles instead of wheeled and only tested the buggy cause I was getting fustrated with the lock ups and wanted to see if it happened with wheeled vehicles too. I will admit it does not occur often with wheeled vehicles. but with FLYing vehicles it happens all the time
#15
The ticket has been confirmed and passed on for scheduling.
05/05/2011 (5:35 pm)
Guys, Chris already said he reproduced it and did so using the the extra steps that have been suggested. He just had to go an extra step further which would be due to the difference between the Preview and the current codebase.The ticket has been confirmed and passed on for scheduling.
#18
05/26/2011 (9:59 am)
Fixed in 1.1 Final. 
#19
06/04/2011 (2:28 pm)
Out of curiosity, how was this fixed? It has been a thorn in my side with every version of Torque I've ever used.
#20
One was the fact that the Player's working collision set was still being updated while mounted. This resulted in wasted cycles as the Player's collision doesn't need to be updated while mounted.
The other, and chief culprit, was that Vehicle::updateWorkingCollisionSet() was spending a lot of time in TSMesh::buildConvexOpcode(). So when the vehicle would collide against a TSStatic with visible mesh collision that had a couple thousand polys, like the default tree, it would sit and spin while it tried to update the collision set against everything. Now it acts more like the Player's collision so that it breaks out faster. It makes it a little less accurate, but it greatly cuts down the TSMesh calls so that it's performant again.
Dave also added a couple new script variables to help tune vehicles a bit more, his comments from the log follow:
Added a tunable parameter to Vehicle to force an update to the working collision list after a number of ticks have elapsed -- $vehicle::workingQueryBoxStaleThreshold. As wheeled vehicles collide with players and other vehicles, it is possible that another moving vehicle could enter the working collision query box while we are moving but we have not updated the working list to discover this. This parameter allows the system to check for this case at the expense of running more triangle queries. Fast moving vehicles are more susceptible to this as their working query box can be quite large (the extent is scaled based on linear velocity). Set this parameter to -1 to disable this timed check. The default is 10 ticks.
Added a tunable parameter to modify the multiplier used to generate the working query box from the convex box -- $vehicle::workingQueryBoxSizeMultiplier. The larger the multiplier, the less often a new working query list will be generated based on the vehicle's motion. The default is 2 (the same as Player)
06/04/2011 (8:58 pm)
It hits a lot of files so I won't bother posting the specifics of it right now, but here's the short version. Basically it came down to a couple things. One was the fact that the Player's working collision set was still being updated while mounted. This resulted in wasted cycles as the Player's collision doesn't need to be updated while mounted.
The other, and chief culprit, was that Vehicle::updateWorkingCollisionSet() was spending a lot of time in TSMesh::buildConvexOpcode(). So when the vehicle would collide against a TSStatic with visible mesh collision that had a couple thousand polys, like the default tree, it would sit and spin while it tried to update the collision set against everything. Now it acts more like the Player's collision so that it breaks out faster. It makes it a little less accurate, but it greatly cuts down the TSMesh calls so that it's performant again.
Dave also added a couple new script variables to help tune vehicles a bit more, his comments from the log follow:
Added a tunable parameter to Vehicle to force an update to the working collision list after a number of ticks have elapsed -- $vehicle::workingQueryBoxStaleThreshold. As wheeled vehicles collide with players and other vehicles, it is possible that another moving vehicle could enter the working collision query box while we are moving but we have not updated the working list to discover this. This parameter allows the system to check for this case at the expense of running more triangle queries. Fast moving vehicles are more susceptible to this as their working query box can be quite large (the extent is scaled based on linear velocity). Set this parameter to -1 to disable this timed check. The default is 10 ticks.
Added a tunable parameter to modify the multiplier used to generate the working query box from the convex box -- $vehicle::workingQueryBoxSizeMultiplier. The larger the multiplier, the less often a new working query list will be generated based on the vehicle's motion. The default is 2 (the same as Player)
Associate David Montgomery-Blake
David MontgomeryBlake