Quote from Shotglass :

ok now he just claimed the wheel turns faster than the tyre ... im sure he knows a bit about coding but his physics knowledge is pretty appalling

Not the whole tyre but what he said is actually true for the front part of the contact patch when accelerating, which has smaller angular velocity than the wheel hub in that case. The video was probably meant as a popular lecture and obviously things are simplified, because being precise would take too much time.

When you brake in the straight line the ARBs don't generate any forces, because both wheels of the same axle have the same suspension deflection. In the other case (sideways stopping) the ARBs do work and their effect at every wheel is to make the suspension stiffer. Because the damping at every wheel is still the same, therefore the system becomes underdamped, which means longer oscillations at higher frequency.

The torques at the output shafts of the central differential would be equal (for open differential), but the torques delivered to front and rear wheels would be different. Isn't that what we really wanted?

Last edited by w126, Tue, 8 May 2007 07:37.

Quote from Bob Smith :

Those wheels (1 and 2 in the diagram) a) surely have to be the same size for it to work mechanically

You can achieve the same with additional gears (2:1 ratio for example) on one of the output shafts of the central differential or different final drive ratios of front and rear differentials. When driving in the straight line the front and rear wheels turn at the same speeds (approximately), therefore the output shafts of the central diff don't have the same speeds (the additional gears convert both torque and rotational speed), nothing unusual for a differential.
IMO all the differential settings available in LFS are possible mechanically.

Something related: http://www.cs.ucl.ac.uk/staff/P.Bentley/WLBEC1.pdf

Quote :

Abstract. Formula One motor racing is a rich sport that spends millions
on research and development of highly optimized cars. Here we describe the
use of a genetic algorithm to optimize 66 setup parameters for a simulation
of a Formula One car and demonstrate performance improvements (faster lap
times) better than all other methods tested.

Your code could be very useful for doing similar stuff with LFS.

Quote from jtw62074 :

When it's done properly, the lateral force will drop with increasing traction regardless of the slip angle. Even when you're way under the limit. As you approach the limit it winds up very smoothly transitioning into limit behavior. As such, you can steer with the throttle quite nicely. It's all very predictable and drifting actually becomes quite a lot easier. Suddenly you find yourself steering as much or more with the throttle than the steering wheel, even when you're below the traction limit. I've yet to see that anywhere except in Gregor Veble's model for Racing Legends and my own.

Do you claim that all current good simulators have such a basic flaw? It's very hard to believe.

You might want to compare F1PerfView output with this. The attachment shows the slip angles (vertical axis) from the WR lap in MRT at Fern Bay Gold calculated with RAFTyreExtract (the version used is not entirely ready yet). Front left wheel is in red, front right in green, rear left in blue and rear right in black. Understeer is defined as front slip angles being larger than rear slip angles and you can see it happening in many corners during the lap.

If the slip angle in F1PerfView really means what is described here http://en.lfsmanual.net/wiki/Telemetry#Data_Items then I'm affraid it's not correct.

Quote :

Slip Angle. Difference between steering radius and actual radius, measured in steering degrees. Negative indicates understeer, positive indicates oversteer.

This paper http://www.engr.colostate.edu/ ... ing%20Tire%20Modeling.pdf has a nice figure showing the correct definition of slip angle.

I hope that in S3 phase LFS is going to become more diverse and versatile instead of just providing more of the same. Bikes? Why not? It is very hard to do properly because of controller limitations, but LFS is already very configurable and innovative when it comes to controllers, so there is hope for some more great ideas in this area. It would be hard not to mention rallying here, with an appropriate new game mode. Also some off-road stuff in the spirit of Screamer 4x4 could be very interesting, deformable terrain, rain...

However, boats and planes just don't make any sense. Trying to do them would mean losing focus completely.

Quote from Shotglass :

how do you achieve a front/rear torque split anyway ?

By using front and rear differentials with unequal final drive ratios. I guess it should work.
The torque split would be constant only with open differentials. For LSD it changes depending on the circumstances.

Lancia Stratos
Rally version of Ford Escort Mk2 (with Cosworth BDA engine)

Quote from Niels Heusinkveld :

But how did you get the LFS curves?

http://www.lfsforum.net/showthread.php?p=212598#post212598 (follow the links in this post)
http://www.lfsforum.net/showthread.php?t=3667

Quote from Niels Heusinkveld :

Are they exact?

Now I know that grip values (also longitudinal and lateral tyre forces) calculated by RAFTyreExtract are almost uniformly too small by 1-2 % (the relative error is close to (single wheel mass) / (total car mass)). There may also be additional errors when driving over the kerbs due to the way the program approximates the road surface, needed for coordinate transformation.
But I think it is good enough to distinguish between the curve options shown in the first post.

Quote from Niels Heusinkveld :

Furthermore, curves are one thing..

Real (experimental) data curves of the types discussed here show steady state tyre behaviour, i.e. when the parameters do not change or change very slowly. It is more difficult to find real data about dynamic tyre behaviour, which I guess might be the area where LFS and ISI engine outputs differ the most.

Quote from Boris Lozac :

Today i was testing the Seat Leon Mod, and i noticed that when you aply like 30, 40 % of throtlle, the sound is like you released it totally.. like on idle

Maybe it's the gas pedal that fools you, not the sound? ISI engine has this strange pedal mapping "feature":

Quote :

My gas pedal has a big dead zone, how can I fix this?
Assign the brake pedal axis first and then the gas pedal axis.

http://www.10tacle.com/gtr-game/en/index.php?FAQs#8

AI could at least drive sideways (on purpose) when cornering on dirt parts of rallycross tracks. That would make them quicker.

Quote from JeffR :

Do you have any curve plots for the tires in LFS?

Here is an example for road tyres: http://www.lfsforum.net/attach ... tid=4791&d=1136410311 However, it was done before the last physics patch. It looks like lateral grip could drop by at least 15 % after the peak in that older version of LFS. Unfortunately I don't have more current data.

Also Silverstone (it's called Northamptonshire http://www.rfactor.net/index.php?page=northampton_details) will be released with the next rFactor patch.

These four tracks from F1 season were build by more than one person and it had to be done quickly to be ready for pitlane park events. Some people reported that during these events driving aids (other than TC) were always on in the simulators available for visitors. Could these be the reasons for choosing rFactor?

BTW, remaining pitlane park events are Monza and Shanghai.

Not anytime soon in this case probably means more than 5 years from now. In this period we may see great simulations built from scratch by larger teams and released. Just think of RBR as an example, which was released in 2004 and this is what Eero Piitulainen said in ASS interview: "Then, in the summer of 2002, I saw a job advert for a physics programmer at Warthog."
What I mean is that from our point of view whether RL is alive or not doesn't matter much.

Sega Rally Revo (an arcade game) is going to have the feature discussed in this thread.
http://pc.ign.com/articles/708/708074p1.html

Quote :

More interesting, however, is how each car will shift polygons in the roads themselves. They create patterns and waves as they bend when driven upon.

We watched as the producer circled around the same patch of dirt over and over again. As he did, the heavy rally tires dug various grooves into the ground. By switching cars, from a light to a heavy one, the grooves dug were deeper and more profound. The earth didn't regenerate or reform, it stayed the same. When the car was slowly rolled over it, the shocks perfectly reacted to each groove with great precision. Imagine now that the course you're going to play on has multiple cars racing across the same surface multiple times, creating distinctly different terrain obstacles each lap. Not just your car, either, the AI cars, too.

Yes, for locked differential the torque is not distributed equally most of the time. But for open differential it is distributed equally all the time.

With a wheel in the air the torque acting on the wheel through the axle will be used to increase the rotational speed of the wheel, which has non-zero moment of inertia.

Quote from Mikkomattic :

in a differential, both wheels get the same torque - "it's just the way it works mechanically".

Isn't that true for open diffs only?

Quote from himself :

About Locked Diff. Lets say that maximal torque at left wheel without spinning it is 200 Nm and 800 Nm on the right. Reaching 400 Nm both wheels are proppeled with 200 Nm. Then the right wheel is being "filled" with torque untill it reaches its peak value. So we have 1000 Nm at diff -> 200 @ left and 800 @ right one. But what next? Increasing torque at diff to 1200 Nm will it be distributed equally to both wheels then? (300 / 900) or unequally proportional to maximal non-sliping value? (240 / 1060) ?

Additional torque (over 1000 Nm) will cause angular accelaration of both wheels. Because they are locked together, they will have equal acceleration. They also have the same moment of inertia, so I think this additional torque will be split equally, 300 / 900 in this case. In fact 280 / 880 might be more correct, because some torque will be needed to accelerate the axle.

Maybe combining live position and orientation data from OutSim with track surface description (CMX) could be good enough to calculate live ride height of every wheel? Provided that wheels have contact with the ground at a given moment of course. However I don't know how accurate CMX files are.

I'm sorry, what I wrote previously sounded too rude. :ashamed: I know doing such measurements requires lots of work. This method is good to get info about temperature effect, which alone is probably not load dependent.

Do you measure maximum grip for the same value of normal load in every case? I ask because grip is load dependent (load sensitivity http://www.lfsforum.net/attach ... id=4791&d=1136410311). If you do not use the same normal load in every case than you may get additional inaccuracy because of that. OTOH if you use the same normal load, then it must be rather small value (judging by maximum grip for road super tyres). I think it might have been better to use larger load, for example the normal load of outside tyre in a typical corner, because then you get grip values closer to effective grip of the whole car (outside tyres do most of the work when cornering). For example someone might expect to corner at 1.27 g on road super tyres, but in fact no more than 1.2 g might be possible.

Last edited by w126, Sat, 18 Mar 2006 14:09.

Quote from Vain :

TWhen you think about how to construct tracks from a pattern of a lot polygons (let's say quads, for simplification) it really isn't too complicated in terms of CPU-time. There's still a lot of maths and thinking to do, but the CPU usage should be far lower than what f.e. the tyre model causes.

Having for example reasonably looking (and acting) ruts in gravel road would require significantly more polygons representing road surface per square meter than are used now. Then these polygons act as input to collision detection algorithm (you need to know where the wheels contact the road in every simulation step). The computational complexity of this algorithm is probably more than linear wrt number of polygons, so there is definitely significant computational cost involved in achieving such deformable surfaces.