The online racing simulator
Searching in All forums
(635 results)
jtw62074
S2 licensed
Quote from Hyperactive :No one has not yet driven any "Todd-sims" so I wouldn't jump into conclusions yet. Even the physics department is more of a question mark atm.

Wait and see (when's the demo out dammit already!!11??)

Hopefully the karts will be as close to reality as the next VRC version. Here's it running with the new tire model along with a video of a real car:

http://www.performancesimulati ... les/vrc_compare_mach3.wmv

We showed this to a bunch of engineers at an SAE presentation awhile back. It took them awhile to figure out which was real and which was in-game video

Anyway, I'm probably not alone in wanting a match that good for Kartsim. We'll do the best we can to make it happen.
Last edited by jtw62074, .
jtw62074
S2 licensed
Quote from Shotglass :didnt todd provide most of the basic physics code for this sim? very likely to become one of the best sims out there... at least in terms of physics

Yes, it uses my physics engine and I'm responsible for the handling dynamics end of things. In modder speak, I "do the physics."

Realism is priority 1 with all of us, so don't worry about this being some arcade knock-off wannabee thing
jtw62074
S2 licensed
Engine damage? Can't say I've ever noticed this...
jtw62074
S2 licensed
Sure does look fun! Glad to see Force Dynamics appearing to do well and developing a new rig. Look forward to trying one some day.

Keep it up, guys!
jtw62074
S2 licensed
Quote from JeffR :I don't understand why less locking factor results in more lift throttle oversteer. Take the extreme case of an open differential. During engine braking combined with cornering, it seems that the inside rear tire would lose grip and slow down while the outside tire would not, giving more warning, and less prone to oversteer, because only one tire would be sliding. However I gather than an open diff creates more oversteer reaction to lift throttle than a mostly closed (LSD type) diff.

Can someone here (maybe Todd Wasson) explain why this is so?

There are a couple of yaw torques involved here.

The first that you seem to be referring to is caused by the lateral tire forces. As you said, the capability for this would decrease when you go to a tighter diff while coasting into a turn because there is a longitudinal (braking) component that tends to get larger as you stiffen the coast side of the diff. That component by itself indeed does tend to increase oversteer as you envision because there's less lateral force available on the outside rear tire. A fully open diff gives the most possible lateral force, so it does seem silly to suggest that it causes oversteer indeed.

However, there is a second yaw torque that comes from the longitudinal tire force (the braking component on the outside rear which is what evilgeek is referring to). A bigger rearward force on the outside tire because the diff is tight would tend to straighten the car; an understeer effect by itself. Two competing torques exist. The question is, which one generally wins?

In my simulations so far (LFS and all others too that I've tried) the longitudinal effect has won in every case by a pretty considerable margin. However, you do have a valid point in that an open diff gives you the most possible lateral force in any given situation, which is why I recommend people run the loosest coast lock they can get away with, then adjust the rest of the setup accordingly. That in itself would suggest more open = understeer, but the opposite usually winds up being true because of that longitudinal force that counteracts it.

Edit:

http//www.performancesimulations.com/files/diff4.jpg

That's showing longitudinal components of tire force under acceleration. Flip all the arrows to point down and you have the situation under coasting/braking while cornering.
Last edited by jtw62074, .
jtw62074
S2 licensed
Probably peak force versus load. With no load sensitivity it would be a straight line.
jtw62074
S2 licensed
Pretty graphs, AndroidXP. Why not make use of the nice skidpad LFS has to collect data instead?

People probably shouldn't use the term "grip" as a substitute for "friction coefficient." It adds to the confusion for most people because most folks consider grip to be the same thing as force. Racers are in an endless quest to "find more grip." Whether that be through raising the friction coefficient of the tires by changing air pressure or through increasing downforce (reducing friction coefficient), they call that increasing grip since either way you get more force at the tires.

Grip = force in my book, although I don't know if there's an actual SAE definition to the contrary.

Nothing ever struck me as odd about the load sensitivity in LFS, even with all the playing on the skidpad I do. If there was no load sensitivity, most of the typical chassis tuning like ARB changes wouldn't do anything, or perhaps do the opposite of what happens in reality in some cases.

Increasing load sensitivity should generally tend to increase understeer when off throttle, and increase oversteer when on it.
jtw62074
S2 licensed
I'll join the club too. This is a really nice patch that was totally unexpected (for me anyway, maybe I don't pay close enough attention ). I'm having a blast with the new car.

I never really notice the tire wear to be honest. Overheating and losing grip, yeah. Wear? Not so much. I'm sure it's there, but I seem to be able to go a very long time on any of the tires as long as the pressures are set to keep the temps in line. Granted, I'm very rarely the fastest one on the track.

The clutch overheating is a nice touch. I did this accidentally of course and giggled upon finding the thing slipping like crazy after recovering from a couple of spins without being careful. I likey

Great work, guys! Keep it up and have a great holiday
jtw62074
S2 licensed
Quote from breadfan :There is a Czech automobile news website, that published a few short reviews of racing simulators (GT5, GTR2, GTL, F1R, RBR, LFS, rF, Race, TOCA and others).

<snip>


Enjoy

Thank you
jtw62074
S2 licensed
Quote from mrodgers :I live in the US. We have warnings and nags on our coffee cups that warn us the contents are hot, that is how bad it is.

At one job I had we used foam ear plugs. I kid you not, the package warning said, "may cause difficulty breathing if caught in windpipe."
jtw62074
S2 licensed
Nice videos and site, Hallen.

A friend of mine ran a couple of Donkervoort series for a few years (open top Lotus 7 types) and filmed several of his races and so on. It took awhile for him to figure out how to get rid of the wind noise and let the engine sound come through more. Eventually, he stuck the microphone under the dashboard on the passenger side, up towards the firewall. This is the result:

http://youtube.com/watch?v=Dp7g1NAMNxE

I went for a couple of rides in this car, and the video sounds very much like it does in reality, although I couldn't hear the turbo like you can in the video. (The car pictured in the video is wrong, by the way, although the driver's name is correct. Wolfgang wasn't actually driving his own car here, but my friend's. We don't know how they got this video and were surprised to find it online )

Anyway, regarding mic placement, maybe you might want to try the same thing? It sounds rather windy, although the video quality is very nice!
jtw62074
S2 licensed
I agree with Tristan. Pressure seems to be the biggie here. That's how I get the temperatures I want too. I don't run the FOX very often though.
jtw62074
S2 licensed
Either way, I'm not for putting it into LFS. It's meant for my sim.
jtw62074
S2 licensed
Oh, ok. I understand now.

I'm happy and flattered that you like the sound, but doing something with OutGauge to get it running in LFS isn't something I want to do. Sorry. I doubt the LFS team would appreciate it much either
Last edited by jtw62074, .
jtw62074
S2 licensed
Quote from KeiichiRX7 :Todd, any chance we could get these simulations hooked up to OutGuage?

That would be pretty cool

The engine simulation? What would that do? The driving sim would make more sense. I probably misunderstood...
Last edited by jtw62074, .
jtw62074
S2 licensed
Quote from lalathegreat :of your latest engine Sim, which part is more computationally intensive. Also did you design the sim with a larger respect for it generating audio.

The initial engine simulations were originally developed with no intention for use in video games. The first one is in my drag racing simulation, Straightline Acceleration Simulator, which is a tool like Bob Smith's for helping people set up their cars. The engine simulation in that was mostly written back when I was in high school in 1991-1992 or so.

Since then the other models were written to explore much the same thing. At one point while working on a sorting line at Holsum Bakery (can you believe it?) it popped into my head that the simulation could probably produce audio too. This was about 8 or 9 years probably. The Pentium 60Mhz system gracing my desk back then hadn't a prayer of pulling it off, nor were my coding skills up to the task at the time, so it remained just a thought experiment until a few years ago.

The engine simulation aspect itself would take up more cpu than the audio would. However, with the new system it's not so easy to draw a line between the two as there wouldn't be a preprocessing step. I.e., the engine simulation is producing the audio on the fly in real time, so the question then loses some meaning.
jtw62074
S2 licensed
Quote from Shotglass :hm interesting tyre info on one of the vids there

whatever happened to releasing that car sim btw ?

It's far from ready for any type of release. There isn't even a car rendered currently and the graphics are atrocious

It's basically just a testbed for other development projects and doesn't really get much more than sporadic attention here and there. It'd be neat to release something some day, but I don't have concrete plans to do so. The last thing I want to do is announce something like a release date. People quickly turn against developers when they make an announcement like that and fail to deliver
jtw62074
S2 licensed
Quote from Shotglass :definitely an interesting prospect for the future but iirc were still at least a couple of years away from tightly speced general purpose computing on gpus/parrallel cores in fusion so it will be quite some time until every card on the market comes up with the same numbers

You're probably right. The 8800GTS/GTX is the first card that has a general purpose API, CUDA, for it. Its architecture is apparently radically different to allow different memory sharing and other fancy hardware stuff that I don't understand in the slightest at the hardware level The API is very impressive, but yes, you'd need to write a separate system for other cards using shaders instead if you wanted widespread GPU support.
jtw62074
S2 licensed
I've written a few engine models that vary in complexity. The 2 stroke model is for Virtual RC Racing 4 (or VRC Pro or whatever we wind up calling it) and will probably be used in KartSim too. That's not audio stuff.

There are two components to the 2 stroke sim. First is a preprocessing step where the simulation is run at a bunch of rpm steps. That's pretty quick really since it's a single cylinder engine. It takes perhaps 2 seconds to come up with the torque curve. In that you can change fuel mixture strength, oil and nitro %, etc.. It's using unsteady gas dynamics so the pressure waves travelling through all the intake/exhaust/expansion chamber areas and so on influence things significantly. The area above the piston is three separate volumes which allows intake/exhaust gases to flow and mix across the piston between the transfer and exhaust ports. Some basic heat transfer and other stuff is saved during this step too which is then used in the second component, the real time part. In that, the engine temperature, oil film thickness on the cylinder wall, and so forth varies in real time which can change the torque the engine is making and allow runaway heating from a too-lean condition to seize the engine.

The more complex sim is indeed a 4 stroke model that works similar to WAVE, although probably isn't as accurate. That one takes a couple of minutes to run a full torque curve for a V8 so is definitely not real time. The output data from that can then be used for the real time audio stuff.

Some of you may remember these from a couple of years ago:

http://www.performancesimulati ... iles/EngineSoundModel.zip
http://www.performancesimulati ... les/EngineSoundModel2.zip

Those are indeed real time V8 engine simulations with all 8 cylinders having their own mass flow rates through the valves, cylinder pressure variation, and so on. You'll probably notice the CPU load is pretty high though. It's also not used to make torque curves as it's such a simplified model that it's not nearly accurate enough to do that. The valve model is very simple. They're either open or closed, and there is no intake model at all. Instead, there are preselected volumetric efficiency curves which could have been done in a way to allow throttling of the engine, although I didn't bother with that as I abandoned the approach. The exhaust runner length and dimensions are not accounted for either. So we're talking very, very basic here to run in real time. And this one uses too much CPU power to run a car sim on top of it unless it was running on a multi-core system. Those didn't exist when I wrote those though

The latest one I'm working on now has a lot more potential. This is another simplified engine model that currently is running in a preprocessing step, then the data is fed into the live audio simulation system which itself is very fast (1-2% cpu load usually). That preprocessing step engine model is considerably faster than real time. A V8 will run about 100 times faster than real time with plenty of room to double or triple that, so eventually I'll use it that way, although currently that's not the case. I can kill off cylinders and that sort of thing. Valve bounce/float and simulating stuck valves will also be able to be done with the approach as well.

This too, however, will probably not be very accurate in terms of torque output and so forth which is more what this thread seems to be about. There isn't a turbo simulation in there either. It's mainly intended for audio.

http://www.performancesimulati ... iles/ToddSim-GenIV-06.wmv
http://www.performancesimulati ... iles/ToddSim-GenIV-07.wmv

So yes, it's possible to do an engine simulation in real time. The above movie has audio running at 88Khz, so it's calculating the engine stuff 88,000 times per second on average, which is double what audio/music on a CD runs if I'm not mistaken. The question is really, "how much can you do and at what level of accuracy and complexity?" Currently, it's not too high if you're only using the CPU and not the graphics card (especially the 8800GTX).

While I'm posting videos I might as well add a fun, OT one:

http://www.performancesimulations.com/files/dominoes.wmv

Last edited by jtw62074, .
jtw62074
S2 licensed
Quote from lalathegreat :well that explains the results shown. thats clearly not how it works in real life.

Sure it does. In reality the efficiency value there varies a bit with throttle and rpm, but fundamentally this approach is good enough for its purpose. To get nitpicky you'd want to use BSFC curves, but what difference would it really make to game play in LFS, and then how would one argue for or against the accuracy of the BSFC curves when the engines are completely fictitious, anyway?

If the mileage is too high or low on some cars, a quick tweak to the fuel efficiency value for each car is all that'd be needed. 30% is rather high for fuel conversion efficiency, in general, iirc.

There was a debate in rec.autos.driving about fuel efficiency versus fuel economy a couple years ago, where someone was insisting that the best fuel economy came at 40% of redline. That's not specifically what people here are arguing about, of course, but some of you might find it interesting as it gets into some calculations using real world engine data that is both throttle position and rpm dependent, and considers both in variation with a car's speed. The posting was pretty off the cuff by this point in the thread as the guy we were talking too was exceptionally dense (high volumetric efficiency? ), so my language and attitude is a bit flame-like.

The specific post is here:

http://groups.google.com/group ... ving/msg/4349618c20e0f5b4?

The rest of the thread is here for context:

http://groups.google.com/group ... p;rnum=1#44a65441d60ee4dc
jtw62074
S2 licensed
I'm not too sure what to add to this thread. Much can be learned about how LFS's camber, tire temperature, pressure, and resulting grip work from running on the skidpad. I do quite a bit of this actually whenever running a car I've barely touched (that's my "new content," right there )

Camber adjustments for skidpad tests were done with the Shift-L suspension display on. This shows camber while actually cornering. What's noticeable is that the peak lateral grip comes in when camber is 0 on the Shift-L display. I.e., when camber is actually 0 at the moment relative to the road. This is what I call "dynamic camber" rather than the camber shown in the setup screens for "live camber," which to me is just "camber." In the setup screen this means adding in a lot of camber adjustment because the suspension geometry on all the cars I've tried lack enough camber gain to handle this (they all need shorter upper arms, pretty much).

Tire pressure has a noteable effect on dynamic camber (shift-L while cornering, although watching the 3 pressure bars on each outside tire in the F9 display as Forbin describes is the same thing) in LFS as the body roll angle changes. Lowering the tire pressure softens that corner of the car and increases body roll, so any time tire pressure is adjusted you ought to adjust camber too. This is something I didn't notice until playing with the LX4 in a frantic attempt to get within 4 seconds of Axus' lap times recently.

A reasonably safe conclusion is that in LFS these high cambers work in short races because the dynamic camber (shift-L while at max cornering) is close to 0, which gives the highest lateral acceleration and cornering speed. I'm not sure how the temperature distribution across the tire in LFS effects grip though, as you can't test that separately without throwing camber into the mix. My impression is that the average temperature across it is used, or something close to it, but I could easily be wrong there.

This works just fine on the skidpad, but on a track the tires heat up unevenly so much on the straights that you of course wind up with a really uneven distribution. What exactly the tradeoff is there in LFS I couldn't say. But I sure have fun trying to figure it out! This heating split on the straights seems overdone in LFS though.

In longer races, if you don't really notice much difference in grip when you have a really hot edge and really cool edge develop so long as the average temperature across the width stays about where the optimum temperature is, then you can probably be safe setting up the car to keep the average temperature at the optimum and not worry too much about the spread. I always until just recently assumed that having the temperature distribution equal and right on the optimum temperature was the way to go in LFS, but it seems that it's more important to have the pressure distribution even mid-corner. Ah, the joys of car setup

If this is the case, the pressure distribution then effects grip more than the temperature distribution, so it might be a good idea to set up the car to put the average temperature across the width right at optimum (just the middle temp is good enough, probably, unless tire pressures are exceedingly low or high). The end result is usually quite a lot of camber. Granted, this hurts your braking a bit, but the trade off is probably usually worth it.

Overall though, having -3 deg or more "live camber" isn't unusual at the racing track in reality, so I wouldn't let the number bother me. In reality, tires make peak lateral grip at some non 0 "dynamic camber" angle, often -3 deg or more. The front right tires in one racing class at a nearby (very) short oval track running street tires were running probably over -12 degrees. Road cars aren't set up this way because of tire wear and durability, primarily, where most driving is at 0.3g lateral or less. Most of the time you're going straight.
Last edited by jtw62074, .
jtw62074
S2 licensed
I've got one of the Z800 visors that does the 800x600 resolution. They can be bought for around $700-$800 on eBay. I'd ignore the mumbo jumbo comparisons about screen size looking like it's 60 inches viewed at a distance of whatever feet. That might be correct, but...

My notebook has a 17 inch screen. When I wear the Z800 and sit back in a big, fluffy chair, the image in the visor looks the same size as the laptop monitor. I'm left wishing it was just a tad bigger and was honestly a little bit disappointed when I first tried it (except for the 3D effect which is pretty mind blowing). However, after playing a bit I more or less forget about it, especially in a dark room.

I couldn't get LFS to work in stereo mode unfortunately. It might be the special drivers that were needed for my notebook at fault though. The only racing sim I tried in 3D was mine along with VRC. First person shooters rock though and can be downright frightening in full 3D. Zipping around between skyscrapers in Flight Simulator 2004 made me queazy enough after a few minutes that I had to stop!

The 3D effect is excellent. However, I suspect a big monitor with some shutter glasses might be better, unless you're just dying for the head tracking. In that case, it's best to get a TrackIR on top of the visor as well. The head tracking is much better than the built in Z800 accelerometers provide.

As for a smaller visor like the OP posted, I'd look hard at seeing if you could try a pair out first before buying them unless there's a satisfaction guarantee. To each his own though. Many folks can't go back to a monitor after trying a 3D visor

Oh, and the 800x600 resolution looks a lot better than I expected it to. It's quite clear and seems much higher res than that. Any games you play with it need to work in full screen (no windowed games) and of course be able to go down to 800x600, or in the case of the OP's post, 640x480. Not too many games go that low these days.
Last edited by jtw62074, .
jtw62074
S2 licensed
I'm not sure and haven't seen any specific mention of how pneumatic trail varies with it.

There are graphs floating around out there, however, that show aligning torque as a function of longitudinal force at several different slip angles. In one of them, even at 0 slip angle there was some non-0 aligning torque (about 10 N-M) which increased towards about 20 N-M with a bit more than 5000N longitudinal force (compared to 160 N-M at 6 deg slip angle, the highest the data went to). It was a little different under braking than acceleration, but there was this small change even at 0 slip angle.

Up to about 4 degrees the aligning torque rises a little bit under very slight braking, then drops off toward "0." This doesn't specifically say what the pneumatic trail is of course. If there was a combined operation lat/long force diagram to go along with it maybe the pneumatic trail could be figured from that. I haven't looked for this at all, but will keep my eyes open for it.
jtw62074
S2 licensed
I hope this will help clarify the difference in aligning torque due to pneumatic trail alone versus pneumatic and mechanical trail acting together. This is relevant to the NetKar versus LFS FFB discussion.

First, here's one of BuddhaBing's links so we can remember what aligning torque curves are and how they look:

http://i1.tinypic.com/4y7l0ys.jpg

The curves rise, hit a peak, then drop back down and sort of tend to level off somewhere either above or below the 0 aligning torque line. Data like this is measured on a tire machine with no suspension. These curves result from the lateral force and the pneumatic trail, but without any mechanical trail.

Now here's a fancy new diagram from me

http://www.performancesimulations.com/files/sat4.JPG

Aligning torque is the blue line times the red line. It's just a force acting at some distance from a fulcrum, like a wrench on a nut. Only this wrench is trying to twist the tire and the steering wheel that's connected to it around the steering axis of the suspension.

The left column of pictures show what's happening in the first link (the aligning torque curve graph). Note that the slip angles and magnitudes of the force and trail here do not match up with what's shown in the aligning torque graphs. My picture is completely fictional and is just for illustration.

Starting at the top left picture, at some tiny slip angle there is a little lateral force (red arrow). The force is acting very close to the center of the contact patch. The aligning torque is this distance multiplied by the force. A small force times a very small distance gives a very small torque, as shown in BuddhaBing's link where the aligning torque is very near or equal to 0 at 0 slip angle.

As lateral force increases, the force centroid moves rearward in the contact patch as we go to the fictional 3 degrees. Both the torque arm (pneumatic trail) and the lateral force get larger. The aligning torque is increasing. In my example pictures, at 5 degrees the aligning torque and lateral force are both quite large. Here we're right around the peak of the aligning torque curve.

As we continue to increase slip angle, the force centroid moves back towards the center and may even move past it so it's forward of the center of the contact patch. The aligning torque drops and may become negative.

If Netkar is using the aligning torque curves from the Avon data directly, then it should be working just like the left column.

The right column shows the same thing, but the torque arm includes both pneumatic trail and the mechanical trail on top of it. For this fictional tire, at 7 and 10 degrees slip angle the lateral force is the same. The pneumatic trail decreases (torque arm, blue line, gets shorter), so you'd feel a little bit of lightening in the steering wheel as you get near and past the peak of the lateral force curve, but nowhere near what you get in the left column where pneumatic trail is assumed to be the only influence. There, if the pneumatic trail is cut in half and the lateral force held constant, the aligning torque is cut in half too. In the right column, the pneumatic trail is only part of the total trail, so cutting it in half (or doubling it) changes the aligning torque much less. The aligning torque is more dependent on lateral force than it is in the left column.

One could imagine a third column there with the trail held constant. I.e., the lateral force doesn't move forward or rearward in the contact pach, but sits still somewhere. This wouldn't necessarily have to be the center, so you could have pneumatic trail included that is constant and doesn't vary with slip angle as one type of model. The aligning torque then varies only with the lateral force. This is how LFS feels to me and is likely the big difference in FFB between NetKar and LFS. If that is correct, then the second column would sort of blend the two together and better reflect reality, for both LFS and NetKar
Last edited by jtw62074, .
jtw62074
S2 licensed
Quote from Shotglass :could someone please clear one thing up for me ? from my understanding sat need a certain degree of long slip otherwise there wont be an arm to act on yet those curves never refer to any long slip

Here's a quick and dirty diagram showing the relationships between lateral force, pneumatic trail, and aligning torque in the case of 0 caster and kingpin inclination. This is pretty much what results in the aligning torque diagrams you see in graphs measured on tire testers:

http://www.performancesimulations.com/files/sat1.JPG

The pneumatic trail is just a torque arm. The lateral force varies all throughout the contact patch since you have different amounts of lateral distortion. At the front there's very little and as you proceed towards the rear it increases, then decreases. As a result, the center of force (lateral force centroid) moves forward/rearward in the patch (up and down in the diagram) as the slip angle, vertical load, and resulting lateral force change.

As slip angle starts at 0 and then increases, the force centroid starts pretty much at the center of the patch, then moves rearward toward where the lateral force arrow is drawn in the diagram, then returns toward the center at around the lateral force peak. Sometimes it can probably wind up slightly forward of center at even higher slip angles which would give a reversal in the aligning torque. This is fairly common from data I've seen to date.

Note that there is no longitudinal force here at all. Longitudinal force in the case pictured would project straight through the center of the patch (upwards/downwards in the diagram) and not produce any aligning torque at all since a torque arm would not exist, even if the force centroid was forward or rearward of the patch center. The situation changes if the force centroid is left or right of this, however. More on this in a minute.

Mechanical trail is added here:

http://www.performancesimulations.com/files/sat2.JPG

The steering axis due to caster angle intersects the ground somewhere. At 0 caster the intersection would be smack in the middle of the contact patch. As you increase caster, you move the intersection point forward. The distance from that intersection point to the patch center is the mechanical trail. The total torque arm then becomes the mechanical trail plus the pneumatic trail (not quite, but that's extremely close; there'd be 2% cosine error at 11 degrees caster). In this case, unless you had very near 0 caster, it's unlikely the total aligning torque would ever drop to 0 or reverse direction.

Tire data does not include this mechanical trail. It's measured purely in the tire plane with 0 caster as in the first diagram. NetKar appears to work this way to me. It seems to ignore suspension geometry effects in this aspect, at least.

LFS seems to me to have more or less a constant total trail (pneumatic + mechanical). The effect of that would be the same as multiplying lateral force by some value to get the aligning torque. I don't feel any drop off in aligning torque at high slip angles at all. However, with caster and the resulting mechanical trail in the picture, this should be more natural feeling except that you do miss what would become a subtle drop off in aligning torque as you approach the limit. So it makes sense that some people feel the front tire limit better in NetKar than in LFS, while others might feel that the loss that (to me at least) is missing in LFS is exaggerated in NetKar to the point of it feeling not as good.

To each his own. Some would prefer to feel the front tires approach the limit even if it means the steering wheel getting extremely light or losing all torque (perhaps even reversing it) all of a sudden. Others (myself included) would prefer to have the aligning torque build up and just hit a maximum somewhere without going completely limp. You can still feel the limit with that approach in some sense in that at some slip angle the aligning torque stops increasing. NetKar's approach is better in one way, LFS's is better in another. Overall, if you compared steering wheel torque in each sim to reality, I'd bet LFS's is a lot closer, even if it's missing some magnitude of the drop near the peak that you get in NetKar.

Ideally you'd combine the two approaches. If NetKar is indeed missing the mechanical trail as I strongly suspect, it could be added through a bit of wrangling. The pneumatic trail would have to be calculated in real time from the aligning torque, then the mechanical trail added to it, and finally, the lateral force multiplied by this total trail to get the aligning torque. That would be a huge improvement for Netkar's FFB.

LFS seems to work a bit differently, but similar principles could be used. The point is to add in the pneumatic trail (if my impression of it being either missing or not actually varying with slip angle is correct, of course) in addition to the mechanical trail, and use the combined two for the final aligning torque. If LFS is using a brush or similar tire model, the pneumatic trail can be calculated directly from it. Problem solved. This works quite beautifully, actually.

In both sims, with this approach you get the best of both (I've driven a model that does this). You have the heavy handed feeling you get in LFS, but with a much more subtle version of the aligning torque drop off you get in NetKar near or after the peak, so you feel the limit coming at the front tires better. In addition, you wind up tuning the feel at the steering wheel by adjusting caster, something that race engineers due in real life. A racing engineer once told me that he sometimes does this to trick his driver into using more steering than he otherwise is inclined to, even if it means giving up a tiny bit of lateral force capability. After all, he wasn't using it anyway.

Tire pressure greatly effects pneumatic trail, and therefore aligning torque, as well. This is why in reality you can feel a tire losing air pressure through the steering wheel mid-corner. Drivers can probably feel the tires heating up and building pressure over the first couple of laps as well. If so, that would largely explain it.

Back to longitudinal (traction/braking) force: This can indeed cause an aligning torque at the steering wheel too.

http://www.performancesimulations.com/files/sat3.JPG

Case # 1 shows the steering axis intersection point with the ground like in the previous diagram. Here we have some caster which puts this point forward of the contact center and lateral force centroid. In this case, as mentioned briefly earlier, there is no torque arm present so no aligning torque is generated when traction or braking force exists.

Kingpin angle is the equivalent of caster, but in the left/right direction rather than forward/rearward. In a nut shull, the steering axis can be positioned pretty much anywhere and slanted in any direction, so it can (and usually does) intersect the ground somewhere to the left or right of the patch center in addition to forward/rearward. With a left or right offset present there is indeed a torque arm that longitudinal force will act on, which will generate an aligning torque when traction force is present, and an opposite aligning torque when braking force is present. The steering axis is changing with suspension travel too. (This isn't all as hard as it sounds, by the way. The calculations are pretty short and straightforward)

Granted, in a perfectly straight line you wouldn't notice it if the suspension is symmetrical because the left/right tires would cancel each other's aligning torque out at the steering wheel. In other situations though, there would usually be some effect.

The force centroid may not naturally be in the exact center of the contact patch. Due to asymmetries in the design, the presence of camber, tire pressure, and so forth, the force centroid is probably slightly to the left or right of center. However, the point is that there can be a torque arm in the lateral direction and one in the longitudinal for both lateral and longitudinal forces to act on. In aligning torque data this may partially explain why aligning torque sometimes reverses at some high slip angle.

Kingpin versus caster angle :
http://www.performancesimulations.com/files/steeringaxis.JPG

Scawen (or Stefano, for that matter), in case you're reading: To get all these effects, you just need to make sure the force centroid is free to move about in the contact patch (or something equivalent), then take the portion of the resulting tire force vector acting perpendicular to the steer axis. Voila: Steering torque that varies with everything under the sun including suspension travel and so forth. It can be taken further than this, but it's a good approach.
Last edited by jtw62074, .
FGED GREDG RDFGDR GSFDG