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.

/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?

Quote from 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?

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)?

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 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:

Quote from 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.

Very good point, but it would be closer to real life

Quote from Vain :

Prediction coupled with high check-rates (read: 100 Hz) is the best way to get sensefull collisions.

Depends on how well LFS predicts and at the moment I think it needs improvement...

Quote from 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.

If it was single player, it could have been one of those automatic resets for going outside of the level.

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

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

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).

Quote from -wes- :

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? (...)

Quote from the_angry_angel :

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

EDIT. added some

Quote from 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).

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.

Quote from Hyperactive :

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.

Quote from Hyperactive :

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

Quote from Hyperactive :

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:

Quote from Hyperactive :

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

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);

Quote from Hyperactive :

(...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

Quote from Hyperactive :

Or did I just understood it all wrong

Nope, you've got a lot of it right

Quote from the_angry_angel :

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)

Quote from 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

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)

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

Quote from Hyperactive :

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.

Quote from Hyperactive :

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

Quote from Vain :

Due to the nature of continuous collision the amount of needed CPU- and GPU-time increases significantly

The 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

Quote from Vain :

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

Quote from xapexcivicx :

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.

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.

wow, half of the stuff in my own thread i cant even understand
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

Quote from -wes- :

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.

Quote from -wes- :

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

Quote :

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

Quote from -wes- :

I'm not sure how a driving game would do it

In 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...

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.
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.


impact
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.

Quote from -wes- :

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

Quote from the_angry_angel :

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?

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.

Quote :

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.