Collision detection

[mattlikespeoples]

So i was racing around a tight autoX course and i just realized how much this annoyed me. I'd clip a big red barrier, sink in a bit and then shoot off in the other direction when i should've hit it and ricocheted off, not sling shotted in the wrong direction. This also affects racing sometimes but i think thats more lag. I can understand that things like collision detection is hard to program for but most other racing games dont seem to do this sling shot thing at all. any thoughts?

[(NOZ)RockyZ]

THis is very annoying. It makes contact in LFS very unrealistic, in close racing in city tracks liek SO there is ALWAYS contact.

In LFS a contact that was just a small scrape could cause 2 cars to fly couple hundred feet into the air while IRL the car would have just hit each other and kept on going. This results in bad starts and causes racing expirience to be bad just because a person accidentally scraped a little bit of the front person's rear bumper. I think lag is one of the most serious problem but it isn't the only problem, there are a few bugs and it woudl be very good if the LFS team worked on that before anything else less important.

[XCNuse]

its just an incomplete collision system thats all, some objects act as rubber objects by absorbing mass and momentum and act as a single vertex and fling the car somewhere with tremendous force

.. which needs work, yes we all know.. not to much of a bug when everyone knows about it ;)

[Bob Smith]

Also, the car moves every 1/2000th of a second, but collision checking only happens every 1/100th (because it's CPU intensive). So the collision code should really allow for this somehow.

[Roadie]

i think almost everyone could handle it updating at 1/2000th of a second... LFS only uses like 55% of my cpu when i Run it..

[Lible]

NOOO! My cpu is 100 and never less when i run LFS :shrug: My computer should be in museum.

[mattlikespeoples]

i think what bob said would be feasable. just allow for some tollerences to be accounted for when a collision occurs. not being a programmer i would have no idea where to start but i dont think we ned every 1/2000th of a sec updating for collision. that would make LFS much less accesable to everyone unless they had a high end pc

[M.Mos]

Only the cars are only updated 3-6 times per sec. , that isn't much or?
Is their a way to increase online car updates?

[the_angry_angel]

Only the cars are only updated 3-6 times per sec.Thats PPS (Packets Per Second), which does not relate to physics steps. Each client runs its own physics steps, if they do not match the servers final outcome (per packet from the server), then the client is forced to alter its game state. By doing this you can run games over the net at a reasonable speed, but of course when you get slow machines or slow net connections you can get "snapping" of cars.

I believe Bob isnt 100% correct in his explanation (Scawen, or anyone who knows better feel free to correct me); The main game loop runs at 100Hz (100 times per second). In this loop boundary box sanity checking occurs. However, there is a internal loop, which runs at approximately 2MHz (if I remember correctly). This inner loop moves the car and samples things like tyres, etc.

i think almost everyone could handle it updating at 1/2000th of a second... LFS only uses like 55% of my cpu when i Run it..As said, increasing this to every 1/2000th of a second would certainly kill most machines, including yours. Why almost exponentially decrease the potential market of LFS, for the sake of stopping the rubber object syndrome?

[XCNuse]

either way.. i have a good replay of proof of how far ahead of time the damage works.. i have a replay of me running into a car stopped on WE after he spun out and i was on outside of turn and he spun into me path.. and about a quarter of a second before i hit him, my nose gets all crushed up

[the_angry_angel]

Thats very interesting XCNuse, could you possibly post this? Was it online?

It might change the way we think LFS runs. Either that or we could contribute it down to a lag, and then a tiny client snap.

[Bob Smith]

I believe Bob isnt 100% correct in his explanation (Scawen, or anyone who knows better feel free to correct me); The main game loop runs at 100Hz (100 times per second). In this loop boundary box sanity checking occurs. However, there is a internal loop, which runs at approximately 2MHz (if I remember correctly). This inner loop moves the car and samples things like tyres, etc.
Isn't that what I said? And it's k for thousands ;)

[the_angry_angel]

:doh: Didnt read your post properly :( Sorry Bob! :)

And yes, you're right. It should be KHz :p

[bbman]

either way.. i have a good replay of proof of how far ahead of time the damage works.. i have a replay of me running into a car stopped on WE after he spun out and i was on outside of turn and he spun into me path.. and about a quarter of a second before i hit him, my nose gets all crushed up
I saw something like this too, but I thought it would be just my imagination... I drove XFR on SO Long (somebody said it is scary and I had just to check it out... :D) and crashed into a wall pretty bad... When I watched this crash on the replay, it was as if parts of the car backed off to avoid hitting the wall (did it anyways, but looks funny: "Car scared by wall" :D)

[Hyperactive]

To XCNuse:

Isn't that what always happens when your car hits something? Check some of your replays and watch one hit in slow motion 0.250x to see that the damage is always slightly before the actual touch.

---
I am not a programmer myself either. It is hard to find the reason why sometimes a little touch can get so forceful (spelling...). As someone explained earlier the cars and other object in game move every 1/2000 seconds (?) and collision detection happens every 1/100 seconds. And in online races cars get updated 3-6 times per second, though this has nothing to do with this? (because these can can happen offline too and always with some objects, like the concrete road blocks)

So two cars side-by-side can get inside each other cars' in a 1/100 second and then the collision detection notices it and creates the force to simulate the touch between the cars. As an outcome the player feels the force :)

If the collision detection engine works how I think it does: It watches over the objects in the game and when too objects slightly cut each other's outlines the collision detection gives the phys-engine some data that there is a force between these two objects, the greater the cut in the greater the force.

But could it be that the damage-detection engine (...) can't handle sharp edges in collisions? Maybe the sharp edges can get a little deeper in other object before the collision detection notices it? And then the collision-engine thinks that the objects have much more speed than in reality they have at the moment. Because the the sharper object is so deep in the other object. So the force between the objects get too big and kaboom!

I assume the force should be equally as big as the objects' momentum? So the force was to just keep the objects separated (not allowing an object to get inside an other object)?


Sorry for bad english and horrible speculations :P

[-wes-]

It down to many things inculding; ping/ cpu speed/ server cpu speed/ packet quality/ isp congestion.




If the game server is overloaded(too many clients/stuff going on at the same time etc) people will begin to see server induced lag.

Server lag can be caused by lack of bandwidth or a slow cpu, wont matter if you have a ping of 5ms if the server cant send new data that fast.

The same can be said for the client pc, but its easyer to see.
A low frame rate can indicate lag on a client, lowering the framelimiter will alow the cpu more time to do other things.
If your pc is running slow, then your car will sink further into objects before anything happens. Speed is also a factor, the faster you go the faster your cpu needs to run in order to calculate the cars positon.

lfs uses ( i think) a physics based collision system, and a force is placed on objects upon collision. Nothing stops them from moving through each other unlike the gt games. Which use a bounding box solid surface for collison. Evan then objects can still go through each other when the framerate drops very low. (like 5fps)
Too very overlapped objects can end up placing their forces in the wrong direction, which is why thay can take off evan offline.
Pridiction errors online will cause a larger than normal force to be transmitted before you get the next update. So you start to fly, while the other person drives on as if nothing as happend. :razz:

the ping time you see will only be the minimum time for data travel, its not the full story.

you need a ping of 10ms to match lfs physics rate(100hz)
50 ms ping will give you 20 updates a second, not much is it?



When everything is working well, lfs has proven to be very good at collision/multiplayer.

[Hyperactive]

The same can be said for the client pc, but its easyer to see.
A low frame rate can indicate lag on a client, lowering the framelimiter will alow the cpu more time to do other things.
If your pc is running slow, then your car will sink further into objects before anything happens. Speed is also a factor, the faster you go the faster your cpu needs to run in order to calculate the cars positon.


So setting the framelimit can prevent these too? I ask this because I've just bought a new computer but haven't set framelimit...would around 30fps be enough?

And if two car's collide, the player with slower PC or slower connection (not talking about megabytes) gets the aero-effect?

I was just wondering how the collision detection actually works :tilt:

[the_angry_angel]

Isn't that what always happens when your car hits something? Check some of your replays and watch one hit in slow motion 0.250x to see that the damage is always slightly before the actual touch.Thinking about it, that could be probably be because the bounding box is very slightly larger than the car. A bounding box is a simplified "outline" of the car, which you can more easily check for intersection of vertexes on.

If the collision detection engine works how I think it does: It watches over the objects in the game and when too objects slightly cut each other's outlines the collision detection gives the phys-engine some data that there is a force between these two objects, the greater the cut in the greater the force.Thats exactly right :D Or at least how its traditionally done.

[Hyperactive]

Thinking about it, that could be probably be because the bounding box is very slightly larger than the car. A bounding box is a simplified "outline" of the car, which you can more easily check for intersection of vertexes on.

But if I remember it correctly I've seen the damage appear when the car was like half metres or more (around 2 feet) away from the wall for example. And not doing more than 60kph. So a slightly bigger bounding box doesn't sound to me how it is - and I may be wrong of course :Handshake:

[tristancliffe]

There's obviously a prediction system. We'd complain a lot more if the cars stuck through the fences momentarily before deforming!

[XCNuse]

yes hyper, you can pretty much watch any replay in slow mo, and you will see damage occur.. before you even get near the wall, here ill post just a quick replay showing this

just did a few tests.. it seems as though it only calculates early with cars (well.. hitting walls here and it crushes right after i go into them.. hm)

highlighted the times the corners
1 before
2 instant car deforms
3 well.. a bloody result :scared:

[-wes-]

So setting the framelimit can prevent these too? I ask this because I've just bought a new computer but haven't set framelimit...would around 30fps be enough?

And if two car's collide, the player with slower PC or slower connection (not talking about megabytes) gets the aero-effect?

I was just wondering how the collision detection actually works :tilt:

Well only if lfs is cpu bound on your system. It Just prevents the pc from doing screen related things.Put up the framerate on the screen. See if it changes after reducing the screen detail/res. If you have just bought a new pc a low framerate is more likely being caused by the graphics card.




programing link (http://www.gamedev.net/)

source code (http://home.wxs.nl/~monstrous/)

[Gunn]

Perhaps clipping adds to the illusion? OT, I was surprised to find my car undamaged recently after I slammed into a wall at high speed. On inspection of the replay my car appeared to repair itself as it rebounded from the wall, the way the AI does. New panels, new paint, new tyres! I should try to dig that one up and post it. Very unusual.

[Vain]

This is the usual way to substitute a full-blown prediction of collisions and all the trailing stuff and because of that I believe that the devs are fully aware of where, why and under which conditions this happens. And we will propably see advancements in the next versions. It's just very work-intensive.

Vain

[Sgt. Stinger]

I have had experiences when i drove straight throug the wooden fence @ blackwood carpark, and the car gets instant repair :) kinda LOL isn't it :p

[vpr01]

hehe. me and me mate mess around with the colliosion bug sometimes... just cruise into him at like 10mph and my car goes about 100ft in the air whilst doing some aerobatic barrel rolls and flips.

[the_angry_angel]

/me stroke beard

Sounds like you're on the ball with the prediction system. Although I would've thought that using those cycles for a higher physics rate is a better solution? Get around the problem, or solve it... Anyone feel like proving that thought wrong?

[Bob Smith]

/me stroke beard

Sounds like you're on the ball with the prediction system. Although I would've thought that using those cycles for a higher physics rate is a better solution? Get around the problem, or solve it... Anyone feel like proving that thought wrong?
Isn't the idea that the prediction system uses less cpu cycles than running the collision checking more often (for the same amount of effictiveness)?

[Vain]

Increasing the amount of cycles per second will not get rid of the problem. The intersections will just be smaller, but the rubber-jumps will still appear. Though... infinite checks per second would solve the problem. But you know... infinite... ;)
Prediction coupled with high check-rates (read: 100 Hz) is the best way to get sensefull collisions.

Vain

[the_angry_angel]

The way I see if happening, no.

Surely all the prediction system does is advance the bounding box vertexes in a direction, corresponding to the velocity of the vehicle. Either that or it projects a ray and sees if that intersects anything.

Assuming the bounding box case; I would've thought that this is fairly cpu intensive myself, even if the prediction bounding box is a simple cuboid. Using a single point as the prediction bounding box would be fairly inaccurate, so it must have some dimension(s).

Assuming the ray case; Its certainly by far less cpu intensive, but its not highly accurate. Perhaps this is the key to understanding the rubber object syndrome. Rather than real collision checking in the inner loop, the system runs a minimum of 4 rays on the horizontal plane (forwards, backwards, both sides), then on the main loop it runs real bounding box sanity checking. This would certainly explain the strange physics of bouncing off walls, as in certain directions and velocities the ray's would miss things, and they'd only get picked up when the real bounding box checking occurs.

Ah ha my dear Bob! I think we've got a reasonable explanation finally :detective

Edit:
If someone wants me to elaborate on the rays and how I think it works (if you're not following or you think I'm wrong), please tell me. I'd like to get to the bottom of understanding how LFS might work...

Edit 2:
Increasing the amount of cycles per second will not get rid of the problem. The intersections will just be smaller, but the rubber-jumps will still appear.Very good point, but it would be closer to real life ;)

Prediction coupled with high check-rates (read: 100 Hz) is the best way to get sensefull collisions.Depends on how well LFS predicts :p and at the moment I think it needs improvement...

[xapexcivicx]

Perhaps clipping adds to the illusion? OT, I was surprised to find my car undamaged recently after I slammed into a wall at high speed. On inspection of the replay my car appeared to repair itself as it rebounded from the wall, the way the AI does. New panels, new paint, new tyres! I should try to dig that one up and post it. Very unusual.
If it was single player, it could have been one of those automatic resets for going outside of the level.

[dave_w11]

I don't think the automatic resets reset your damage and tyres etc, just plonk you back on track where you were.

[xapexcivicx]

in single player? It resets everything if I'm not mistaken
90% sure

[xaotik]

Nope - go to Fern Bay Club, damage your car and then drive off straight after the first chicane (where the ads are), you'll get dropped back into track with the same car state (tyres/damage).

[Hyperactive]

Well only if lfs is cpu bound on your system. It Just prevents the pc from doing screen related things.Put up the framerate on the screen. See if it changes after reducing the screen detail/res. If you have just bought a new pc a low framerate is more likely being caused by the graphics card.

I haven't played LFS for some time now (pedal update) so I can't be sure, but I think my framerates are around 90 with fairly heavy setups. I have a 7800GT geforce and amd athlon 3500 plus 2x512 memory.

So setting a framelimit actually leaves some extra power for the cpu and graphics card to use if heavy calculating is suddenly needed? So the physics don't get any better, the game just "flows" better? (...)

Assuming the ray case; Its certainly by far less cpu intensive, but its not highly accurate. Perhaps this is the key to understanding the rubber object syndrome. Rather than real collision checking in the inner loop, the system runs a minimum of 4 rays on the horizontal plane (forwards, backwards, both sides), then on the main loop it runs real bounding box sanity checking. This would certainly explain the strange physics of bouncing off walls, as in certain directions and velocities the ray's would miss things, and they'd only get picked up when the real bounding box checking occurs.

But isn't that just a waste of cpu power to run that calculation first using the 4 rays and then in the main loop using the bounding box? If I understood it correctly the system first tests if the 4 rays "find" something and then uses the bounding box check to see what it is and _how to react to it_ (?). So nothing physics related does not happen before the bounding box check? As there is always a little time gap between the two operations the data that the ray-system transmits to the bounding-box-system is always little behind. Could this have something to do with it too? (...And doesn't the ray-system also have the vertical rays too, 6 altogether; 1 forward, 1 backward, left and right, up and down...:))

Or did I just understood it all wrong :smileypul

EDIT. added some

[StewartFisher]

Nope - go to Fern Bay Club, damage your car and then drive off straight after the first chicane (where the ads are), you'll get dropped back into track with the same car state (tyres/damage).
Correct, but if you hit space (or whatever key you've assigned) your car will be reset with fresh tyres and all damage fixed. The automatic car reset works differently to the manual one.

[the_angry_angel]

But isn't that just a waste of cpu power to run that calculation first using the 4 rays and then in the main loop using the bounding box?No, because its much easier to check a single point or line more often, than multiple points less often.

If I understood it correctly the system first tests if the 4 rays "find" something and then uses the bounding box check to see what it is and _how to react to it_ (?).Sort of...let me explain

So nothing physics related does not happen before the bounding box check? As there is always a little time gap between the two operations the data that the ray-system transmits to the bounding-box-system is always little behind.The ray system is always ahead of the bounding box, in this situation, yup :up: :)

Could this have something to do with it too?Yes, it would explain why you get damage before hitting something - and thats exactly the point :D

However, its difficult to say exactly as we dont know how it works...exactly. The ray system is done everytime the vehicle moves in my head.

Probably the easiest way to explain it is in pseudocode (fake code);main loop (at 100Hz)
{
inner loop (at 20Hz, every 1/100th of a second which makes 2KHz)
{
Ray casting to check possible collisions (also checks rays from other vehicles)
Check rays according to velocities and determine if theres unavoidable collision
If collision occurs
{
do damage according to prediction
}

Move Car
}

Create bounding box according to vehicles current shape
Bounding box checking to determine collisions
If collision occurs
{
do damage
}
}

(...And doesn't the ray-system also have the vertical rays too, 6 altogether; 1 forward, 1 backward, left and right, up and down...:))Yes, but I was only considering the horizontal plane, not the horizontal and vertical :) As for the down ray - I'm not sure. There would probably be one for the main simulation, but I'm not sure on how relevant it would be for collisions as I'm unaware if you can damage from that direction :)

Or did I just understood it all wrong :smileypulNope, you've got a lot of it right :)

[Hyperactive]

Probably the easiest way to explain it is in pseudocode (fake code);main loop (at 100Hz)
{
inner loop (at 20Hz, every 1/100th of a second which makes 2KHz)
{
Ray casting to check possible collisions (also checks rays from other vehicles)
Check rays according to velocities and determine if theres unavoidable collision
If collision occurs
{
do damage according to prediction
}

Move Car
}

Create bounding box according to vehicles current shape
Bounding box checking to determine collisions
If collision occurs
{
do damage
}
}


Hmm, after inspecting the code I just wonder why the damage to the car is done in both loops? Did you mean that the rays are used to do a "good guess" damage and the actual calculations for the damage are done later using the bounding box and the phys engine kicks in here? Are the car damage and the damage-related forces created at the same same loop (in your system?).

Hmm...if the car shape changes in the inner loop, the bounding box has the altered body shape used when it determines the collision? Or does it?

(I'm getting pretty deep into this, and still it all is just a guess:))

[dUmAsS]

Increasing the amount of cycles per second will not get rid of the problem. The intersections will just be smaller, but the rubber-jumps will still appear. Though... infinite checks per second would solve the problem. But you know... infinite... ;)
Prediction coupled with high check-rates (read: 100 Hz) is the best way to get sensefull collisions.

Vain

no thats not the best way. keep the collision detection around 60hz and just add continuous collision code

first google result: http://gamma.cs.unc.edu/Articulate/ (has some good pics showing what actually happens in lfs)

[Vain]

1. Did I read correctly that the continuous collison performs in "nearly interactive" rates? That means in about... 5Hz? On a dedicated machine (it does nothing else!)?
2. Due to the nature of continuous collision the amount of needed CPU- and GPU-time increases significantly with the amount of moving objects that are checked. Is that correct?

These are just the first questions when it comes to continuous collision that come to my mind.

Vain

[the_angry_angel]

Did you mean that the rays are used to do a "good guess" damage and the actual calculations for the damage are done later using the bounding box and the phys engine kicks in here?I'm not entirely sure to be honest. Its a theory I still cant decide on. Doing the deformation would be too heavy for the inner loop, so I'd say you're right :) But it doesnt explain exactly how the prediction works, or even if it is true prediction and not just some form of lag between engine components.

Are the car damage and the damage-related forces created at the same same loop (in your system?)No. In my current system the forces are created in the car movement section.

The reason I'm currently thinking that LFS used a ray [prediction] system, is the problem that a ray wouldnt detect current intersections, and in the next loop it could cause the sort of behaviour we experience :)

Due to the nature of continuous collision the amount of needed CPU- and GPU-time increases significantlyThe point of the constant rate of physics is two fold, to keep the simulation in time easily and to restrict the number of frames required to be drawn :) Therefore you dont have to draw every frame of movement - so continuous detection should only be CPU limited (in theory) :) But practically you're probably right :s

[dUmAsS]

2. Due to the nature of continuous collision the amount of needed CPU- and GPU-time increases significantly with the amount of moving objects that are checked. Is that correct?

well with CC you can lower the main collision detection frequency so the speed decrease from using CC evens out

and you would only enable it for the cars anyway, not dynamic track objects

[Gunn]

If it was single player, it could have been one of those automatic resets for going outside of the level.Multiplayer online at Westhill. I think there was an AI car circulating at the time too.

[-wes-]

Pridection relates to online games. It's the client pc (your pc) guessing where your new positon will be.

Its always the server that decides where everything is, you can not move untill the server says ok.
All fps games use this because it prevents cheating, and keeps everyone in sync.

You can see this in counterstrike if you switch off client prediction ( cl_pridect=0)
Go to a server where you have high ping 200ms say; notice the delay before you can move?

Prediction covers up that delay.

In driving games this would be very bad. So your car is not subjected to server control in the same way. I'm not sure how a driving game would do it but I guess it would just check that your car is not doing the impossible and that its around the area the server thinks it shoud be.

You still get pridiction for the other players, so sometimes a car will drive stright on in a corner because your pc is not recieving data for it.

[mattlikespeoples]

wow, half of the stuff in my own thread i cant even understand:shrug:
that's quite alright. with all this talk of prediction and rays and loop cycles, can we get a dev to comment? maybe just to shed some light on if these guys are headed in the right direction. sounds like they have but some actual comfirmation would be a nice touch :nod::D

[the_angry_angel]

Pridection relates to online games. It's the client pc (your pc) guessing where your new positon will be.Yes, but we're not talking about client-server vehicle prediction - we're concentrating on damage prediction..

I'm still not convinced my theory is entirely right. It just doesnt logically make sense. But we certainly cant contribute it to lag. Also we equally cant apply it to the server telling the client the vehicle is somewhere else, as it (the vehicle which gets damaged) would "snap" into its new position. This assumes that Scawen gets the client to snap under all situtations, and its entirely possible that that assumption is not true, and that scawen only snaps in extreme cases.

Its always the server that decides where everything is, you can not move untill the server says ok. Not always, and its not been done in online games in this manner, since quakeworld... but yes, if the client disagrees with the server, then the client always alters it state to be the same as the server In driving games this would be very bad.Yes, and this is especially true in LFS as we only get packets from the server every 1/6 to 1/3 of a second. That would be too much of a lag to race. So yes, you're right :)

I'm not sure how a driving game would do itIn the way already described? The client predicts, then every "update packet" the client snaps all objects in the wrong place to the servers desired location...

[-wes-]

I was thinking last night about the damage showing up before you hit a wall.
And I think I've got it!
When you watch an online replay, your watching events from the SERVERS
prespective.

This means that your car(in the replay) is lagging behind your live(when you were racing) possion.
When you hit a wall your pc sends the impact info to the server, which then puts it on it's version of your car immediately. :tilt:
So from the servers view the damage can show up on the car before the impact, as the damage info can be sent before a true position packet is sent.
:D

impact (http://www.-wes-.f2s.com/impact3.avi)
1.7mb

see how the car gets moved in the air? Didnt happen when I was driving live.
but this is the servers view so it snaped the car's position when it received new positon data from my pc.

[the_angry_angel]

This means that your car(in the replay) is lagging behind your live(when you were racing) possion.I think I see where you're going with this. I had assumed that the replay was exactly as you'd see it on the client.

I'm having a busy and a fairly bad day, so I think I'm gonna have to try and get my head around this properly, later :(

[maczo]

I had assumed that the replay was exactly as you'd see it on the client.

isn't it almost the same but with the exception of your own car? for what i've noticed, your own car's path in an mpr is updated just like every other player's car (it's sort of 'jumpy'). that would be quite logical, as then each and every car in the mpr would have the same format for path info. correct?

[AndroidXP]

Well, the lag explanation is a nice try, but when I think about it, how would that work? If you watch an mpr it surely is from the server pov, but then everything just lags behind, but that doesn't explain a mysteriously appearing body damage. If you send the "oh I hit a wall" packet then this packet is also delayed, like all the other position update packets.

see how the car gets moved in the air? Didnt happen when I was driving live.
but this is the servers view so it snaped the car's position when it received new positon data from my pc.Also I actually don't think that there's an "collision" packet at all. The server just gets position and status (tyres, suspension/engine damage, ...) updates and just calculates what would've happend (including, physics wise unimportant, body damage) if you had continued driving with the same steering/throttle amount, etc. and then updates the actual position as soon as it gets a real packet again. And depending on how recent the last packet was the more or less accurate the server-calculated events/driving paths are.

Anyways, back to the mysterious damage; I think instead of using the actual position for the damage calculations it uses the position of the cars that they would have in the next frame, so depending on how much FPS you have, the "precalculated" path is longer or shorter (making the pre-impact appearing damage more obvious at low FPS). Maybe, as the internal engine tries to run at 100Hz, it's not FPS dependend but merely speed dependend, but the point is the same.

[Shotglass]

does the damage before impact only hapen in replays or also during real time gameplay ?

[the_angry_angel]

Also I actually don't think that there's an "collision" packet at all. The server just gets position and status (tyres, suspension/engine damage, ...) updates and just calculates what would've happend (including, physics wise unimportant, body damage)Yes, you're exactly right - which is my problem with the "servers POV" solution. I really didnt have time to think it through yesterday, but you've got the nail on the head with that idea...

it uses the position of the cars that they would have in the next frameNice idea, but you cant really do this as an unknown number of physics steps will have cycled (outside influences could alter the FPS and thus the number of cycles per frame etc. etc.), so things may happen that you cant predict accurately, and you'd probably end up doing the expensive damage calculations twice for the same item of damage.

Whilst its a nice idea, I'm not sure on how it would applicable it is, for the above reasons :(

does the damage before impact only hapen in replays or also during real time gameplay ?This is something I've been meaning to discover.

Other than recording the output of LFS, through a graphics card (fraps wouldnt have a small enough frame time), so we can determine this, I dont think we can solve the mystery completely :(

[XCNuse]

it happens early realtime, just so fast you dont notice it, thats why i dont really see this whole thing as being a problem imo

and about the "server side" replay.. that makes no since, why would the server be doing work for your own computer like that? afaik, your own car doesnt lag whatsoever in any way shape or form.. if it did im sure you would see some times where you are jumpy and whatnot, each replay is done by your own computer recorded by what is being sent to you, otherwise it would be the server sending you what you just did which.. i still have to say makes no since at all

after testing this in single player, im gonna have to say it occurs only in multiplayer, so heres a test for you angel, get some buds, go to BL carpark, run some cars into each other and watch what happens (one stopped, and have the other car charge into it)

if nothing happens, lower the PPS, if nothing then, somehow increase lag (might be hard but it would be helpful) so what i suggest is you do one at 3 PPS and if you didnt see anything, still save replay, leave server for a few secs, and watch that MPR again and see what happens, if nothing happens this might be deeper than lag

[the_angry_angel]

I'm not seeing it as a problem XCNuse, I'm more curious about how LFS works, and understanding some of its stranger behaviours. Sometimes it can help solving problems or answering questions. Plus it solves some of my personal niggles.

after testing this in single player, im gonna have to say it occurs only in multiplayerOh dear :( (see my comment at the bottom)

so heres a test for you angel, get some buds, go to BL carpark, run some cars into each other and watch what happens (one stopped, and have the other car charge into it)*sigh* Something (amongst other things) I've been trying to sort out for a little while - but nothing I have time for :( (****ing woman changing things last minute [her: "oh, we'll go to mine tonight" me: "but we said mine...i've arranged to do things later" her: "dont you love me?" me: "argh!! ****ing hell..." etc. ] and work [booo, evil buggers :p])

if nothing happens this might be deeper than lagThats kind of my fear at the moment. It could be a deep issue with LFS, and in the future it might be a lot harder to fix :(

[Hyperactive]

I'm not sure what did you mean but I think the server just shares the data about car damage, car positions, player related data (name, car choise...) etc. ... and checks that the client has valid version of LFS

But wouldn't it be *** to have the server run the physics of the all cars too?

I think the system is more like this:
the server just shares the data. Meaning that that it gets data from player A's client and sends it to other players. Then these client machines check the positions of the other cars and compared it to the postion of your own car (also speed and other factors too). As the network system has lag and the physics system has lag, these two make this possible:

Let's imagine two cars racing on the track:
1. cars are 1 mm from each other

2. a data package is send to the server by both clients about their current situation

3. Server forwards the data back to clients
Let's assume these 3 steps take 0,2s to happen.
In the meanwhile the cars have moved forward and also closer to each others in their clients' LFS engine. The server does not know this yet. The real distance between them is now -5mm. So the cars are "overlapping". At the moment the client A thinks that the other car B is driving directly forward. The client A does not get any actual data about this but it predicts it. The same is done vice versa.

4. So the both clients think there is some distance between them. Now the clients recieve the packets from the server. The collision system (the rays system, as mentioned earlier) is ran and the prediction damage is calculated and shows up in the 3d model. (the ray models notices that the cars are overlapping)

5. The actual code handling the actual damage and physics is calculated (the bounding box, as said earlier). It gets some weird data about the distance and the speeds of the cars (the distance of the cars being now -5mm). As it was just just before positive and bigger. (This may or may not be the cause why we sometimes get some strange sky flying episodes, but I have some more to it. The physics engine may see that the other car has a lot more speed than it in reality has and therefore it thinks the impact is much higher...read on)

6. The physics are run in the clients' machines and clients send this data to the server, which forwards them as said earlier.
6.1 at the same time the car of the client gets its physics data and the physics are run. The car of the client A gets the force of the impact and moves slightly away from the the other car B (but the B doesn't see it yet, though he moves away also, but the A does not see this. They both see the other has moved when they get their packets from server.

7. The impact is not that big, so the cars don't change their lines much. So when the clients recieve the next packets the data on those says: Cars are still inside each other, distance being -3mm, but the speed of the both cars is away from each others too. Maybe the clients engine can't understand this (or the force factor is coded so that it is set as integer with values acceptable being over 0 and under 50000 (can't remember the right values for this, sorry). As it gets a negative value (or too big one) the integer gets "upside down" and becomes something really big. Or it gets a 0, meaning there is no effect at all.

But there is also a third option. As the bounding box sees the distance is negative it tells the phys engine to create a negative force too. As this force draws the other car close the value gets again negative and bigger, let's say -12mm. Now the bounding box gets the right values for the speed (cars gettting closer) and wrong values for the distance. So it just gives some berzerk values to the physics engine, which creates a big force between the cars.

8. So the client A gets a big value and flies off the skies while the B keeps driving and notices an airplane on the sky :). The client A sends the data to the server which just forwards it, and doesn't notice those ridiculous values about it's altitude.


I will read this once more, once I've got my head cleared up. So beware the obvious logical errors in it :smileypul

[the_angry_angel]

I think the system is more like this:
the server just shares the data. Meaning that that it gets data from player A's client and sends it to other players.It also does some basic sanity checking as well...
Then these client machines check the positions of the other cars and compared it to the postion of your own car (also speed and other factors too).Yes, sorry if I didnt make this clear. This is exactly how it should work. The client is the only one who works out damage. The server shouldnt even see the clients as more than 1 "point".

I've not got the chance to read your whole post right now. I'll edit/update when I can.