Two very informative and very very good posts, lol. You should have posted sooner

Welcome to the forum orangutan; hope to hear from you more often!

In rFactor there is first these collision feelers (12 of them) then there is collision body that is low detail body model, I don't know everything from it, but those affect where and how contact is found, then there is high and low detail engines for parts that fell out, also every object has spring, damper and inertia + mass values.

In the end though the real cause is lag issues in that if the cars crash during a lag period they might jump to a collision state after the lag resolves and car position is no longer calculated but known. This creates forces that are too large and BOOM.

When a collision is detected it means the two car meshes have touched. It might be that when this happens there is a need to roll back the car positions until the point they touch and then calculate the forces.

This should stop the pinball issues as it means the mesh overlap will be calculated at the point of contact and not after the two cars are well inside each other caused by lag warp.

The feeler idea is interesting as well.

Quote from Hyperactive :

Quote from Tweaker :

Such a dumb argument.

As good as yours.

Oh? How is that? I at least give some logical explanation to why it happens. When most people say "oh, LFS isn't that great online because people go flying to the moon when they get hit". This is ridiculous to say, and it is so uncommon, it only makes such an argument seem less 'concrete' or true to fact. And with the situation, it is a given that lag situations can happen in ANY multiplayer game. So to say that a lag problem makes close racing impossible (thus deciding the game's netcode is crap) in its entirety is just an ignorant way of not looking at the whole picture. LFS plays perfectly fine with close racing and door-to-door action. I can't count the number of times I've been banging doors and bumpers while having a good race.

Orangutan, am I right to understand semi-impicit integration as a method of working in time steps, but once a collision is detected by one body sinking into the other, it tries to "roll back" to the moment of the crash and correct itself? If not, surely this is possible to some extent? With the physics running at 100Hz, and cars travelling at some 60m/s, that's a movement of 0.6m per time step, a pretty small distance. You could probably do a good estimation of when the colision actually happened from there, basically reversing the integration with a more accurate, implicit expression between the previous time step and the current one, and let the collision handling model handle the rest, as you described.

On the other hand, when racing online, inaccuracies can go as far as 30m in heavy lag situations at high speeds. Granted, at those speeds, the relative speed between the two cars will be much smaller at any case in most collisions, but is it not possible to again obtain an implicit expression describing both cars' motion reasonably well for a period of half a second close to the time of the collision (each PC does one for its own car), swap this over the network and only then calculate the collision? Atleast for collisions that appear major? Sure, you'd wait half a second between collision and effect, but atleast you didn't lose the race because of a collision that shouldn't have happened in the first place. I can't think of a situation where this would be more frustrating/problematic than the current method.

Hope I made some sense.

Quote :

Why do people always say this about LFS. Name a time when we've raced and one car goes "flying"

Happens all the time on autocross tracks. Bump into a barrier wrong and suddenly your car is doing somersaults. That's not an indictment of LFS -- we're all fans here, so there's no need to get defensive about it -- it's just a relevant observation when comparing LFS and rFactor. It's one area where LFS's physics, which are in most other respects superior to rFactor's, will need to be improved in order to support more motorsports and a mod community (eventually).

For instance, rFactor has a buggy mod. It's not very polished, but the point is that some guys threw together some buggie models, described the vehicles to rFactor, and it works. They drive like buggies. They never catch a tire wrong and go flying into the sky spinning like tops. I would much prefer to have such a mod in LFS (would gladly pay $50 for a track editor), but there are a few kinks to work out first before a mod community can just go nuts and not end up with wierd results. As it is now, if you try to build a ramp in the autocross editor and don't put the ramp planks close enough together, it becomes a space shuttle launching pad. ^_^

Quote from Eric Tetz :

Happens all the time on autocross tracks. Bump into a barrier wrong and suddenly your car is doing somersaults. That's not an indictment of LFS -- we're all fans here, so there's no need to get defensive about it -- it's just a relevant observation when comparing LFS and rFactor. It's one area where LFS's physics, which are in most other respects superior to rFactor's, will need to be improved in order to support more motorsports and a mod community (eventually).

For instance, rFactor has a buggy mod. It's not very polished, but the point is that some guys threw together some buggie models, described the vehicles to rFactor, and it works. They drive like buggies. They never catch a tire wrong and go flying into the sky spinning like tops. I would much prefer to have such a mod in LFS (would gladly pay $50 for a track editor), but there are a few kinks to work out first before a mod community can just go nuts and not end up with wierd results. As it is now, if you try to build a ramp in the autocross editor and don't put the ramp planks close enough together, it becomes a space shuttle launching pad. ^_^

I've said that hitting the barriers and other things is not connected to the lag issue. When they say a car goes flying into the sky from racing close to other opponents online, that is completely different. Hitting the barriers is not what we are talking about... because it is irrelevant.

It's hard to admit but I have... bought rFactor and I have to admit it isn't bad. Sure some mods are a bit odd but get some of the better ones (particuarly the Protoracer mod) and it feels very good indeed.

TBH rFactor with a 40 car (offline grid) runs faster than LFS for me (either 20 online or 12 offline) with a lot more detail, although LFS's graphics just have something about them that gives them an edge.

The physics really don't seem that bad, there are some areas where it may slip up but TBH LFS has still got massive gaps of its own, and frankly IMO perceptions of physics in any (hlaf decent) sim will always be based off the feedback it gives.

As for the FF it's ok(ish) nothing compared to LFS or N2003 but the vibrating in a straight line/when idling is annoying. The sound may be less informative but when on full throttle it just sounds awesome.

I haven't tested rF online yet and don't intend to because I feel LFS makes a far better online racer. Offline the collision model seems rock solid (I've yet to be flung anywhere by the physics LFS style) and the damage model feels a lot more polished. For those who have tried GTR/GTL/RACE and decided that's what the ISI engine offers then think again, I can't believe how different rF is to the SimBin crap.

One other thing I like... http://www.rfactorcentral.com/detail.cfm?ID=Nordschleife

Quote from Tweaker :

I've said that hitting the barriers and other things is not connected to the lag issue. When they say a car goes flying into the sky from racing close to other opponents online, that is completely different. Hitting the barriers is not what we are talking about... because it is irrelevant.

@ Tweak - I'd love to try your LFS because there is a serious issue with racing too close to each other in LFS, having said that LFS's damage model is at the same time far too lieneant on contact in single seaters.

Quote from Tweaker :

When they say a car goes flying into the sky from racing close to other opponents online, that is completely different. Hitting the barriers is not what we are talking about... because it is irrelevant.

You said yourself it happens, but it's "uncommon". Any differences between rFactor and LFS are relevant in a thread like this.

Quote from axus :

Orangutan, am I right to understand semi-impicit integration as a method of working in time steps, but once a collision is detected by one body sinking into the other, it tries to "roll back" to the moment of the crash and correct itself? If not, surely this is possible to some extent? With the physics running at 100Hz, and cars travelling at some 60m/s, that's a movement of 0.6m per time step, a pretty small distance. You could probably do a good estimation of when the colision actually happened from there, basically reversing the integration with a more accurate, implicit expression between the previous time step and the current one, and let the collision handling model handle the rest, as you described.

On the other hand, when racing online, inaccuracies can go as far as 30m in heavy lag situations at high speeds. Granted, at those speeds, the relative speed between the two cars will be much smaller at any case in most collisions, but is it not possible to again obtain an implicit expression describing both cars' motion reasonably well for a period of half a second close to the time of the collision (each PC does one for its own car), swap this over the network and only then calculate the collision? Atleast for collisions that appear major? Sure, you'd wait half a second between collision and effect, but atleast you didn't lose the race because of a collision that shouldn't have happened in the first place. I can't think of a situation where this would be more frustrating/problematic than the current method.

Hope I made some sense.

No, actually explicit/implicit/semi-implicit really refers to the the differential model
equation being solved per timestep, no matter what the adaptive stepping approach
taken.

Given s0 as the initial state vector (usually the position and velocity degrees of
freedom) and find s1 as the new state vector:
explicit Euler: s1 = s0 + ds0
implicit (backwards) Euler: s1 = s0 + ds1 (s1 is a function of its own derivative, hence a system solve)

Rolling back is a part of adaptive time stepping, whose steps can be solved using
any step integration method (well, almost...it gets trickier with step solvers that need
history, especially if they leverage fix step lengths).

An adaptive time stepper is problematic for real time. I use it for my non real time
collision detection and response, but it is inherently non deterministic in CPU time.
This means the game could easily get into situations where it would stutter. Plus
it is hard to imagine a clean way to step back in time when the players are
already reacting and interacting past the critical collision time...because note that
lag induced problems can put the critical collision time farther back than one
time step.

It would seem to me that a more robust way to resolve lag induced over
interpenetration is to either do what rfactor does (turn those collisions off), or to
limit the effective penetration depth; which is to say that the response on a given
time step will never be more than as if the collision is at some reasonable depth X.
This would effectively spread the resolution of an over deep collision out over time.

When I refer to "uncommon" I am talking about the racing Eric... bumper to bumper, door to door. Not about hitting barriers. Read read.

I know it happens when hitting barriers, but this isn't about that. :doh:

@ajp, sure just don't race on Redline racing or any other extremely laggy servers that people join just because it has a high count . If you choose any typical server but don't watch for ping or how smooth other drivers are before racing, feel free to go 'flying' all you want. Because from my own experience, having raced on many servers of my choosing, it pays off by not having any laggy situations. I've gone and played on "Pro Racing Room" which is an Aussie server, and the admins tell me I lag, and I can only assume this. And it is laggy at this time, because a lot of North Americans are connecting to their server, and it is causing accidents. Those kinds of things you need to avoid... then you wont get your flying cars.

And if we did have catpulting from tire to tire contact on the open wheelers, that would be normal. But tire contact isn't part of the game at all unfortuneately, it is wheel/rim & overall body contact. Imagine an indoor kart with bumpers surrounded on all sides... that is how it feels.

orangutan, you're crazzzy :faint:

Btw, rFactor loses it too after some speed is exceeded, damage you get to car is less visual as engine is not capable of calulating right amount of damage because hit happens too fast, then damage that happens can be almost anything. When watching replay at slow motion it gets then more damage.

But I don't know if it is possible to get better collision behaviour without sacrificing lot of performance.

Nice posts orangutan.

Two questions: what do you mean exactly by the term "pre-spin state"? Isn't it more or less the same as oversteer?

And do you know if any modern PC sims are using integration methods other than Euler. My impression has been that todays CPU's haven't made this possible yet or that some methods were just not worth it.

Here are two posts on the subject by the devs of Rigs of Rods and Racing Legends:
http://www.lfsforum.net/showthread.php?p=149882#post149882
http://www.lfsforum.net/showthread.php?p=149954#post149954

Quote from J.B. :

Nice posts orangutan.

Two questions: what do you mean exactly by the term "pre-spin state"? Isn't it more or less the same as oversteer?

And do you know if any modern PC sims are using integration methods other than Euler. My impression has been that todays CPU's haven't made this possible yet or that some methods were just not worth it.

Here are two posts on the subject by the devs of Rigs of Rods and Racing Legends:
http://www.lfsforum.net/showthread.php?p=149882#post149882
http://www.lfsforum.net/showthread.php?p=149954#post149954

Similar to oversteer using the definition of oversteer as the rear tires having a
greater slip angle than the fronts. However, this is different than the common
understanding of oversteer as 'loose' or 'not enough rear grip', since these imply
more of a setup condition as oppossed to a particular dynamic state. In practice,
I myself use the less formal later definition instead of the formal definition...hence
I differentiate by using a term like 'pre-spin'. In the case of rfactor, I therefore meant
'a high degree of formal-definition oversteer'.

Yes, I know of a few instances where semi-implicit integration is making its way into
games, but I know of no top shelf racing games. For example, I know some
secondary physics in the PS2 game Darkwatch are done this way (I know one of
the coders). Havok supports such integration, so I'm sure other games do it as well.
Any game that is using Qualoth cloth is using semi-implicit. I have an articulated
tree sitting in front of me right now simulating at about 100 fps with 737 branch
segments using backward euler with a biconjugate gradient solver (slower than
conjugate gradient but can handle a non-symetric system) on an opteron
275 (at work).

I agree with the position in those threads you posted that Euler is likely more
appropriate than RK4 for this application. Also, the difference in mod parameters
would likely be minimal between Euler and RK4. Backwards Euler changes that,
which makes is more relevent to know if it is being used. The question to me is
then: if/when will backwards Euler makes its way onto the real-time racing table?

Quote from Tweaker :

LFS plays perfectly fine with close racing and door-to-door action. I can't count the number of times I've been banging doors and bumpers while having a good race.

Well one thing is for sure, rFactor does door-to-door racing and rubbing on-line much better than LFS.

rFactor actually sends more date to your PC about the people closest to you, that's why it works so well. rF's net-code is way more advanced. In LFS all kinds of crazy things happen all the time, even with good ping/latency. I've been punted off the track at 5 times the speed by little tiny bumps more times in LFS than I care to remember, and it never happens in rF..

Maybe the physics behind collisions aren't better in rF, but the end results are way better. I've played both extensively, and that's my experience.

But when only six people play rF online it's hardly surprising there are less crashes

Interesting. I'm trying get a bit of an understanding of Backward Euler:

Quote from orangutan :

explicit Euler: s1 = s0 + ds0
implicit (backwards) Euler: s1 = s0 + ds1

So ds1 is the time derivative of s(t) at t=1 (to be multiplied by the time step I assume). But what is s(t) in a racing sim? I guess it can't really be a function since the external inputs to the simulation are always changing. Come to think of it, if this function were known there wouldn't be much point for any numerical integration would there? Is it an interpolated function calculated from known, past values?

Quote from Tweaker :

Besides, it is both lag and the model... but the reason for it all happening IS the lag in the first place. Because as you know when two cars are inside each other, like in Auto-X when you exit the garage or whatever..., they will fly apart when trying to break free.

The fact that 'dodgy' collisions occur in single player as well as multiplayer suggest that it is not lag that is the issue. Perhaps I didn't explain it well in my last post, but the problem of one car being inside another arises from the fact that the simulation must use discrete time steps to update itself. Basically we have a situation where there is no collision, we update to the next time step, and bang, one car is inside another. Lag in multiplayer effectively increases the size of the time step (making the problem worse), but it is not the source of the problem with collisions.

The real problem is how the model reacts when it detects that one car is inside another. I don't know what algorithm is used to generate the collision reaction forces that each car experiences, but that is not important. What is important is that it is not currently giving 'realistic' results.

If Overlap_Force > Reasonable_Force then Overlap_Force = Reasonable Force

Can you tell I'm crap at programming?

Quote from jtw62074 :

I'd like to just interject here for anyone interested that collision detection and response is an entirely separate area from the handling stuff. I'm perhaps unfortunately right now needing to rewrite my own collision detection/response system, which in no way effects how the car drives. The vehicle dynamics code that controls how a car moves when you haven't, err., I want to use an f word followed by "up" here but will be civil, "hit something," is entirely different and separate from what happens when you're out on the track and haven't hit something or somebody.

I did engineering at university and have done a lot of dynamics and finite element analysis and I don't see why this has to be the case. Am I overlooking something?

Perhaps it makes your model simpler, but there is no reason why an external 'collision force' cannot be added when a collision is detected. I believe that if your model cannot deal with such things then obviously you have oversimplified. Surely you can't assume away collisions when your model is supposed to be simulating cars that CAN crash into each other.

Quote from jtw62074 :

No vehicle handling software model intended to investigate handling and aid in an engineer's chassis design and setup job, even those that will absolutely reproduce results within the error margins of the data that can be collected (even within my wet dreams of Ferrari's F1 labs), is even remotely interested in what happens once the car has hit a wall or another car. Does this mean "the physics are wrong?" Well, it sure is wrong indeed once it hits a wall, because during the course of the computational studies the walls didn't exist in the first place, so it'll just run right through them. They don't care what happens when it hits a wall or another car. They want the car to react under driver inputs *exactly* as it would in reality. Period. If the driver hits another car or crashes, well, that's another problem for another study. That one will be concerned with crash safety instead.

This follows from what I said above. In the cases you describe here, the engineers are not interested in what happens when the car hits a wall as they're studying the (non-crash) vehicle dynamics. They're not making a computer game so why should they simulate something that they're not interested in?

Quote from orangutan :

Well written stuff about discrete time integration and its approximations.

While I agree with what you have said, I think that it is a minor point in this discussion. Although using more approximate integration methods can result in less realistic motion, on the scale and time frame that we are looking at I don't think that they are what is causing the cars to 'shoot off into space' (don't take that phrase seriously, I'm just being colourful).

I think that the problem is that the forces that are initially generated when the collision is detected are (orders of magnitude?) out. Following this argument, using semi-implicit integration to 'bleed energy from the system' is not a genuine solution. Again, without knowing how the forces are currently being generated I can only guess at how to remedy the problem.

P.S. Sorry for the 3 posts in a row, but I think it is neater to respond to each person individually. (I'm not trying to spam the forum.)

Quote from Peptis :

The fact that 'dodgy' collisions occur in single player as well as multiplayer suggest that it is not lag that is the issue.

Yes I know that the dodgy collisions can happen in either of the modes (hitting a car in SP doesn't send you flying, hitting barriers applies to everything), but I still don't think people understand what I've explained in previous posts. The fact that the lag online can create such morphing of cars when near each other, that is the whole reasoning for this.

I cannot understand why some of you guys still use barriers and curb clipping as examples of the flying, this is about the racing alongside another car when there is lag. Which in turn is the reason why this argument was made about rFactor's NETCODE vs. LFS's NETCODE when in close racing :doh:. Again, nothing to do with the barriers, curbs, or anything else that describes the collision model. If you've raced LFS over LAN at full 12 pps, you will see why I brought this up. It is super smooth and there is no flying cars the better the connections get. So all I can conclude is that laggy players (and there are quite a few that come and go in LFS) is the main cause of this. The collision model that allows the cars to fly is a given, but how it even starts in the first place is from lag... and LAG is such a debatable subject when it comes to judging the online play of a racing game. LFS can run great without any lag if you have everyone in the loop running smoothly.... and I play on servers that are like this more often than never.

If this still isn't clear, I give up.

Quote from Peptis :

I did engineering at university and have done a lot of dynamics and finite element analysis and I don't see why this has to be the case. Am I overlooking something?

Perhaps it makes your model simpler, but there is no reason why an external 'collision force' cannot be added when a collision is detected. I believe that if your model cannot deal with such things then obviously you have oversimplified. Surely you can't assume away collisions when your model is supposed to be simulating cars that CAN crash into each other.

i think what he meant is that collision detection and response is per se completely seperate from your normal vehicle dynamics code
of course after youve decided how to handle the collision and what forces need to be applied where they will be fed directly into the vehicle dynamics
so of course they interact (collision forces cause changes in the vehicle dynamics and vice versa) but the actual handling of what the car does and how you deal with a collision are seperate subjects