The online racing simulator
Crash Physics!!!
1
(26 posts, started )
Crash Physics!!!
I'm all for drama but what is up with the crashing?

I went into the hairpin a little hot at AS NTNL and bumped a car as he was turning in. He went spinning off into oblivion.
Or in an XFR I was playing around and rammed a car at about 50kmph and my car hopped up and flipped ass over teakettle.

Am I the only one that finds this a bit irritating?

lambchop44
(\ /)

(O.o)

(> <)



Dominate the world, bunny!
I dont have a problem...I dont crash

Its just the incompeted physics..
#3 - JTbo
You should not ram to other cars.

And yes, cars are too strong, they would neet to be easier to destroy 50kph to solid wall or other car and your car should be undrivable, as can be seen at crash tests.
repeat after me... lfs != finished
lfs != finished
(even relatively small) lag = big collisions
lfs != finished
Well, so far, only 'God' has managed to balance all forces perfectly.
Scawen might need a bit more time. Collisions aren't too bad imo but
there are still some bugs sending things into oblivion.
Just (ha, just!) needs elasticity of collisions to be added (the barriers 'soak' energy in real life) so that weird things like this don't happen so much. The other issue is that cars actually overlap between packets, meaning suddenly LFS realises two cars are in the same space. This generates huge forces, which makes some pretty impressive crashes.
-
(thisnameistaken) DELETED by thisnameistaken
Quote from thisnameistaken :It seems that some collisions are more damaging than others though. I've been lapping the XFR around FE Club lately and found that if I slide off and hit the barriers with the side of the car, it tends to completely destroy the suspension both front and rear on the side that hits the wall. But if I hit it head-on, I only get a bit of damage.

Straight head-ons damage your caster, and caster is the primary thing that gives you the forces on a FF wheel. With enough caster damage, you can actually get negative caster. This causes the front wheels to anti-center, or move to either the left or right extreme. Basically the forces become inverted.
Quote from tristancliffe :Just (ha, just!) needs elasticity of collisions to be added (the barriers 'soak' energy in real life) so that weird things like this don't happen so much. The other issue is that cars actually overlap between packets, meaning suddenly LFS realises two cars are in the same space. This generates huge forces, which makes some pretty impressive crashes.

exactly! the overlap caused by lag isn't usually so dangerous, either because on regular races after T1 we ususally don't get too close other cars and lags usually are not too big and also because since we got car damage, i think car-to-car collision is somehow "elastic"...BUT, lightly hitting objects will produce "hyperspace jumps" that are totally unrealistic...as i said this has not been a huge problem for regular races till now (except for SO track), but since servers are hosting custom layouts (see StuntRacerClub) where rigid objects are all around, this is becoming a much bigger realism problem IMO.

i imagine that scawen will schedule this for a major patch after S2 final, not before i think...in the meanwhile let's consider this: good crashes realism is good, not crashing is better
AFAIK it's exactly the opposite; the elasticy causes most of the problems. If all objects were as rigid as the side barriers there would be much less crazy airborne incidents. The reason for this is because those crazy reactions happen as soon as the "touching point" of a wheel intersects with one of the objects, and the softness allows the cars to squish into them enough for the "fatal touch".

Another thing to think about is taking the last few known position frames and checking if the current position is actually possible, which would prevent the "driving through objects at high speeds" bug. The current system only checks the actual positions disregarding the "history" completely, resulting in situations where you're "hugely" intersecting with other objects causing an extreme counter force physics reaction. If you took the "history" and saw that both objects touched eachother at a speed of 1 km/h then you'd know such big forces are impossible and you can therefore generate forces for a 1 km/h collision instead.
Unfortunately its not down to elasticity as such, and nor is it "packets" from the server. I'm of the opinion that all bodies are 100% rigid, without elasticity.

The reason I believe this is that between physics steps the objects intersect and the physics engine calculates the force that would be required to do that. Thus assigns a corresponding impulse - which is rather large. If it was elastic, then we shouldn't bounce at all, as the force would initially be cushioned. A little comment, try thinking in terms of physics steps rather than frames, as the frame rate is independent of the physics system.

I can see a lot of comments going in the same direction as the "Collision Detection" thread we had recently. It might pay to briefly read that over.
Yeah, I meant physics steps anyways. Well currently many objects feel pretty soft to me, which looks like an attempt to soften up those bounce problems. IMO the only real problem is the tyre contact patch touching any of these objects, and if the behaviour of such an intersection was fixed there wouldn't be any crazy reactions but merely going-through-things issues left.
Sorry if I'm misunderstanding your point, and LFS completely, but "going-through-things" is whats causing the problem in the first place?! I think that the "softness" is a side product of this (see explanation below).

ObjectX passes through ObjectY.
Physics engine observes this, and realises that its not right.
Rather than merely moving ObjectX a few units so that its "outside" of ObjectY, the physics engine tries to be clever and deduces that this must've been a fairly large force to cause this, and calculates what force to apply to ObjectX.
Oh no. We've been catapulted across the track.

With regards to the tyre deformation, I'm not sure if it even interacts with walls or objects. Its not something I've actively looked into LFS for. if it does, then I apologise as you maybe right; although it seems like a bit of a hack - which isnt something LFS or Scawen is known to do.
#16 - JTbo
Good example is BL pit garage walls, you need to drive out from garage so that side of car touches wall corner, wall and car are getting into each other can catapult effect is ready. You can do this with walking speed, 5kph is surely enough.

When kind of solid object touches car internal not flexible part then there is suddenly great amount of energy generated.

Imo, one problem is that damage engine is too slow, you can verify this by hitting wall 60kph and 160kph, later gives less damage because engine can't calculate fast enough.

Well, I don't know if it is engine or just math model or whatever, but I think that you see my idea here?

Maybe devs do already know how to make it work better, we can just wait and wish for best and fear for arcade damage model
I completely agree with you JTBo.

The damage engine being too slow is one we could debate long and hard, but the short of it is that we just dont know how LFS works and we can only speculate.

Its gonna be hard at the LFS meet, not asking Scawen these questions
Just concentrate on filming stuff then
One will be creating art *caveman attack impression on camera*

Edit: Be prepared for 4 hours of my face grinning at the camera
#20 - JTbo
I would like to ask from devs what is importance order of these:
Damage model
New tracks/cars
Graphics
Tyre physics
Engine modeling(rpm limiters, temps etc)
Is there some other what devs have on list

Sorry for OT, could not control myself again
Its probably not fair for us/me to ask, but if they start up a conversation along those lines I wont forget
Quote from JTbo :I would like to ask from devs what is importance order of these:

My guess:
Tyre physics
Engine modeling(rpm limiters, temps etc)
Damage model
New tracks/cars
Graphics

@the_angry_angel: yeah, I think that its not the actual collision box (the car body) doing much harm but rather only when the tyres come into play. And that softness makes the tires able, or atleast more likely, to intersect with whatever object was in the way.
#23 - JTbo
Here is pics and vids from my limited testing about collision bug. Clearly there is something wrong with that building, lol.

It did not even touched yet, imo.

Pics body 24-25 there is collision.

Pics force 4-5 there is collision.
#24 - JTbo
Quote from JTbo :I would like to ask from devs what is importance order of these:
Damage model
New tracks/cars
Graphics
Tyre physics
Engine modeling(rpm limiters, temps etc)
Is there some other what devs have on list?

Sorry for OT, could not control myself again

I did forgot engine sounds from list
We all know that LFS' collision model is unrefined... I'd imagine there are some nice vector-collision algorithms cooked up on Scawens codenboxen simmering for implementation in the future.

The way it seems, to me at least, is that the car is 'allowed' to exist in the same space as another object, whereas that will eventually need to be changed... I think when a collision is detected, the game should calculate the 'impact point' based on the two last known vectors and velocities of the object, THEN determine the force, elasticity, deformation, etc... I think that'd save on a lot of the magic rocket rides into the atmosphere. Lagging cars is another matter to handle, since they're so unweildly at times. I think the game does this for 'physics objects' at the moment.. like the tyres and cones, but the static objects, I dunno.

Still, the implementation is solid (though has these quirks), it's a hojillion times better than most games out there.... Anyone play NFS: Porsche Unleased on a LAN? Anyone manage to snap a road sign into the air and have it land on the guy behind you?

50lb road sign + 2000lb car @ 200km/hr = CAR STOP DEAD IN IT'S TRACKS?!

Yeah :P I started hitting every road sign I could after that one!!!
1

Crash Physics!!!
(26 posts, started )
FGED GREDG RDFGDR GSFDG