I've been known to do that at 32 years old
Warning: Ridiculously long post here. Got carried away. Basically they're some thoughts on collision detection/response in general as well as a bit about online implementation challenges that perhaps some might find interesting. If not, skip it and carry on 
There are quite a lot of things to look at in collision detection/response, especially in the case of online racing. Make no mistake about it, this is a very tricky thing to pull off and in my opinion LFS does an impressive job of it. As does rFactor.
Maybe I can clarify a couple of things here into separate areas.
First, looking at pure collision detection without the online lag aspect. I.e., during offline racing when you hit a wall or an AI car or something.
There are a few approaches to solving the problem which can depend a bit on what sort of collision primitives you're using and whether you're doing a dynamic versus static test (made up terms just now for discussion). A static test is one where you take two objects "now" in the simulation and see if they are interpenetrating. If they are, you do the collision "response" which itself can be done a few different ways. I.e., in the Grand Turismo series and Ferrari 355 Challenge the "response" is simply to move the cars apart from each other a little bit so they are no longer colliding. They don't bounce off each other one bit (not that I've noticed). A more typical way is to add a force so that they bounce apart. Yet another way is to use a combination of the two. More on this later.
About the "now" part mentioned earlier. One further step some systems do is to backtrack the motion of the objects and see where they were a 1/2 time step ago. If they weren't hitting then, then you go forward a 1/4 time step, then back or forth an 1/8, etc., until you find a reasonably close point and time of collision. This can be fairly expensive for the CPU to do and is probably not necessary in a car racing sim. I don't do this in my engine because I have another way of taking care of the interpenetrations (I'm working on it now, so perhaps it will be horrible. We'll see).
On to the collision primitives. If you use the actual car mesh to do collision detection you are looking at checking a triangle against another triangle. When you roll slowly into a wall and the left front bumper hits it, you'll see it. This can be very slow though due to the shear number of triangles involved so is probably not very common in racing sims. You can improve this by breaking the triangles down into sections outlined by invisible boxes that are checked first though, which greatly reduces the number of triangle checks.
Another way of doing it is to use other sorts of primitives like boxes. I.e., the car "mesh" that collides with something in the physics engine is not literally the body of the car, but rather a series of boxes that wrap around it and fit it as tightly as possible. Even though a little part of the car mesh might be touching something, the boxes aren't, so there's no collision. This is a little bit on a tangent from what you guys are discussing, but since we're on the subject I thought it might be interesting to throw out there. The point is that in some sims where two wheels might be touching each other and yet don't effect anything, this might be why. It's not necessarily an inherent flaw in this type of system though. It might just be that the creators didn't make boxes for the tires. It becomes sort of an art issue at that point rather than something wrong with the engine. I.e., a modder might be able to fix it himself.
BANG! Ok, our "collision detection" has determined that a car has hit something. What now?
Typically what you do is find a collision point somewhere. The actual volumes are interpenetrating so you need to come up with a point in there somewhere to apply a force to. Then, you can find the velocity along the "collision normal" (finding that can be tricky too). I.e., if a ball is tossed onto a flat table, the collision normal points straight up. It's just a vector (think of it as an invisible ray) that might be perpendicular to the surface that was hit.
Now, when a rigid body hits something and there is no energy absorption at all and no friction, the collision point's velocity is reflected along that collision normal vector. I.e., some force or impulse is applied to that point in the direction of the collision normal.
Calculating this force or impulse can be done a couple of different ways, but the gist of it is you're trying to answer, "what force/impulse, when applied along the collision normal, will make that collision point reflect off with the opposite velocity it had coming in?"
To absorb whatever percentage of energy you want all you need to do is multiply that by 0 through 1, so that's just a variable you can change somewhere in the system or model, most likely. (In my stuff it's just a variable in the source code). This 0 through 1 number is called the "coefficient of restitution."
Ok, what this force or impulse does is cause the objects to bounce off each other. The ball hits the table and bounces back upwards. However, there's an additional here: At that time step where you applied the force to reflect the velocity of the collision point, you did not actually move anything. On the next time step, the objects might still be interpenetrating. Fixing the interpenetration is another area. If you don't do anything about that, then what's likely to happen is the collision detection sees on the next step that they're touching, only this time in the opposite direction. Now a new collision force/impulse is applied to reflect the velocity, only this time it pushes the objects back together, resulting in another opposite reflection.
Back and forth, back and forth. The end result is that if the objects hit each other hard enough (more appropriately, "fast enough"), they might stick together and vibrate. This doesn't happen in LFS or any racing sim I've ever seen, so it's very likely that something is in fact being done about penetration, either by preventing it from happening in the first place (the stepping backwards in time mentioned earlier), or fixing it after it has happened (which is what I'm working on).
In short, on top of the force that reflects the velocity, you can calculate another force that will fix the interpenetration. This would in fact scale with the penetration depth. The linear and angular momentum change caused by this extra impulse needs to be subtracted/negated on the next time step, otherwise you can get a huge extra kick on top of what you should have had just due to the impact velocity. Scaling the impulse down just a touch or limiting it somehow is not a bad idea either. If the penetration is fixed over a few physics engine cycles you probably won't see it.
Because the collision detection process itself might yield a strange collision point at some orientations (perhaps a box primitive that's nearly perpendicular to a wall and close to one of the triangle verticies in that wall, for example), the interpenetration that is calculated might be way, way in excess of what it is in reality. If you're using a method like I am to fix the penetration, you might give the car a HUGE impulse to fix the penetration. If you do not subtract that momentum change on the next step, the car is blasted to the moon...
My guess is that something along these lines happens with the barriers at the autocross track in LFS.
_________________________
Now, going to the online situation. This gets really messy and I have not done it myself yet except in Virtual RC Racing, where I used a very simple collision system indeed and the only online bit was on a LAN where there's no latency at all and we can send packets back and forth every single graphics frame. Collisions work just great on a LAN in VRC. If the collision velocity is more than some amount, there is no penetration correction force applied at all. At high velocities the reflection stuff will usually cause the cars to bounce apart from each other so I don't calculate it there. In this case it's as others here mentioned where the reflection velocity, mass, and all that stuff is the sole factor that determines the force. It works pretty well.
Introduce lag into this picture as well as being restricted to a pitifully low number of packets that can be sent every second. If I'm not mistaken, most online racing sims send only 5-10 updates or so every second. Yikes... Now you're sitting in your physics engine running at 50 or more times that speed and are attempting to figure out if two cars hit each other now, or on step 20, 30, etc.. It's tricky
If you're playing Billy online and are getting only 5 updates per second telling you where he is, you have to do something in between times. Otherwise the car shows up and the position is updated only 5 times per second. This shows up as a wildly stuttering car that's an unrecognizable mess. Really, really bad. This even looks horrible at 40 updates per second (I've done it).
In short, you need to artificially move his car somehow in between times. This is where racing sims often differ a bit in how the online aspect appears. The most cpu friendly way is to smooth the motion somehow. "Dead reckoning" is the most simple way. In the last packet you received you had Billy's position, but if you also included his velocity, you could interpolate between graphics frames, moving Billy's car around so at your 50fps his car is still moving even though you only know for sure where he actually is every 10 graphics frames.
Introduce a big lag spike. For 0.25 seconds due to a network stutter or something you get no update at all from Billy. He continues moving right along at the speed he was going 0.25 seconds ago on your computer, then suddenly his update comes in and his car jumps a few feet to his actual position. This is basically why in (most?) sims you see the cars moving smoothly, but also jumping just a tiny bit here or there a few times per second. rFactor has none of this at all and is the smoothest I've seen, but I must admit that I'd rather have a bit of minute jumping here and there than see some of the things I see there. Primarily they don't appear to interpolate the cars' rotations in a way that matches up with the translation. I.e., if they projected the rotation interpolation forward in time and used that instead (if they really aren't already), it would probably look a lot better.
To minimize this jumping in VRC I restricted the distance that the car could move per graphics frame. I.e., if due to a little lag spike or something Billy's position should be corrected 2 feet to the right, I might only let it move 0.25 feet. Eventually within a few graphics frames it slowly moves over to about the right spot. Your representation of Billy's car is always sort of chasing his actual position down. This is how it appears to work in rFactor too. You could, however, say that if the update position is really huge, don't bother smoothing it, just pop the car back where it's supposed to be and carry on. This appears very smooth with no jumping at all, but when you have a really big lag spike occur of a second or two, the car doesn't just jump back to the right spot like it does in LFS. Instead, it zooms very quickly over to that position and continues on its way. This is how it appears to work in rFactor where you get "fast forwarding" instead of a sudden teleport to the correct position. Keep in mind that the programmer here is supposed to be magically figuring out what the other guy did with his controls some time ago without the information having been sent yet. God forbid if the other guy actually hit something during that period and was sent off in a totally different direction than you know about yet. Tricky problem
Another way is to let the physics engine run for the other nearby cars. I.e., Billy's car position, throttle and steering inputs, and so on, are sent to you and you treat him like an AI car (with or without the actual AI driving) in the mean time. The car rolls along, the suspension is moving the car around, and so on. This is what appears to happen in LFS. I must admit it looks very good and is very convincing. It requires more CPU time to do, but it works well in LFS on my system. A minor improvement in LFS might be to use a hybrid of the two by allowing a tiny bit of position/orientation interpolation to be done on top of the running physics to minimize the jumping. Although I must admit that when actually driving, I don't see any jumping at all. From TV cam mode it's a bit more apparent, but not a major deal to me at all and I hardly ever notice it.
These two approaches both have their pros and cons. Collision detection without any network involvement at all is a serious b*tch to get right. Add in network stuff and woooaahoooaaaa, Nelly! On your computer Bily's car may appear to be touching yours due to the dead reckoning or whatever smoothing algorithm you're using, but on Billy's computer you might not be touching him. So how do you determine if a collision has happened in this case? You're all familiar with this I'm sure in one sim or another where a bit of lag causes you to hit somebody else when you swear you didn't really hit him at all. Well, you did on his computer and you didn't on yours, so you're both right If someone would kindly remove the speed of light barrier it would make all this stuff much easier
Once you did determine that there was a collision online, you're solving the same problem as you do offline. You calculate an impulse and apply it equally/oppositely to both cars due to velocity, and depending on how you do things, you might also do an additional impulse to eliminate the penetration. If you do this *before* you render the graphics you theoretically won't see the penetration offline, but due to the network issues it is somewhat inevitable otherwise unless both systems give their cars different impulses. And you better subtract that momentum change that the penetration impulse gave on the next cycle or else large penetrations will shoot you to the moon, and even small ones can introduce energy into the system that shouldn't be there.
My guess is that subtracting this momentum change might not be done in LFS. If it isn't, it's a pretty easy fix. Chances are though it's more complex than that. The collision point itself might be wrong in some situations. I haven't licked that one myself just yet even for a simple box touching a triangle, so don't have much to say there.
Anyway, as said before, this whole area has nothing to do with the rest of the physics model, the car's handling, and so on. It is indeed a part of the physics model of course because you're just adding another force or impulse into it, but calculating that force vector and application point is a different algorithm and doesn't say anything about any other part of the physics engine.
Basically they're some thoughts on collision detection/response in general as well as a bit about online implementation challenges that perhaps some might find interesting. If not, skip it and carry on There are quite a lot of things to look at in collision detection/response, especially in the case of online racing. Make no mistake about it, this is a very tricky thing to pull off and in my opinion LFS does an impressive job of it. As does rFactor.
Maybe I can clarify a couple of things here into separate areas.
First, looking at pure collision detection without the online lag aspect. I.e., during offline racing when you hit a wall or an AI car or something.
There are a few approaches to solving the problem which can depend a bit on what sort of collision primitives you're using and whether you're doing a dynamic versus static test (made up terms just now for discussion). A static test is one where you take two objects "now" in the simulation and see if they are interpenetrating. If they are, you do the collision "response" which itself can be done a few different ways. I.e., in the Grand Turismo series and Ferrari 355 Challenge the "response" is simply to move the cars apart from each other a little bit so they are no longer colliding. They don't bounce off each other one bit (not that I've noticed). A more typical way is to add a force so that they bounce apart. Yet another way is to use a combination of the two. More on this later.
About the "now" part mentioned earlier. One further step some systems do is to backtrack the motion of the objects and see where they were a 1/2 time step ago. If they weren't hitting then, then you go forward a 1/4 time step, then back or forth an 1/8, etc., until you find a reasonably close point and time of collision. This can be fairly expensive for the CPU to do and is probably not necessary in a car racing sim. I don't do this in my engine because I have another way of taking care of the interpenetrations (I'm working on it now, so perhaps it will be horrible. We'll see).
On to the collision primitives. If you use the actual car mesh to do collision detection you are looking at checking a triangle against another triangle. When you roll slowly into a wall and the left front bumper hits it, you'll see it. This can be very slow though due to the shear number of triangles involved so is probably not very common in racing sims. You can improve this by breaking the triangles down into sections outlined by invisible boxes that are checked first though, which greatly reduces the number of triangle checks.
Another way of doing it is to use other sorts of primitives like boxes. I.e., the car "mesh" that collides with something in the physics engine is not literally the body of the car, but rather a series of boxes that wrap around it and fit it as tightly as possible. Even though a little part of the car mesh might be touching something, the boxes aren't, so there's no collision. This is a little bit on a tangent from what you guys are discussing, but since we're on the subject I thought it might be interesting to throw out there. The point is that in some sims where two wheels might be touching each other and yet don't effect anything, this might be why. It's not necessarily an inherent flaw in this type of system though. It might just be that the creators didn't make boxes for the tires. It becomes sort of an art issue at that point rather than something wrong with the engine. I.e., a modder might be able to fix it himself.
BANG! Ok, our "collision detection" has determined that a car has hit something. What now?
Typically what you do is find a collision point somewhere. The actual volumes are interpenetrating so you need to come up with a point in there somewhere to apply a force to. Then, you can find the velocity along the "collision normal" (finding that can be tricky too). I.e., if a ball is tossed onto a flat table, the collision normal points straight up. It's just a vector (think of it as an invisible ray) that might be perpendicular to the surface that was hit.
Now, when a rigid body hits something and there is no energy absorption at all and no friction, the collision point's velocity is reflected along that collision normal vector. I.e., some force or impulse is applied to that point in the direction of the collision normal.
Calculating this force or impulse can be done a couple of different ways, but the gist of it is you're trying to answer, "what force/impulse, when applied along the collision normal, will make that collision point reflect off with the opposite velocity it had coming in?"
To absorb whatever percentage of energy you want all you need to do is multiply that by 0 through 1, so that's just a variable you can change somewhere in the system or model, most likely. (In my stuff it's just a variable in the source code). This 0 through 1 number is called the "coefficient of restitution."
Ok, what this force or impulse does is cause the objects to bounce off each other. The ball hits the table and bounces back upwards. However, there's an additional here: At that time step where you applied the force to reflect the velocity of the collision point, you did not actually move anything. On the next time step, the objects might still be interpenetrating. Fixing the interpenetration is another area. If you don't do anything about that, then what's likely to happen is the collision detection sees on the next step that they're touching, only this time in the opposite direction. Now a new collision force/impulse is applied to reflect the velocity, only this time it pushes the objects back together, resulting in another opposite reflection.
Back and forth, back and forth. The end result is that if the objects hit each other hard enough (more appropriately, "fast enough"), they might stick together and vibrate. This doesn't happen in LFS or any racing sim I've ever seen, so it's very likely that something is in fact being done about penetration, either by preventing it from happening in the first place (the stepping backwards in time mentioned earlier), or fixing it after it has happened (which is what I'm working on).
In short, on top of the force that reflects the velocity, you can calculate another force that will fix the interpenetration. This would in fact scale with the penetration depth. The linear and angular momentum change caused by this extra impulse needs to be subtracted/negated on the next time step, otherwise you can get a huge extra kick on top of what you should have had just due to the impact velocity. Scaling the impulse down just a touch or limiting it somehow is not a bad idea either. If the penetration is fixed over a few physics engine cycles you probably won't see it.
Because the collision detection process itself might yield a strange collision point at some orientations (perhaps a box primitive that's nearly perpendicular to a wall and close to one of the triangle verticies in that wall, for example), the interpenetration that is calculated might be way, way in excess of what it is in reality. If you're using a method like I am to fix the penetration, you might give the car a HUGE impulse to fix the penetration. If you do not subtract that momentum change on the next step, the car is blasted to the moon...
My guess is that something along these lines happens with the barriers at the autocross track in LFS.
_________________________
Now, going to the online situation. This gets really messy and I have not done it myself yet except in Virtual RC Racing, where I used a very simple collision system indeed and the only online bit was on a LAN where there's no latency at all and we can send packets back and forth every single graphics frame. Collisions work just great on a LAN in VRC. If the collision velocity is more than some amount, there is no penetration correction force applied at all. At high velocities the reflection stuff will usually cause the cars to bounce apart from each other so I don't calculate it there. In this case it's as others here mentioned where the reflection velocity, mass, and all that stuff is the sole factor that determines the force. It works pretty well.
Introduce lag into this picture as well as being restricted to a pitifully low number of packets that can be sent every second. If I'm not mistaken, most online racing sims send only 5-10 updates or so every second. Yikes... Now you're sitting in your physics engine running at 50 or more times that speed and are attempting to figure out if two cars hit each other now, or on step 20, 30, etc.. It's tricky
If you're playing Billy online and are getting only 5 updates per second telling you where he is, you have to do something in between times. Otherwise the car shows up and the position is updated only 5 times per second. This shows up as a wildly stuttering car that's an unrecognizable mess. Really, really bad. This even looks horrible at 40 updates per second (I've done it).
In short, you need to artificially move his car somehow in between times. This is where racing sims often differ a bit in how the online aspect appears. The most cpu friendly way is to smooth the motion somehow. "Dead reckoning" is the most simple way. In the last packet you received you had Billy's position, but if you also included his velocity, you could interpolate between graphics frames, moving Billy's car around so at your 50fps his car is still moving even though you only know for sure where he actually is every 10 graphics frames.
Introduce a big lag spike. For 0.25 seconds due to a network stutter or something you get no update at all from Billy. He continues moving right along at the speed he was going 0.25 seconds ago on your computer, then suddenly his update comes in and his car jumps a few feet to his actual position. This is basically why in (most?) sims you see the cars moving smoothly, but also jumping just a tiny bit here or there a few times per second. rFactor has none of this at all and is the smoothest I've seen, but I must admit that I'd rather have a bit of minute jumping here and there than see some of the things I see there. Primarily they don't appear to interpolate the cars' rotations in a way that matches up with the translation. I.e., if they projected the rotation interpolation forward in time and used that instead (if they really aren't already), it would probably look a lot better.
To minimize this jumping in VRC I restricted the distance that the car could move per graphics frame. I.e., if due to a little lag spike or something Billy's position should be corrected 2 feet to the right, I might only let it move 0.25 feet. Eventually within a few graphics frames it slowly moves over to about the right spot. Your representation of Billy's car is always sort of chasing his actual position down. This is how it appears to work in rFactor too. You could, however, say that if the update position is really huge, don't bother smoothing it, just pop the car back where it's supposed to be and carry on. This appears very smooth with no jumping at all, but when you have a really big lag spike occur of a second or two, the car doesn't just jump back to the right spot like it does in LFS. Instead, it zooms very quickly over to that position and continues on its way. This is how it appears to work in rFactor where you get "fast forwarding" instead of a sudden teleport to the correct position. Keep in mind that the programmer here is supposed to be magically figuring out what the other guy did with his controls some time ago without the information having been sent yet. God forbid if the other guy actually hit something during that period and was sent off in a totally different direction than you know about yet. Tricky problem
Another way is to let the physics engine run for the other nearby cars. I.e., Billy's car position, throttle and steering inputs, and so on, are sent to you and you treat him like an AI car (with or without the actual AI driving) in the mean time. The car rolls along, the suspension is moving the car around, and so on. This is what appears to happen in LFS. I must admit it looks very good and is very convincing. It requires more CPU time to do, but it works well in LFS on my system. A minor improvement in LFS might be to use a hybrid of the two by allowing a tiny bit of position/orientation interpolation to be done on top of the running physics to minimize the jumping. Although I must admit that when actually driving, I don't see any jumping at all. From TV cam mode it's a bit more apparent, but not a major deal to me at all and I hardly ever notice it.
These two approaches both have their pros and cons. Collision detection without any network involvement at all is a serious b*tch to get right. Add in network stuff and woooaahoooaaaa, Nelly!
On your computer Bily's car may appear to be touching yours due to the dead reckoning or whatever smoothing algorithm you're using, but on Billy's computer you might not be touching him. So how do you determine if a collision has happened in this case? You're all familiar with this I'm sure in one sim or another where a bit of lag causes you to hit somebody else when you swear you didn't really hit him at all. Well, you did on his computer and you didn't on yours, so you're both right If someone would kindly remove the speed of light barrier it would make all this stuff much easier Once you did determine that there was a collision online, you're solving the same problem as you do offline. You calculate an impulse and apply it equally/oppositely to both cars due to velocity, and depending on how you do things, you might also do an additional impulse to eliminate the penetration. If you do this *before* you render the graphics you theoretically won't see the penetration offline, but due to the network issues it is somewhat inevitable otherwise unless both systems give their cars different impulses. And you better subtract that momentum change that the penetration impulse gave on the next cycle or else large penetrations will shoot you to the moon, and even small ones can introduce energy into the system that shouldn't be there.
My guess is that subtracting this momentum change might not be done in LFS. If it isn't, it's a pretty easy fix. Chances are though it's more complex than that. The collision point itself might be wrong in some situations. I haven't licked that one myself just yet even for a simple box touching a triangle, so don't have much to say there.
Anyway, as said before, this whole area has nothing to do with the rest of the physics model, the car's handling, and so on. It is indeed a part of the physics model of course because you're just adding another force or impulse into it, but calculating that force vector and application point is a different algorithm and doesn't say anything about any other part of the physics engine.
Last edited by jtw62074, .
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.
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 )
Last edited by jtw62074, .
Pieter Bervoets showed me in car vids of him running at Spa in his Donkervoort (similar to an LX6, but twice as powerful). The slip streaming was quite strong, I'd say quite a bit more than what we have now in LFS. He was running lap after lap with another guy and they swapped the lead on the big straight after Eau Rouge easily every lap. In fact, they'd wave each other by each time. Just made the both of them faster so they could pull away from the pack.
I'd personally like to see a bit stronger effect in LFS. Not as strong as it used to be, but maybe 1/4 or 1/3 of the way between what we have now and what it was.
I don't really like having much downforce loss, but if a little bit is realistic, then go for it. Just please don't make me spin out like used to happen in the F08 at the oval
I'd personally like to see a bit stronger effect in LFS. Not as strong as it used to be, but maybe 1/4 or 1/3 of the way between what we have now and what it was.
I don't really like having much downforce loss, but if a little bit is realistic, then go for it. Just please don't make me spin out like used to happen in the F08 at the oval
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 
Memorize the heck out of the track The video isn't as clear as it is on my monitor of course. That was actually 1280x1024 res with no video compression or anything, so the corners aren't really as totally blind as they look.
The video isn't as clear as it is on my monitor of course. That was actually 1280x1024 res with no video compression or anything, so the corners aren't really as totally blind as they look.I can assure you it's most certainly not dead by any stretch of the imagination
I spent a few days at Gregor Veble's house perhaps three or four weeks ago driving the physics engine for Racing Legends, have worked with Tony for the past couple of years on VRC, and had a nice dinner with Chris and Tony at a show in Birmingham. We all chat daily. It's most certainly real and being worked on every day as it has been all along. The web site hasn't been and won't be updated in a long time, that's all. Doesn't mean Chris and Gregor aren't still coding. They'll use something of mine in there too, so I'm counting on it a bit more than you might be Doing such a car is indeed a good physics test. I tried this in mine and it worked quite well. Even ripped GPL's sounds and one of the backgrounds for it
http://www.performancesimulations.com/files/ToddSimGPL1.wmv
Would be interesting to try it in LFS too though, for sure.
I like Deggis' sample there. Good job!
I haven't read the whole thread so pardon me if I say something that is old news already. I'm not suprised really if somebody becomes faster with improved engine sound included. The immersion factor can really help a lot of people. Some of us would be faster that way, others not. I suspect for me it wouldn't make much difference since I'm quite a visually oriented driver, but who knows? I know in my sim it somehow feels different when I change sounds. Not the handling of course, but the general feeling and how I drive can be influenced a bit by that. When the engine is really knarly and beefy sounding I tend to operate the throttle a little differently (I get scared ).
Anyway, it wouldn't suprise me to see someone go faster with different sounds. Two seconds is quite a lot though. That is suprising.
I haven't read the whole thread so pardon me if I say something that is old news already. I'm not suprised really if somebody becomes faster with improved engine sound included. The immersion factor can really help a lot of people. Some of us would be faster that way, others not. I suspect for me it wouldn't make much difference since I'm quite a visually oriented driver, but who knows? I know in my sim it somehow feels different when I change sounds. Not the handling of course, but the general feeling and how I drive can be influenced a bit by that. When the engine is really knarly and beefy sounding I tend to operate the throttle a little differently (I get scared
). Anyway, it wouldn't suprise me to see someone go faster with different sounds. Two seconds is quite a lot though. That is suprising.
I don't have the picture handy, but someone sent me one a few weeks ago of a car that was modified to have a really huge steering angle. From the picture it looked to be 60 or 70 degrees. Again, that's not a stock car though.
I agree that one probably shouldn't require a ton of steering lock for drifting. As long as the car is understeer over the limit, it will straighten itself up in time regardless of the steering lock you use. It just takes longer if you can't crank it way, way out there
I agree that one probably shouldn't require a ton of steering lock for drifting. As long as the car is understeer over the limit, it will straighten itself up in time regardless of the steering lock you use. It just takes longer if you can't crank it way, way out there
While in Zaandvoort watching the A1GP qualifiers a week ago or so I went by a sim display area at the track. The guy had a set of Logitech FFB pedals on display there, so they are indeed coming. I told him I was a sim developer so he let me take a picture provided I didn't post it online anywhere. He wasn't supposed to have it on display, but couldn't resist the temptation I suppose
All three pedals are FFB. This is a new Logitech product due out in November according to the gentleman at the display.
All three pedals are FFB. This is a new Logitech product due out in November according to the gentleman at the display.
Bump mapping a road surface can look good, but it can also make it look worse. In a very early version of Virtual RC Racing we had bump mapping on the track, which looked kind of neat, but in the end we got rid of it as it sort of looked "marble-y". Maybe we just didn't do it properly or spend enough time on it (Tony West wasn't working with us yet at that point; had he done it maybe it would have looked great). Anyway, the pure texture without it looked a lot better. Not to say that other effects might not be very cool though of course!
Shaders are definitely cool though and not something that's too terribly difficult or time consuming to include. I've experiment a *tiny* bit with a shader in OpenGL and it really was fairly straightforward. Once you initialize/compile them as the program is running, you pretty much just turn them on and off and then begin rendering. All the shaders I've seen (I bought a book on them) were rather short. I was quite surprised.
But anyway, this isn't something that would probably take a year to do
EDIT: I'm don't have LFS on this computer (I'm Slovakia working on a notebook right now) so can't check, but it seems to me there were reflections on the cars of the surrounding world. Am I remembering wrong and imagining things? If so, that's probably a shader right there already.. If not, well, errr.... Nevermind :spin:
Shaders are definitely cool though and not something that's too terribly difficult or time consuming to include. I've experiment a *tiny* bit with a shader in OpenGL and it really was fairly straightforward. Once you initialize/compile them as the program is running, you pretty much just turn them on and off and then begin rendering. All the shaders I've seen (I bought a book on them) were rather short. I was quite surprised.
But anyway, this isn't something that would probably take a year to do
EDIT: I'm don't have LFS on this computer (I'm Slovakia working on a notebook right now) so can't check, but it seems to me there were reflections on the cars of the surrounding world. Am I remembering wrong and imagining things? If so, that's probably a shader right there already.. If not, well, errr.... Nevermind :spin:
Last edited by jtw62074, .
No problem, I was quite flattered by the notion actually, so thanks
In order for somebody else to listen to it I had to record it somehow of course. Either that or pop the program in here which I preferred not to do.
I see. Quite frankly, I wasn't sure what I was really looking at in that graph you displayed.
Yeah, there is a high pitched ringing there at idle. This is actually a resonance phenomenon happening in the exhaust system that's causing it. It can be tuned out pretty easily though.Thanks for the kind words, everyone.
[edit] Oh, and the spelling I always knew was apostrophe
Kraftwerk! Ah, yes.
Remember "Breakin'?" This tune sound familiar?http://www.performancesimulations.com/files/ToddSim7a.wmv
One of my all time favorites for sure
FMOD (instead of DirectSound) has DSP filters that I think can probably do all this sort of thing in real time, so it might be possible.
Doh, fixed CPU/GPU #2, thanks Axus and Askoff
Ah, yes, thanks. Fixed the error so the post should be correct now
And yes, load balancing is important indeed. Right now generally the vertex shader in a game is sitting around doing nothing for the most part, so there's probably plenty there to exploit.
And yes, load balancing is important indeed. Right now generally the vertex shader in a game is sitting around doing nothing for the most part, so there's probably plenty there to exploit.
They're indeed working on this type of thing. From what I've heard, at least one of the companies is releasing an SDK that makes this type of thing easier to do. Actually, it might already be out for beta at this point, but I'm not sure about that.
Matrix and vector calcs can be done in 1 cycle, so it's just insanely fast. A matrix multiplication is probably 200 times faster on the graphics card than the CPU (edited, thanks Axus ), so there ought to be plenty of power there. Granted, when we all are running quad+core CPUs this may not be necessary, but it's an interesting area anyway. I've seen some physics stuff done on a GPU. One particular example was an audio system that was essentially doing live ray-tracing so a sound source in a maze would be pretty accurately altered by the walls and so on, so you get multiple reflections and all that. Runs in real time too because it's mostly done on the GPU, but there's no way it would even come close to running on a CPU.
Matrix and vector calcs can be done in 1 cycle, so it's just insanely fast. A matrix multiplication is probably 200 times faster on the graphics card than the CPU (edited, thanks Axus
), so there ought to be plenty of power there. Granted, when we all are running quad+core CPUs this may not be necessary, but it's an interesting area anyway. I've seen some physics stuff done on a GPU. One particular example was an audio system that was essentially doing live ray-tracing so a sound source in a maze would be pretty accurately altered by the walls and so on, so you get multiple reflections and all that. Runs in real time too because it's mostly done on the GPU, but there's no way it would even come close to running on a CPU.
Last edited by jtw62074, .
Sure you can. GPU stuff is just shader language. You can fill it with matrix/vector calcs to your heart's content, stuff it into a texture, then read it back out from the exe. I was doing something like 40 billion calcs/sec in a shader when my P4 3.6Ghz HT spu could only do 1.3 billion. This was happening during a simple shader animation and there was 0 loss in frame rate. If they were 3Vectors it could have done about three times that many. There's some bandwidth overhead because you have to transfer the data back and forth between the exe memory and the GPU, but yes, it's absolutely possible to do this kind of thing.
Much easier said than done. If you have a few spines along the width of the track you can make some waves across it, but putting a 150mm wide curved rut precisely located wherever you want is probably not a realistic option, even if you were to manually do it. You don't have infinite control over the surface with splines unless you have a LOT of splines. In that case you might as well do it with high density polys. That'd be a lot easier. Attempting to calculate the changes needed on the spline to do it automatically would be rather challenging, to say the least, even for one rut. Want another one perpendicular to that one crossing through it? Errr...
Try playing with splines some time and you'll probably see what I mean.This would most likely be an exceedingly difficult approach to the problem which could be solved in much easier ways.
FGED GREDG RDFGDR GSFDG