You guys are saying that the cars are flying or going "to the moon", I have never seen a car go UP from close-racing light lag contact online. If anything they will spin to the sides, but never go straight up to the sky :rolleyes:

Only times I've seen cars go straight up is from hitting the buggy barriers, or in destruction derby, were contact is hard enough and fast enough to actually make some strange things happen. And if there is lag online in LFS, it is usually one person causing such an accident. The lag comes from the car not being updated fast enough and it can slam into (or inside - like telefrag) a car when it 'appears' beside it. As far as I can recall, rFactor has a similar problem when someone is laggy, and their car skips all over the place too, causing accidents. It really is no different. The flying part is the phrase I am bugged about, because I haven't seen a car go flying unless it is from what I already described.

You have to consider that LFS is very lenient when it comes to slow hardware and the fact that it doesn't require much of a connection to play online. I played on 56k a long time ago, and was a bit laggy, but people played me just fine, and I never went 'flying'. And the fact that most of the reports of lag in LFS are from either the server chunking, low pps settings, or players with poor connections. LFS isn't entirely laggy or problematic with horrible laggy collisions... you have to take into account that those situations really only happen if the performance of anyone or anything is very low where you are playing online. It doesn't happen often, unless of course you choose to play on a server that you don't connect well too (even if you do, it doesn't mean some laggy person from the other side of the planet won't connect and cause mayhem)

I've always thought LFS was very good in this area. I never get shot off or anything like that. A light tap results as I'd expect it to. Maybe it's my system or connection helping

Quote from Tweaker :

You guys are saying that the cars are flying or going "to the moon", I have never seen a car go UP from close-racing light lag contact online. If anything they will spin to the sides, but never go straight up to the sky :rolleyes:

Maybe they don't do 200 m flights but too often some minor contact aftermath gets very bizarre.

Quote :

LFS isn't entirely laggy or problematic with horrible laggy collisions... you have to take into account that those situations really only happen if the performance of anyone or anything is very low where you are playing online. It doesn't happen often, unless of course you choose to play on a server that you don't connect well too (even if you do, it doesn't mean some laggy person from the other side of the planet won't connect and cause mayhem)

What are you talking about? Lag isn't the problem, maybe half of the problem because it obviously doesn't help this, but the problem is the whole collision model. Lag doesn't cause it because it happens in single player too. Drive a car into AI car at 250 km/h in singleplayer and see what happens...

Quote from deggis :

What are you talking about? Lag isn't the problem, maybe half of the problem because it obviously doesn't help this, but the problem is the whole collision model. Lag doesn't cause it because it happens in single player too. Drive a car into AI car at 250 km/h in singleplayer and see what happens...

If you have a car that is being flung to the side or "in the sky" it is not just the collision model. Cars are able to 'merge' into each other from a substantial amount of lag. If you've ever looked closely how it happens (down to each frame), you can see that once a car lags it will not appear for a brief moment, and then reappear as being blended into another car. Once this happens, it is like magnets that bounce away from each other (opposites attract, "likes repel").

The collision model is not entirely at fault when you put lag into the mix. And there is almost nothing we can do about it, because once someone lags, the car is updated as being in an entirely different position all of a sudden, and LFS can't really do any better than to let the laggy player be resuming from hiccups... even if next to (or inside) another car.

In singleplayer, multiplayer, it is all the same if you hit buggy walls, but what I am speaking of is an entirely different subject, and hardly related to the 'collision model'. This is about multiplayer connectivity.

i experienced this "magnet effect" during the race1 on westhill

Quote from Tweaker :

If you have a car that is being flung to the side or "in the sky" it is not just the collision model. Cars are able to 'merge' into each other from a substantial amount of lag. If you've ever looked closely how it happens (down to each frame), you can see that once a car lags it will not appear for a brief moment, and then reappear as being blended into another car. Once this happens, it is like magnets that bounce away from each other (opposites attract, "likes repel").

The collision model is not entirely at fault when you put lag into the mix. And there is almost nothing we can do about it, because once someone lags, the car is updated as being in an entirely different position all of a sudden, and LFS can't really do any better than to let the laggy player be resuming from hiccups... even if next to (or inside) another car.

In singleplayer, multiplayer, it is all the same if you hit buggy walls, but what I am speaking of is an entirely different subject, and hardly related to the 'collision model'. This is about multiplayer connectivity.

There is a problem with the collision model. If one car is inside another, then it should be obvious to the model that something has gone wrong, be it lag (multiplayer), too little time resolution (multiplayer and single-player), or whatever. The reason that one car is inside the other is not the issue here, the issue is what, as the physics model, should I do about it when I find one car inside the other?

Obviously, the repel like magnets approach isn't realistic. IRL you don't normally see two bodies occupying the same space as each other, so another approach must be taken. I have ideas on what could be done, but I won't present them here as they will cloud the real issue; I don't want people responding to my ideas, I just wanted to point out that there is something wrong with the physics model.

That being said, we all know that the physics model isn't finished. I have faith that the problem will not exist in S3.

Quote from Peptis :

There is a problem with the collision model.

I never said there isn't

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. When racing online next to someone, this same situation can mildly happen from just a bit of lag and the cars will morph together a little bit (or a lot) depending on how laggy it is. And having a low PPS setting (is required for some hosts that cannot handle enough packets being sent) at 6 pps, it is rather smooth, but you need to be playing on a good host, everyone have good/stable connections, and the gameplay is fine. Many servers use 4 pps to try and eliminate any lag, but it kind of makes things worse in my opinion. Most hosts should use 6 pps, and decrease the amount of slots to what they can support. This isn't uncommon, but with most public playing, anyone can come around in your server and make things unstable.

I don't know what else there would be to do other than make the cars even more "solid", in turn dissallowing the morhping of cars. But as I said, with lag, you can get a car being updated in one spot and then it can flash in another spot which is sometimes interwoven with another car. How that can be fixed, I have no idea, you have to make more of a compromise by making the netcode simpler and faster I'd imagine. And considering LFS is pretty darn accurate for watching clients online (a lot of car actions are fairly accurately seen as opposed to other simulations that have simple clients that appear to float and what not), there is a lot of updates needed to have a lot shown. We can only have a max grid of 22 people playing, and even before that Scawen was reluctant to increasing the amount because the game needs to have smoother connections from the server and its clients for the best play. I can only imagine that if we were to go with 40 people on the grid, the netcode we have currently would have to be greatly sacrificed in order for it to be as smooth as we need it.

I've just bought rFactor now that they have allowed you to play in demo mode before you buy and I have to say initial impressions are pretty good.

I like the sounds, track graphics and day/night transitions so far. This is all based on about a weeks worth of play though, so I need to give it time.

The sounds are good to a degree. I won't go into all the differences between LFS and rF sounds as that's been done to death, but from a new player to rF I will say that they sound great at slow and top speeds. They tend to get repetitive around the mid range though. All the other ambient sounds are good too - break squeal, tarmac sounds, track noise, gear box whine etc.

I was training in the single seater trainer the other night and this felt remarkably similar to the FOX. Again, great sense of speed (the shaking aids this I suppose) and the engine sounded good.

Graphics are good and bad IMO. Track texture, lighting, grandstands etc are all convincing. The day/night transitions are well done which doesn't seem to affect the FPS when racing at night. The cars do look cartoony though and don't have that believable feel about them like the LFS ones.

What I really don't like, like so many reports I've read is the way you can't recover from a slide. Unlike LFS it is very difficult to control a slide (or drift) without it snapping round and spinning you off the track. This gets very annoying when you sense it's happening, but then suddenly you're off.

I haven't tried online yet, so can't say about about the netcode, but I can see mismatches occuring. I've downloaded the Nurburgring only so far and enjoying a 20Km track for the first time.

Overall, so far not bad. I'll keep trying rF as it's early days, so it will be interesting to see how LFS feels when I try that again.

Quote from deggis :

Drive a car into AI car at 250 km/h in singleplayer and see what happens...

Driving to another car with such a great speed should split your car to half, or if it is race car it should bend and twist a lot causing useless shell of what used to be once a race car.

Hitting other car at 40kph should wreck front end, causing radiator to be lost and tire punctures caused by car structures moving inside rubber...

So hitting something at 250, that does not matter what it does currently, main thing is that your car should not be driveable at all after hit.

I find LFS is polling collisions at constant rate and that is too slow, sometimes you can hit something between this polls and it causes trouble.

I must say that I have never seen car to fly off or do anything weird when in typical reallife like racing contact happens, also I find multiplayer to be one of best and very tolerant to bad ping.
But bad thing in multiplayer is that if there is someone with bad connection, whole server seem to come jerky, luckily 56k is rarely seen nowdays.

Quote from Peptis :

There is a problem with the collision model. If one car is inside another, then it should be obvious to the model that something has gone wrong, be it lag (multiplayer), too little time resolution (multiplayer and single-player), or whatever. The reason that one car is inside the other is not the issue here, the issue is what, as the physics model, should I do about it when I find one car inside the other?

This defines when a collision has happened in reality. One thing has "touched" or is inside the other. If they weren't, they wouldn't be colliding.

Quote :

Obviously, the repel like magnets approach isn't realistic. IRL you don't normally see two bodies occupying the same space as each other, so another approach must be taken. I have ideas on what could be done, but I won't present them here as they will cloud the real issue; I don't want people responding to my ideas, I just wanted to point out that there is something wrong with the physics model.

I'd be interested in reading your ideas since I'm working on collision detection/response right now

Anyway, pending that, 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. The reaction once you have mucked up is in no way reflective on the accuracy of the behavior of the simulation in periods of time where you haven't. In fact, they are separate things entirely and you could write one completely without the other ever being present. (This same bit leads folks to thinking the physX chip might give better vehicle dynamics, come to think of it).

In other words, if you don't hit anything and just drive like the wind it could be 100% correct. Once you muck up you could go right through a wall like it didn't exist.

"The physics are wrong?"

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.

They're interested in the handling and that's explored and reproduced mathematically at, well, probably some sort of pretty high level The computer car never hits a wall. Perhaps the physics model for Pole Position, Asteroids, or Pac Man is better because it actually reacts to a collision while a Ferrari or Renault F1 custom handling simulation might ignore it and <gasp> drive straight through a wall.

Anyway, enough ranting here. For the die-hard "I want it to drive like the real thing" folks (like me), do not confuse the handling aspect with the collision aspect in any sim you ever run across. They are two totally, totally, totally separate things. One can suck completely or be non-existant and the other can be spot on. Just depends what you're interested in, really. You want to crash and have it react like the real thing? You want it to drive like a real car when you aren't crashing? Or do you want both?

To the average gamer a bit interested in a driving game, the perfect physics model would do both, but if one is deficient, the other might very well still be the very best you have to drive right now, and might be very, very good, even if it implodes here and there when you hit something (I never had this happen here, btw ).

Personally, I could give a rat's patootey what happens once I crash. Let it drive like the real thing would the other 15% of the time I'm driving The rest is a bonus. But the lack of it doesn't mean the other part isn't right. Really.

Flatout was really good at the crash/damage bit. Was very impressive to me. Flatout 2 is something I ought to check out as well.

Will be (or is now?) a good thing though for a sim when the die hard crowd's realism interest becomes focused on damage modelling than other things. Means everything else is right on

Anyway, night, guys..
(This post brought in part by Miller Lite :bananalla )

^ Yep, if you think about it, the collision model is actually a very complex thing on its own, and it works very very well in LFS. It seems that the mayor "explosions" only occur when the tyre contact points come into play - then things go haywire.

I still remember that video of a FOX league race (?) where everyone made the typical herd instinct error, where the first driver made a mistake and everyone behind follows, hence a stream of cars crashing into the wall. At the very end of the clip, you see a FOX that is turned upside down sliding along the ground, tilted in one direction because of the friction of the rollbar. Then, as the car comes to a stop, it tilts back into the position caused by gravity, looking very real doing so. Now just stop for a moment and try to wrap your mind around the mathematics and logic that is needed for even such a simple effect. Yes, LFS cars might fly around and act weird on collision, but if they do, they behave absolutely correct.

rigid body dynamics surely aren't *that* impressive Android? Some input data, some physics equations, calculate it x number of times a second...
making it *work* well though, that'd be impressive. Currently it just works, imho. Times like these I wish I could program, so I could see how my very straightforward sounding vector calculation / previous packets check would be so difficult to implement / cpu crunching to calculate / unworkable. Rather than judge collision intensity solely on 'depth of penetration', as I believe most rigid body calcs are done, calculate a vector for the colliding objects based on the current and previous packets. Packets would need to be timestamped though, I have no idea whether they are currently or not...

[offtopic] this is the longest thread in this forum isnt it? funny [/offtopic]
keep fighting :>

Quote from Blowtus :

Rigid body dynamics surely aren't *that* impressive Android?

In general? No. But compared to that ISI bullcrap (judging from videos)? Or to the "professional online racing simulator"? Definitely.

Quote from Blowtus :

Rather than judge collision intensity solely on 'depth of penetration', as I believe most rigid body calcs are done, calculate a vector for the colliding objects based on the current and previous packets. Packets would need to be timestamped though, I have no idea whether they are currently or not...

You'd still end up with some funkiness IMO when there's some sort of lag spike and the packets didn't initially arrive in order - I'd imagine that in any scenario/application-layer scheme some form of resynching with the server->other clients would be necessary to retain consistency.

I just think that if there was some sort of collision damping (simulating forces absorbed by the bodies involved), as has been mentioned before, most of the immediately visible weirdness would go away.

Quote from jtw62074 :

Long, very informative post

Always always always great to read your posts, Todd. It's really fun and informative to read posts on physics discussions from someone who's actually working on it. I'm sure I speak for the majority of the community when I say I hold you in the same esteem as the LFS Developers themselves.

While I'd never thought of the collision model and the physics model as two different things, it makes perfect sense. All one has to do is play Burnout to see this, the cars handle like they're on rails, not realistic at all, but the crashes are the best I've ever seen. I haven't played Flatout, but it looks to be the same way. Thanks for enlightening me

Quote from xaotik :

I just think that if there was some sort of collision damping (simulating forces absorbed by the bodies involved), as has been mentioned before, most of the immediately visible weirdness would go away.

The collision intensity due to lag issue would still be there, wouldn't it...? Damped, but still highly inaccurate I'd have thought...

Quote from Blowtus :

The collision intensity due to lag issue would still be there, wouldn't it...? Damped, but still highly inaccurate I'd have thought...

Yeah, surely - but atleast it would give some extra time to recalculate/resync instead of sending your car into orbit because someone tapped you and if that failed then it could just damage your car and send you off track in a less violent way.

Anyhow, I'm sure we'll see how it's properly done sometime in the future.

It would require only simple check, if vertices are inside other object then there has been something odd and collision would be turned off or car moved away or some better reaction?

But when I drive in single player, by gaining enough speed to hit I can see that collision is detected too late and when going slower collision is detected earlier, I can only think that here is some polling that checks collisions at certain times, 0.2 sec or something like that, maybe it would be possible to make low detail and high detail collision detection, object within 1m around car would activate 0.01sec polling, this way at least single player mode would get thing sorted, multiplayer would again need something more tweaks if ping/lag affects to detection routine as it sounds like.

Quote from Tweaker :

Why do people always say this about LFS. Name a time when we've raced and one car goes "flying" illepall If you want to hit each other head on, or play some destruction, then the hitting becomes a circus, but typical side-by-side racing happens all the time in LFS, I don't see people being catapulted into the sky, or even myself. Such a dumb argument.

It doesn't always result the cars thrown around or launched to moon. It is just the annoying fact that event he smallest touches can push the cars metres away from each others or anything bigger.

Quote from Tweaker :

Such a dumb argument.

As good as yours.

---
I guess the biggest difference why LFS collision detection is a bit twitchy while the rF's is not (never tried it in rfactor, the same "engine" is used in the other games too though) is that the rFactor engine has no physics involved when the cars collide. The cars just slide together, the cars have no friction with each others, they just slide against each others without almost anything happening in the cars' suspension, direction or speed. And if something happens it looks/feels/is totally silly. In LFS both cars get pushed aside, the wheels lose grip, the car may be realistically turned around, the suspension moves according to the forces pushing the car around. In short collisions in LFS look and feel exactly real. The bad thing these great physics are lost in multiplayer because the network code can't handle car collisions the same way as it can in single player mode.

As I said, moonflights are rare but as deggis said, it's more of lottery.

Quote from JTbo :

It would require only simple check, if vertices are inside other object then there has been something odd and collision would be turned off or car moved away or some better reaction?

Collisions are only flagged when objects become intermeshed - ie, 'vertices inside other object' happens every time you bump something. The severity is what differs...
I'm speaking only from a basic knowledge of collision detection, but LFS appears to work this way

Quote from JTbo :

I can only think that here is some polling that checks collisions at certain times, 0.2 sec or something like that, maybe it would be possible to make low detail and high detail collision detection, object within 1m around car would activate 0.01sec polling, this way at least single player mode would get thing sorted, multiplayer would again need something more tweaks if ping/lag affects to detection routine as it sounds like.

iirc the collision detection runs at 100hz in synch with the outer phyiscs loop

I tried Rfactor a while ago, but it is quite frankly crap. Its not like a simulator, its more of an arcade NFS type game. I worn anyone interested in getting it, DONT!!!

meh... thats not a very constructive post. but its how alot of people feel.

As has been said, collision detection and response are a different subsystem
from the articulated rigid body dynamics. However, note that there is a
semi-continuous collision happening with the tires and the ground most of the time,
which itself is usually a sort of third subsystem due to detailed tire models.

Underlying a lot of this is whether or not to time integrate explicitly, implicitly, or
semi-implicitly. To put it very simply, explicit costs less per timestep, can be pretty
high order accurate for cheap (RK4, etc), but simulation error injects energy into the
system. Think of a simple planetary orbit simulation. Explicitly integrated, the orbit
will expand over time. With too big of a timestep it will shoot away, just like some
LFS and GPL collisions. This can be patched over with damping (likely non-linear),
velocity caps, whatever.

True implicit integration is too CPU expensive for real time simulation. Semi-implicit
integration (basicly one iteration of implicit, linearizing with a Taylor expansion) is now
becoming real time viable on modern hardware. The bottom line is that
semi-implicit integration is more stable and its error bleeds energy from the system.
The orbit of the planet would decay. Extreme collisions could deaden (depending
on the collision response model). The main problem with semi-implicit is that
it requires correct Jacobians (think first derivatives) to setup a sparse system, and it
needs a sparse linear system solver (often preconditioned conjugate gradient).
Although conceptually simple, these things kinda work even when they are wrong,
so they can be tricky to get exactly right. Also, there is probably no way the AI
would get the same integration. Semi-implicit is still probably too CPU expensive
for that.

Anybody left? Why does this matter? Because this tidbit is fundamental in how
the dynamics, including both normal driving and collisions, inherently look and
feel when in the realm where numerical simulation error is not negligible, such as
real time gaming. I'd really like to know, especially in a moddable system like
rFactor or S3, what choices were made underneath for time integration. It would
affect directions one may investigate in things like mod tire parameters.

I write physical simulations myself for a CGI movie company (like cloth,
feathers, rigid bodies, fluids, etc). So to put a point on this, when artists try to
get silk out of my cloth solver, they cannot just put in silk material parameters...they
have to be mildly tweaked one way or another to get just the right look based on
whether they are using Euler (explicit) or BDF2 (semi-implicit) to solve.

The other reason I bring any of this up is to quash all this 'exactly right' so 'live
with it' talk. It is not exactly right. Only real atoms and all their emergent structures
do it exactly right. Tradeoffs are made. LFS makes some one way. rFactor makes
some another way. They also both make a lot of the same tradeoffs, which in the
big picture is why I think they are more similar than different. So they both
make compromises restricted by the resources available.