rFactor2 Return of the development blog [Michael Borda]

Discussion in 'General Information' started by Markus Broch, Dec 26, 2017.

  1. Markus Broch

    Markus Broch Administrator Staff Member P1 gaming e.V.

    Like the phoenix rises from the ashes anew, it’s time to reignite this blog. A lot has changed since my last entry. We’ve come under new leadership with Studio 397, Britain voted to leave the EU, and America has a new president. But I’m not here to talk politics!

    Traditionally these blog posts cover the Brabham BT44B. That won’t be the case this time. However, we will be picking that up again shortly, so don’t worry!

    Due to the fact that this post was previewed in our release notes for a previous build. Some of the urgency in getting this blog posted was alleviated, which is why I focused on other items. So let’s get started, there’s something new in the air, a small but important change that comes to the tyre model. Taking a step back, admittedly, we’ve been doing things a bit wrong. Since the inception of rF2, we’ve calculated centrifugal forces in a ‘quasi-static model’, thinking this simplification was correct or close enough to reality to not matter. It was glanced over as fact, when in reality, accelerations should be calculated localized as the distribution in the contact patch can vary significantly to the original behaviour. Some correlation issues crept up over time, and as we’ve collected more data, it became apparent that it wasn’t on the data side. You may think that this might be sloppy, however, the reality is the way data is measured, interpreted (smoothed / adjusted / fitted), scaled, or worst of all, even copied between tyres, makes trusting data a very difficult thing to do. For those interested, Niels Heusinkveld, had a more in-depth piece about this kind of data ‘fitting’ which I pointed to in a previous entry. Anyway, without derailing myself too much, it’s not unreasonable to suspect issues with the data itself, in this case we had strong suspicions that the data was measured under a single condition, simply offset and then applied to different data points. This doubt left plenty of room for us to believe that our model was probably correct, when considering the obvious short-cuts the manufacturer had taken in measuring the data. So everything was rosy, we thought, and then we finally obtained the same type of data from another tyre manufacturer. This time, they went to the extra step of measuring at multiple loads. Once we had this corroborating information, it became obvious there was a glaring issue with our tyre model. Of course, this was an original part of the tyre model that hadn’t been touched for years, taken for granted. Furthermore, this was essentially a non-issue before the introduction of the contact patch model. After a little thinking and investigating, it became obvious that our ‘harmless’ simplification, wasn’t so harmless after-all.

    So now, with the latest build, we now calculate localized accelerations, and our QSA model, becomes a little bit less “quasi-static” than before. But what does this actually mean?

    To describe the effect in practical terms, after some early testing, it is quite obvious that the ‘speed sensitivity’ of tyres is decreased. A reduction of speed sensitivity, meaning that the tyres lose less grip as a direct consequence of rotational speed. The resulting contact patch is a little bigger (longer), especially when compared to the previous tyres under a combination of both high speed and load. As you apply slip angle, the longer contact patch increases the sliding speed towards the trailing edge of the contact patch, making tyres more prone to overheat at high speed. A larger patch also increases cooling (as contact conductance is the primary driver of heat dissipation in a tyre). In general, tyre temperatures will probably be slightly higher, so you may need to increase conductance slightly to achieve realistic temperatures. In terms of overall feeling, this is the biggest change in rF2 since the introduction of the contact patch model. This also marks the first major change to the QSA model itself in the 5 years since its rF2’s inception. To describe the change in words, would be to say that the car feels less ‘slidey’ and more stable in high speed corners. This was a prominent issue with the Radical SR3-RSX that we released earlier in the year which, I admit, would fishtail more like it was on bias-ply’s, than modern radial tyres. This has now been addressed with our latest release, and this is our best back to back comparison for those wanting to feel the difference in the models.

    For those of you who are modders (probably a good portion of those of you reading this), it has to be enabled with the following [QuasiStaticAnalysis] variable, in the .tgm file

    CalcPointAccel=1.0 // 0.0=use legacy centrifugal force calculation based purely on quasi-rotation and point position,
    // 1.0=calculate acceleration based on point position deltas

    Comparison of updated and older QSA Models. This tyre is ‘overloaded’ and in the old model, copes quite well despite that.

    Unfortunately, we’ve discovered that the new system is not always 100% stable, and as such, we’ve included the possibility to blend new and old behaviours. This instability typically causes tTool to get ‘stuck’ and as such, generally results in a tyre that will never complete the automated tests. The new variable does not effect behaviour what-so-ever with 0 rotational speed, and increasingly diverges from the previous behaviour with increased rotation speed. The 2 models are also equivalent if there is no tyre deflection/distortion. Therefore, the most unstable conditions occur at higher rotation speeds and with higher deflections. Generally speaking, these are the patch tests, undertaken at the end of ‘compiling’ your lookup table (or certain custom tests). So, the best way to find the point at which your tyre becomes unstable, is to run a deflection test at the maximum tyre rotation speed, and add in some lateral distortion while you’re at it (via ‘Patch Goal CG X’). Finally, throw in a small safety margin of about -0.02 or so. To find this balancing point, it’s a somewhat iterative process. A tyre that is used on a car with relatively low top speeds might well be able to get away with the full point-based accel system, as was the case with the Formula E car we recently released. On the other hand, for something like, say, an IndyCar, we might need a much lower value, perhaps around 0.5 or maybe even less. The original model was never intended to operate in this way, and so fixing the last remnants of instability may be difficult for us, but nonetheless, something we’ll try and take a look into for the future. If you’re unsure about your own tyres, just stick with a value around 0.5 for safety, which should work for all but the most extreme of tyres.

    That concludes this entry, keep an eye out for future blogs as we have more tTool changes in the works. The next changes are aimed at helping modders extract the most out of the tyre model.

    Merry Christmas and Happy New Year!
    Jochen Bendermacher likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.