The online racing simulator
Searching in All forums
(211 results)
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
Lancia Stratos
Rally version of Ford Escort Mk2 (with Cosworth BDA engine)
w126
S3 licensed
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.
w126
S3 licensed
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
w126
S3 licensed
AI could at least drive sideways (on purpose) when cornering on dirt parts of rallycross tracks. That would make them quicker.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.

w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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.
w126
S3 licensed
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, .
w126
S3 licensed
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.
w126
S3 licensed
Quote from axus :not sure if you have taken into account only acceleration of the wheel perpendicular to the road surface or just along the Z axis

I take full wheel acceleration vector into account in my current development version of RAFTyreExtract and when using this version lateral and longitudinal tyre forces differ slightly (around 1 %) from the values shown by previous released version. I have been trying to extend RAFTyreExtract to work with front wheels lately, but to do that I still need to research what is the meaning of steer from RAF dynamic wheel info in all possible cases.
w126
S3 licensed
Quote from colcob :Sorry about this, but you've been wasting your time. There is no way from the data we have to determine the unsprung mass distributions or the sprung mass distributions.

Sprung mass distribution may be obtained from raf (vertical loads) provided that there is a moment when the car is standing still on a flat surface. Total mass distribution may be taken from garage view (with driver and fuel). I hope the two distributions are not equal. The calculation from the first post seems reasonable, though I'll check it one more time.
w126
S3 licensed
Car's accelaration is second time derivative of (X, Y, Z) vector. You can normalize right-vector and forward-vector (their length should be 1). You can also construct up-vector as their cross product. Then lateral accelaration is dot product of accelaration vector and normalized right-vector etc.
w126
S3 licensed
Quote from axus :as the wheel goes along an arc...? Atleast your X and Y co-ordinates will be inaccurate

Yes, but it is a very small error, especially when the position is then used to calculate accelaration.
Quote :but is the CofG position (ie, height, distance from front axel and rear axel) in the RAF files?

Yes, it's all there, but maybe it's better to think of it the other way around. X, Y and Z in static wheel info is a position of a given wheel relative to car's cog. So Y is really the distance from a given wheel's axle, X is track for a given wheel's axle, height of cog would be equal to - Z - suspension deflect (with no car movement) + wheel radius.
w126
S3 licensed
Quote from tristancliffe :To find wheel accels (well, actually suspension accels but for the time being it will do). I took the difference in suspension positions (and converted it from mm to m) and divided that by 0.01 seconds. I then took the difference from each of these suspension speeds and divided them by 0.01 seconds.

Suspension deflect (RAF) is already in meters, so there is no need to convert them. But in this way you get wheel acceleration relative to car body. I think you should rather calculate wheel acceleration in track (world) coordinates, because in fact to find tyre normal load we use F = m * a equation so we must be in an inertial system. We consider only linear movement of the wheel so we take into account all the forces acting through the suspension and forces at tyre contact patch. Through the suspension there are vertical load, X force and Y force (all in RAF dynamic wheel info). I believe these forces are aligned with car body, not road surface. So in fact when there is body roll (cornering even on completely flat surface) part of X force affects tyre normal load. Similarly for body pitch (braking or acceleration). BTW, now I see I have to improve RAFTyreExtract a little. The other part of forces, one acting at the contact patch, which we want to calculate, is usually expressed in 'tyre-road' coordinate system and thus divided into tyre normal load, tyre longitudinal force and lateral force.
For now remaining part is calculating wheel positions in world coordinates, necessary to get linear wheel accelarations. We start at X, Y, Z (RAF data block) which is the position of car's CoG. Also in RAF data blocks there are right-vector and forward-vector, which define car orientation in world coordinates. We can also get up-vector, which is cross product of right-vector and forward-vector. They must be all normalized (their lengths must be equal to 1). Then to CoG of car we add:
X (static wheel info) * right-vector
Y * forward-vector
(Z + suspension deflect) * up-vector
The result should be the position of a given wheel in world coordinates at a given time step.
Last edited by w126, .
FGED GREDG RDFGDR GSFDG