Vehicle -> Vehicle Collision
by Luke Lamothe · in Torque Game Engine · 05/28/2007 (2:27 am) · 7 replies
Ok, after countless hours of code tweaks, we have our racing game performing pretty good vehicle-to-vehicle collision reactions (don't worry, I'll get around to posting a completely separate resource on what worked for us once our deadlines are done!!!). There are a few more hacks... I mean "tweaks" that I need to do, then they should be good enough to ship.
However, there is one thing that I have found really effects collision between vehicles, and that is the whole client/server warping logic and I was wondering if anyone here (Torque employee or otherwise) would have an idea on how to address this "bug".
The issue is pretty simple in that if inside of vehicle.cc I set "sMaxWarpTicks = 0", our collisions between vehicles are fantastic in 95% of the cases (high speeds, head/on, etc.). *IF* however, sMaxWarpTicks is anything OTHER than 0, (which causes clients to interpolate over time to their proper server based position), we start to get horrible collision between the vehicles, and the larger that sMaxWarpTicks is, the worse the detection is. I'm pretty sure that it is related somewhat to the code inside of Vehicle::processTick() that goes:
It seems to be that if the clients are busy merely warping over time to their server positions, that collision detection with them goes wacky, possibly due to the lack of client-side collision detection while the warping is occuring? I've also noted that the speed of the vehicles while warping directly affects the collision. In other words, if one vehicle is standing still, I can ram into it at any speed (ie. > 600km/h) and the collision is perfect. However, as soon as the other vehicle starts to move, the collisions get more and more inaccurate as the other vehicle increases it's speed (ie. it has to 'warp' more to catch up to the server). It's almost like the convex or bbox of the other vehicle doesn't warp properly along with it or something...
I'm pretty much stuck on this one, so if anyone has any help or has experienced anything like this, I would really appreciate your feedback. Perhaps I'm the only one with this issue and it has been caused by the many many many many many other tweaks that I've done with Torque's standard collision detection/reaction in order to get it working more reliably?
It does seem weird though that it only wants to get bad with me when the warping interpolation is occuring though...
Thanks :)
However, there is one thing that I have found really effects collision between vehicles, and that is the whole client/server warping logic and I was wondering if anyone here (Torque employee or otherwise) would have an idea on how to address this "bug".
The issue is pretty simple in that if inside of vehicle.cc I set "sMaxWarpTicks = 0", our collisions between vehicles are fantastic in 95% of the cases (high speeds, head/on, etc.). *IF* however, sMaxWarpTicks is anything OTHER than 0, (which causes clients to interpolate over time to their proper server based position), we start to get horrible collision between the vehicles, and the larger that sMaxWarpTicks is, the worse the detection is. I'm pretty sure that it is related somewhat to the code inside of Vehicle::processTick() that goes:
// Warp to catch up to server
if(mDelta.warpCount < mDelta.warpTicks)
{
//do warping stuff
}
else
{
//do prediction instead (including client-side integration and collision detection)
}It seems to be that if the clients are busy merely warping over time to their server positions, that collision detection with them goes wacky, possibly due to the lack of client-side collision detection while the warping is occuring? I've also noted that the speed of the vehicles while warping directly affects the collision. In other words, if one vehicle is standing still, I can ram into it at any speed (ie. > 600km/h) and the collision is perfect. However, as soon as the other vehicle starts to move, the collisions get more and more inaccurate as the other vehicle increases it's speed (ie. it has to 'warp' more to catch up to the server). It's almost like the convex or bbox of the other vehicle doesn't warp properly along with it or something...
I'm pretty much stuck on this one, so if anyone has any help or has experienced anything like this, I would really appreciate your feedback. Perhaps I'm the only one with this issue and it has been caused by the many many many many many other tweaks that I've done with Torque's standard collision detection/reaction in order to get it working more reliably?
It does seem weird though that it only wants to get bad with me when the warping interpolation is occuring though...
Thanks :)
#2
The multiple definitions of sMinWarpTicks are so that they can be set differently based on what type of object is being updated between client and server, I would assume. I only care about vehicles at the moment as that is all that we are using :)
It's interesting that you note that you seem to get caught on things more without the interpolation taking place...
FYI, I also have a limiter on my iterative collision solving (50), and I've broken up my collision solving into 2 separate iterative loops (first pass is for dynamic objects, second is for static objects).
Thanks for your feedback :)
05/28/2007 (3:40 am)
Yes, your "hoppings" (the warping to the server position) will be more pronounced (especially when you are running at lower framerates or have bad bandwith) as there will be no client-side interpolation towards the vehicle's server specified position (ie. it will just pop there instantaneously).The multiple definitions of sMinWarpTicks are so that they can be set differently based on what type of object is being updated between client and server, I would assume. I only care about vehicles at the moment as that is all that we are using :)
It's interesting that you note that you seem to get caught on things more without the interpolation taking place...
FYI, I also have a limiter on my iterative collision solving (50), and I've broken up my collision solving into 2 separate iterative loops (first pass is for dynamic objects, second is for static objects).
Thanks for your feedback :)
#3
Nice...
05/30/2007 (2:55 am)
So can I assume that that nobody, GG staff included, knows/can fathom why the client interpolation casues collision detection/reaction to effectively not work at all?Nice...
#4
how'd we get from:
to
as to further looking into sMaxWarpTicks...
I should think that predictions in a server to client communication function would be definative, not more extrapolations... or mebbey I'm reading that totally wrong...
edit: yeah... F32 len = (mRigid.linVelocity.len() + 100 /*50*/) * TickSec; //20ms+30ms + 10ms == 50?0o
really does seem to have made quite a diference there... just went through 5 rounds with dumbed-down bots, and ramming the things at low speed, and high speed seems to work fine...
05/30/2007 (3:45 am)
Aaaactually... dunno if this is related, so much as also oddball...how'd we get from:
void Vehicle::updateWorkingCollisionSet(const U32 mask)
{
// First, we need to adjust our velocity for possible acceleration. It is assumed
// that we will never accelerate more than 20 m/s for gravity, plus 30 m/s for
// jetting, and an equivalent 10 m/s for vehicle accel. We also assume that our
// working list is updated on a Tick basis, which means we only expand our box by
// the possible movement in that tick, plus some extra for caching purposesto
F32 len = (mRigid.linVelocity.len() + 50) * TickSec; //20ms+30ms + 10ms == 50?0o
as to further looking into sMaxWarpTicks...
void Vehicle::unpackUpdate(NetConnection *con, BitStream *stream)
{
...
// Cal how many ticks it will take to cover the warp offset.
// If it's less than what's left in the current tick, we'll just
// warp in the remaining time.
if (!as || (dt = mDelta.warpOffset.len() / as) > sMaxWarpTicks)
dt = mDelta.dt + sMaxWarpTicks;
else
dt = (dt <= mDelta.dt)? mDelta.dt : mCeil(dt - mDelta.dt) + mDelta.dt;
}I should think that predictions in a server to client communication function would be definative, not more extrapolations... or mebbey I'm reading that totally wrong...
edit: yeah... F32 len = (mRigid.linVelocity.len() + 100 /*50*/) * TickSec; //20ms+30ms + 10ms == 50?0o
really does seem to have made quite a diference there... just went through 5 rounds with dumbed-down bots, and ramming the things at low speed, and high speed seems to work fine...
#5
As for the sMaxWarpTicks, the problem seems not to be about client-side prediction per say, but with the interpolation used when the client needs to catch up to the server when the server sends out a new position for it. My "theory" at this point in time is that when the interpolation catch-up is occuring, the client doesn't perform any collision detection for that object, which causes very weird results visually.
But I am probably totally wrong in this regard, or am not realising something obvious about the situtaion, which is why I would like someone with experience in this system (GG staff or otherwise) to talk about what the cause may be, and throw around some ideas for a solution as I am really just going off of assumptions made from 5 months of Torque 1.5 usage :)
05/30/2007 (5:55 am)
Thanks for you findings on upping the bbox size. I've played with that in the past and found that it didn't really do anything different on my side, but that was before I fixed other issues with the collisions, so I'll play with it again and maybe it will help with something :)As for the sMaxWarpTicks, the problem seems not to be about client-side prediction per say, but with the interpolation used when the client needs to catch up to the server when the server sends out a new position for it. My "theory" at this point in time is that when the interpolation catch-up is occuring, the client doesn't perform any collision detection for that object, which causes very weird results visually.
But I am probably totally wrong in this regard, or am not realising something obvious about the situtaion, which is why I would like someone with experience in this system (GG staff or otherwise) to talk about what the cause may be, and throw around some ideas for a solution as I am really just going off of assumptions made from 5 months of Torque 1.5 usage :)
#6
05/30/2007 (7:04 am)
Dunno. might have been more obvious this end due to the 300 kph/ 186 mph relative velocities of these puppies... I presume your end's using more realistic speeds?
#7
Most of these issues we can live with at the moment, but the larger problem for us is the issue of having the client-side interpolation totally messing up collisions. If push comes to shove, we will leave it out in order to have better collision detection/response, but the jumping around of AI vehicles, as well as network players when the frame rate is low (only really due to running on low-end machines, but it still does happen) is something that we would like to avoid having to ship with.
05/30/2007 (7:14 am)
Nope... we've got vehicles hitting each other head-on at 600+ kph and things are ok 95% of the time, as long as the sMaxWarpTicks is set to 0 (ie. no client-side interpolation to the server position). The only issues are when you collide with very thin/pointy DIF collision (ie. < 0.25m wide, etc.) or when the relative velocity between vehicles is low, but the actual velocity of the vehicles is high (ie. slight rear-endig when travelling at high speeds).Most of these issues we can live with at the moment, but the larger problem for us is the issue of having the client-side interpolation totally messing up collisions. If push comes to shove, we will leave it out in order to have better collision detection/response, but the jumping around of AI vehicles, as well as network players when the frame rate is low (only really due to running on low-end machines, but it still does happen) is something that we would like to avoid having to ship with.
Torque Owner Kirk Longendyke
a- the hoppings more pronunced
b- you catch on things more (can't speak for the bots just yet, they're doing their typical botish things, aside from the hop)
c- theres actually, 3 definitions for that: in item, player, and vehicle, and both item and player have a sMinWarpTicks... interesting...
After a few more reviews, I will note, that there did still seem to be some passthrough, but I've also recently added a 64 itteration limiter to the resolvecollisions to prevent lockups, as well as a 40.0f cap on linear velocities to try and pull and end-run arround that.. what was it they called it... 'off to pluto' bug?