The online racing simulator
#1 - CSU1
impact absorbtion/collision system:
Have been fooling around driving Nascar and it really does show where LFS fails in terms of dealing with the whole collision system.

Why don't the models in LFS absorb impact instead of giving a 100000000000000% counter force throwing the models in the air?

Is just a general question guy's, and I know whatever scavier is doing is right snd for the best.at.their.own.time. I just want to hear what you think FEELS wrong with the collision system. Discuss.
Yes the current system is wrong. A real collision would absorb some force and send back the rest. The thing is that it's difficult to determine how much of the force is absorbed, it all depends on many many things. I think Scawen had really only two simple ways to implement the collision system easily. He could have gone for the all absorbing system, but it would probably have been even sillier than the all reflecting system we have now. Especially during S1 all absorbing would have looked very stupid without visual damage.
#3 - CSU1
Quote from geeman1 :Yes the current system is wrong. A real collision would absorb some force and send back the rest. The thing is that it's difficult to determine how much of the force is absorbed,

Awww mate, as you all very well know I don't have a head for math but surely what you said is wrong, calculate speed, weight and the varying factors of different parts of the models structure to calculate how much force should be dulled and obsorbed into each model!?!?
Quote from CSU1 :and the varying factors of different parts of the models structure to calculate how much force should be dulled and obsorbed into each model!?!?

That's just the hard part. You need to model the inside parts of the car too to do that (not necessarily visually, but their properties). You also need to take direction of the force also plays a big part in this. Different parts react differently to different hits from all different directions.
I am not saying it can't be done, but even Scawen can't do it in few hours. It needs a whole lot of work.
I think it alot different and i feel that its not that great but would do. If somebody turns into me and we both go sideway and i sort of hit him on the side he goes into a spin and flips. My brother just touched someone down the straight scraped sides and they both came off. In real like you would really feel a jerk and bit of an impact in the wheel.

Hope this helps,

Matt
#7 - CSU1
Quote from geeman1 :That's just the hard part. You need to model the inside parts of the car too to do that (not necessarily visually, but their properties). You also need to take direction of the force also plays a big part in this. Different parts react differently to different hits from all different directions.
I am not saying it can't be done, but even Scawen can't do it in few hours. It needs a whole lot of work.

So im sorry and sorry android if this question has been answered in.

Geeman, thanks. Understanding that the damage we 'see' does not mean there has been damage done to the underlieing model.
#8 - col
Guys, the problem is not about an 'all absorbing' or 'all reflecting' system...

the problem is caused because of multiplayer lag issues... sometimes because of limitations of multiplayer gaming, there is suddenly a big overlap between cars, this causes the collision system to think that huge forces must have been applied... if you decided to 'absorb' them instead of 'reflect' them , then the cars would be crushed to little blocks instead of shooting for the moon...

The real trick - and its a difficult one is for the collision detection to 'know' when overlap is caused by lag and when its caused by a normal bonafide collision... it doesn't matter what 'solution' you use, there will be many implications and there will always be some situations where the resulting behaviour is unrealistic... the only way this will be completely resolved is when the internet gets fast enough and error free enough that lag becomes insignificant.

I'm sure Scawen will come up with something that is more acceptable then the current system (although it seems pretty good to me in most cases), just remember that the real limitation is the internet and don't expect miracles
But it's not just the lag-launching that's the problem - you can experience it with any game. LFS' collision bugs happen offline too, most notably when there's a collision with a static object ... I've set many a pb at Aston by exiting the last turn, lining up the pointy end of the pit wall and having it launch me across the line at Mach 2

[now, how about we move this to Improvement Suggestions?]
#10 - CSU1
Quote from Hankstar :But it's not just the lag-launching that's the problem - you can experience it with any game. LFS' collision bugs happen offline too, most notably when there's a collision with a static object ... I've set many a pb at Aston by exiting the last turn, lining up the pointy end of the pit wall and having it launch me across the line at Mach 2

[now, how about we move this to Improvement Suggestions?]

Dont be silly mate, where's the suggested improvent here?

No, as pointed out above the collision system can't be accurate untill model damage is simulated.
Quote from CSU1 :Dont be silly mate, where's the suggested improvent here?

It's implied, obviously
I rarely experience those unrealistic collisions, and every time that do happens, it's because someone lagged ubnormally, or something like that...
Check out this vid from our OPS championship where i had a severe crash with one of the lapped drivers... it made my hair go gray as it was a final lap and i was batlleing for position with one guy for 10 laps, but at least it looks real.. http://www.youtube.com/watch?v=Un_W5AJdpOw
It can't all come down to lag, I've been launched of some of those walls in South City a few times whilst hotlapping.
Walls are indeed a weak point. I managed to hit a wall/barrier at 10 km/h, only to find my car on the surface of the moon, several seconds later. That should be fixed first, IMHO.
No, I think it's two different problems, with lag encouraging one of them to appear. First is body intersection, where LFS seems to want to separate the bodies by applying a force just high enough so the intersection is gone in the next collision detection cycle (which runs at 100Hz, I believe). This happens mainly if cars lag into each other, shooting both off into the opposite direction. Some objects seem to have the same basic reaction, but the force is obviously dampened to make them soft (barriers, tyre stacks).

The second, very specific problem is when the contact patch of one of the tyres starts intersecting with an object. I think LFS always tries to put the tyre on top whatever it intersects with, which is okay for bumps on the road, but has quite spectacular results if the "bump" happens to be a red-white barrier. The force calculated from a height difference of a metre within one frame does the rest.

Example 1: South City sideways slide into wall. The tyres on the impact side start intersecting briefly with the wall, generating a short force spike upwards on that side of the car, which is why it always results in a roll "away" from the wall.

Example 2: Red white barriers. These suffer greatly from both problems, with the main quirk being that they are "soft", but at the same time unmovable. Soft alone usually means that with enough force you can drive through them, because the counter-force is not 100% of what is needed to separate the objects, which in the case of tyre stacks is barely noticeable as they're shot off themselves. The barriers however stay put, making it much easier for you to overcome this repellent force allowing you to pass through them with relative ease. For "shortcut" purposes it is generally enough if you have enough speed to make the car pass through the barrier halfway, because as soon as you're through more than 50% it starts shooting you off into the direction you actually want to go.
But with passing through objects, there also comes the risk of your tyres intersecting with it during a collision detection cycle, which is the reason you can only pass "safely" through them with a certain speed, and also explains why the reactions of passing through are seemingly random. Just as an example, imagine we barge through a barrier with 100km/h, which is 27.7m/s, which at 100Hz means that the collision detection makes a check every 27.7cm of car movement. Now picture a side view from the car, drawing a line every 27.7cm. If one of these lines intersects with one tyre's contact patch, you'll fly off, or if it's barely touching, suffer from suspension damage. Of course you cannot calculate a perfect passing through speed with this for each car, because the first line is not necessarily drawn at the front of the car, but can be placed randomly within the first 27.7cm of it, depending on how long ago the last collision check ran when you started intersecting the barrier.

Easy to analyse? Yes. Easy to solve? No.
#16 - col
Quote from AndroidXP :No, I think it's two different problems...

great analysis

I think that the second version - the 'non-lag' one should actually be solvable at least to the extent where its effect is not causing any problems during races. (I vaguely remember Scawen saying as much a while back). It should be possible to use some carefully constructed set of logical rules to decide whether the car has intersected an object in such a way that tyre collision response should be ignored or 'watered down' in favour of some more sensible response system.... this should at least be much simpler than dealing with any lag related issues where there are too many unknowns.

(Is there not also some less significant issue to do with the fact that some of the track-side components like the high kerbstones at south city (eg at the pitlane entry for classic reverse) have 'ideal' 90º infinitely sharp edges ?)

cheers

Col
#17 - CSU1
Quote from AndroidXP :No, I think it's two different problems, with lag encouraging one of them to appear. First is body intersection, where LFS seems to want to separate the bodies by applying a force just high enough so the intersection is gone in the next collision detection cycle (which runs at 100Hz, I believe). This happens mainly if cars lag into each other, shooting both off into the opposite direction. Some objects seem to have the same basic reaction, but the force is obviously dampened to make them soft (barriers, tyre stacks).

The second, very specific problem is when the contact patch of one of the tyres starts intersecting with an object. I think LFS always tries to put the tyre on top whatever it intersects with, which is okay for bumps on the road, but has quite spectacular results if the "bump" happens to be a red-white barrier. The force calculated from a height difference of a metre within one frame does the rest.

Example 1: South City sideways slide into wall. The tyres on the impact side start intersecting briefly with the wall, generating a short force spike upwards on that side of the car, which is why it always results in a roll "away" from the wall.

Example 2: Red white barriers. These suffer greatly from both problems, with the main quirk being that they are "soft", but at the same time unmovable. Soft alone usually means that with enough force you can drive through them, because the counter-force is not 100% of what is needed to separate the objects, which in the case of tyre stacks is barely noticeable as they're shot off themselves. The barriers however stay put, making it much easier for you to overcome this repellent force allowing you to pass through them with relative ease. For "shortcut" purposes it is generally enough if you have enough speed to make the car pass through the barrier halfway, because as soon as you're through more than 50% it starts shooting you off into the direction you actually want to go.
But with passing through objects, there also comes the risk of your tyres intersecting with it during a collision detection cycle, which is the reason you can only pass "safely" through them with a certain speed, and also explains why the reactions of passing through are seemingly random. Just as an example, imagine we barge through a barrier with 100km/h, which is 27.7m/s, which at 100Hz means that the collision detection makes a check every 27.7cm of car movement. Now picture a side view from the car, drawing a line every 27.7cm. If one of these lines intersects with one tyre's contact patch, you'll fly off, or if it's barely touching, suffer from suspension damage. Of course you cannot calculate a perfect passing through speed with this for each car, because the first line is not necessarily drawn at the front of the car, but can be placed randomly within the first 27.7cm of it, depending on how long ago the last collision check ran when you started intersecting the barrier.

Easy to analyse? Yes. Easy to solve? No.

Great overview Android,

Ok as lag issues plague almost every multiplayer engine in exsistance, and knowing that this area of the problem can only be solved with help of faster internet networks both on the clients and hosts side, thats in the near future, the web is always growing.

Let us put the lag issues asside for a moment and discuss how the car models in LFS interact with both the road-side models and other cars. You pointed out that there may be 'counter-force' value to each model, the red/white barriers are supposed to be soft yet are stationary and for example have a counter-force value of 50% yet the car model travelling at great speed can overlap the collision system and end up inside the barrier, why? Why does the current system allow models to share the same physical space? Should all models not have 100% counter force values so the possibility of overlap (tyre patch or car model) is impossible?

Counter-force should be determined by how much damage has been inflicted to each car model, but, as pointed out above the models do not yet simulate crumple zones/impact absorbtion.
I've tried so hard not to get involved this time...
Quote from CSU1 :Why does the current system allow models to share the same physical space? Should all models not have 100% counter force values so the possibility of overlap (tyre patch or car model) is impossible?

For the very reason Android outlined. The physics aren't being continuously calculated, but calculated at a constant rate with distinctive amounts of time between each collision step. This means that as each physics iteration runs, it's possible to move very large distances. Due to this, and how intensive collision detections are to calculate (which are required to prevent any intersection between 2 planes, it's possible to get "overlapping".

Since LFS seems to try to be generic in it's physics capabilities (this is actually why LFS is pretty good, little can be classed as "canned effects") this causes an appropriate impulse, and hence the massive force between the two objects.

FGED GREDG RDFGDR GSFDG