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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Yes, but it is a very small error, especially when the position is then used to calculate accelaration.
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.
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.