Realism, ‘real life’, “RL” – big words that perpetually bounce off the walls of the simracing interwebs. The community demands ever more realism, and studios respond by investing considerable sums into marketing that aims to validate a ‘sim’ title by positioning it next to its real life motorsports counterparts: Getting a well-known driver to sit in a rig and do some laps is a familiar promotional strategy.

Of course we know it’s not that simple. It takes more than a visual association with “reality” to keep a sim on par with real-life motorsports. The high standards our fans and customers hold us to motivate us as a team to keep pushing. For us, achieving realism is not just about marketing. We believe that the underlying engine that powers our sim is in many ways unique in its vast capabilities to simulate car physics with astonishing detail and fidelity. Translating this potential into the highest level of realism, however, is no easy task. Accepting this challenge means it becomes very important to have access to real-world data and collaborate with the people who are deeply involved in real-world motorsports.

In a previous roadmap, we mentioned our recent visit to Duqueine Engineering in Ales France, where we worked on tuning the Norma LMP3 in rFactor 2.

Duqueine Engineering, whose HQ is situated at the Mechanopôle test track in Ales France, is a dynamic and motivated young company with big ambitions and the drive to push their team to the next level. We had the pleasure of being invited by Duqueine’s Team Principal, Yann Belhomme, and head race engineer, Max Favard. Max is not only knowledgeable when it comes to real-world racing and what it takes to set up a winning car, he also has a solid understanding of and real appreciation for “simracing”. He regularly organizes intense 1- and 2-day sessions in Duqueine’s cutting-edge sim rig to coach professional drivers and amateurs. Drivers benefit from immediate feedback that is partly based on telemetry and partly based on Max’s keen eye for racecraft. Max then critiques each stint and reviews telemetry on the fly with the driver.

Our first visit to Duqueine HQ back in May, which focused on the Norma LMP3 physics and testing, went so well that we decided to meet up again and put our heads together to expand on our initial collaboration. For our second visit, we concentrated on improving the current set of tires used by our GTEs and LMPs. Again, Max Favard’s expertise in race engineering, backed up with very specific feedback and data, proved indispensable. To our absolute delight, Indy Lights and now Duqueine LMP2 driver Nicolas Jamin had flown in specifically to help with this task. He tirelessly test drove every minute change over the course of three days, and his years of experience in multiple racing series were invaluable.

Rolling up our collective sleeves, we went through an intense series of sessions to put our tires under real scrutiny, which involved short and long stints in the Duqueine simrig, testing both wet and dry compounds. Following each stint, we exchanged ideas and checked the telemetry data. Several tracks were used as benchmarks, including a slightly earlier version of our newly-released, laser scanned version of Sebring. The opportunity to test this hyper accurate track with an experienced driver, able to put it through its paces, was an unexpected bonus. And we are happy to report that Nicolas, who has driven the track many times in various cars, was extremely impressed with the accuracy in the road details.

By overlaying the data from the actual car stints from previous races, we were able to adjust and, ultimately, implement tangible improvements to our current set of tires. Of course data was not the only criterion, we also took into account the overall feel of the car. Nicolas’ detailed knowledge of how the tires behave helped us modify and tweak the end result and get that much closer to achieving an optimal balance.

Making these improvements on the fly relied on our physics development team working remotely in real time. Changes were first discussed at Duqueine, we then exchanged feedback and questions back and forth between teams and repeatedly recompiled the cars. Each iteration was tested with the most recent changes in the simrig until everyone was happy with the outcome.

Although we did take some glossy pics of Nicolas driving rFactor 2 in the enviable Duqueine rig, the really exciting part of this adventure was the close collaborative spirit shown by all involved and the collective interest to improve physics – a hands-on, blood-sweat-and-tears endeavor with loads of coffee!

A big thanks to Yann Belhomme, Max Favard, Nicolas Jamin, and Laurents Hörr (who test drove the Norma in the first session), Jonathan Wagg, and the whole team at Duqueine Engineering for their hospitality and continual dedication – it was a blast! Your know-how helps us push ahead and keep it real.

Essentially, the above tests now allow us to test tyres under more conditions, helping to understand crossover points for compounds, and similarly, wet tyres. As well as allowing us to better visualise how additional track rubber and or surface water might influence overall grip levels. Finally, it also provides a means by which we can directly measure how a track surface type influence the grip and behaviour of a tyre. These are obviously important factors in influencing vehicle dynamics on different racing circuits. Finally, the parameters provide modders with a key tool to prepare for some future improvements we intend to bring to rFactor 2.

Some time ago, we disabled lookup table extrapolation for ‘safety’. We did so, as we had experienced some unpleasantness with rF2 locking up when extrapolation would lead to some extremely stiff (or soft) values that could lead the entire software to freeze. Instead, those have now been unlocked with manually defined ranges (use with extreme caution!). It affords the possibility to build tables slightly shy of required ranges, or can more realistically, help to re-purpose an existing tyre with lookup table for vehicles that might have otherwise fallen outside the range due to a higher top speed, or pressure, or whatever. Note that it’s pretty safe to extrapolate small ranges, in general (that is sticking to within maybe 5-10% of the min/max ranges defined in the [QuasiStaticAnalysis] section of the .tgm). However, for ranges significantly outside those, you will want to regenerate lookup tables for a couple of reasons… Obviously, if you’re extrapolating a lot, you’re further deviating from recorded and established values, as well as risking potentially unstable values resulting from doing so. On the other hand, if the car spends all of 1 second per lap at some really high speed, it may actually be advantageous to record your highest speed in the QSA slightly under the absolute vmax and that extrapolation can actually make the tyre slightly more accurate overall in the greater scheme. So use this knowledge responsibly, you have been warned!

Finally, the last new parameter introduced with B1110 is the [realtime] parameter:

This is a fix for certain tyres with oddly shaped (usually very long and ‘patchy’) contact patches that arise from extrapolation of the inclinations. Some time ago, we recorded the contact patch in greater resolution, and extrapolation has often become more of a nuisance than an assistance. For the record, many of our tyres use 0.5 or even lower values now.

To mark the occasion, there are new versions of the 3 TGM spreadsheets on docs.studio-397.com. The TGM generator, which includes the latest variables. The QSA batch test generator, which reorganises the result columns for compatibility with B1110. And, the realtime batch test generator, which obviously makes use of the new features highlighted in this article. There are many, many other changes, and for the eager, full change-log’s are available within the spreadsheets. Again, to open them, you’ll want to use LibreOffice (ideally on the 5.4 branch as that’s what they have been built and tested against).

For a long time, we’ve had an issue, whereby tyres would incorrectly overheat when running off-road. Simply put, this isn’t particularly realistic, and when you re-entered the track, you end up with hot squirmy tyres that can often send you into another spin due to excessive temperatures. Although similar in traits to tyre dirt pick-up, the effect in the way it operated, wasn’t particularly realistic, and we hope to eventually do tyre pick-up in a more realistic way. Anyway, without derailing myself too much, we have a solution for the problem of excessive heat generated by tyres in off-road conditions. In fact, this new tech allows us to control the temperatures due to a wet road surface too. If needed, it even allows the user to slightly tweak the sliding friction temperatures generated on dry asphalt, if your tyre is slightly off from the data you expect (something that was not possible before). In other words it’s the first time the user has a direct control over the amount of sliding energy that is transferred to the tyre as heat. Some of the more eagle eyed among you, might have noticed these parameters in the tyres within the TGM database, with the release of build 1110, will become active. We’ll also explain exactly what they do. To be 100% clear, these are all [Realtime] parameters for the .TGM file.

The TGM [Realtime] entries (and their current defaults) are as follows:

Each of the “TerrainEffect’s” refer to their corresponding .TDF ‘sound=’ variables. If a surface calls for a grass sound effect, we can safely assume it’s grass. If it’s “Dry” we assume it’s a normal hard driving surface (concrete or asphalt). The first value in each variable, is a blending variable for static and sliding friction coefficients. Given by:

This allows a bit of freedom to adjust the grip coefficients to make off-road slip curves slightly less peaky. The third variable, is the most important change, and allows us to specify the fraction of sliding power applied to the tyre as heat energy. On dry asphalt, this should generally be 1.0 or at least within 10% of that. Of course, sliding on loose dirt is actually dissipating a lot of the energy by rubbing dirt particles against other dirt particles, which may never come in direct contact with the tyre. So only a fraction of the sliding power goes into the tyre as heat. I’ve found that to get the best results, we have to sometimes go as low as 0.05 of the heat energy.

While the defaults are above, the values we found through testing, suggest to use values around:

Generally, whatever type of terrain you are running over (according to the TDF Sound variable), it uses that line. One exception is when Sound=DRY and we detect standing water according to RealRoad. Based on the amount of standing water, it blends between the DryTerrainEffect and WetTerrainEffect.

What is the point of this? Well, two-fold.

One is that you could do something like average them out to create a less peaky slip curve. If the first two variables are both 0.5, it essentially makes both coefficients the same value, which would be the average of the old coefficients… I’m not sure if I’d go that extreme (it might even make the model a little funky trying to switch between static and sliding bristles).

The second point here is that perhaps you want to make some minor adjustments to the grip of some off-road terrains with these TGM variables. If you bias both of those numbers towards using the (presumably lower) sliding coefficient, let’s say numbers like 0.6 and 0.9 [respectively], then you’re going to reduce the grip on that type of terrain. Lower numbers like 0.0 and 0.2 would increase the grip, because it’s biasing it towards the higher static coefficient.

The third variable simply tells us how much of the sliding power should be applied to tire heat. Originally (and now by default), all of the sliding heat energy is applied.

Also new is:

InternalGasMolarMass=0.02897

Which, although doesn’t have anything to do with the previous feature set, allows more adjustability in the inflation gas used, this can influence pressure build-up of the tyres.

In the last blog to cover the tyre model, we promised to include some new features to help analyse tyres. These new features allow realroad adjustments in tTool, which allows you to play with terrain surfaces and measure the results. tTool was also difficult to correlate with on track experiences because the track was always set to standard properties, which meant a standard surface roughness and a green (devoid of rubber surface).

As implied by the title, this blog will actually cover a new spreadsheet release. This will be a relatively short entry.

Getting started, this is actually an update of a previous spreadsheet up to V0.33 (up from 0.23). The rF2 Physics Calculator, as it were, has been refreshed, with a few bug fixes, many new features and much improved feel and aesthetics. To ensure that everything goes smoothly, I strongly recommend to download LibreOffice 5.2.7 (or 5.3.7) from libreoffice.org, as one or two new features are necessary for the spreadsheet to output correct data.

So what’s changed? I won’t bore you with all the details (though you can check the spreadsheet for most of the boring details), suffice to say that there has been some effort made to usability, presentation, and accuracy. There are more outputs, more displays, and should slightly improve the speed of producing something tangible.

As you may be acclimatised to, the base data set is that of the FISI 2012. That is, if you take the outputs of the spreadsheet (orange tabs), you’ll end up with the latest spec FISI 2012 physics parameter files. These files correspond to the HDV, engine.ini, gear.ini (optional) and ultra chassis.ini. There is also a headphysics.ini output, but this is purely graphical (cockpit camera) and does not alter the vehicle physics, finally, new is a damage.ini output too. If you had managed to become proficient with the older spreadsheet, the new one should feel familiar and somewhat refined version of it, with more features. Our recently updated FISI 2012 has these latest physical parameters, and I hope you will have found the car more approachable and intuitive to drive. The car itself has tweaked aerodynamics, all the latest features, and benefits from some small spreadsheet bug fixes.

There are always improvements to be made, and I will attempt to keep this spreadsheet up-to-date as new features are added to rF2. But for now, I’m going to keep this short and sweet. Hope you modders out there find this tool useful!

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.

As you will no doubt be aware, a lot has happened in recent weeks. I would like to assure you all that despite the change in management, the blog will continue into the future.

Next up, to an answer to a question from the floor. I mentioned last time, that we basically optimize the tyre for their state that they see in corners. This is because the majority of lap time is gained through corners. You spend a significant portion of time cornering, corner apexes are also the slowest speeds you see on the lap, so you spend a good portion of time there. Higher apex speeds also mean you spend less time braking, even though prioritizing braking would allow slightly later braking. This is all a generalization, but cornering is predominantly the most important way to gain lap time.

With that out of the way, this is the last major part covering the tyres for the Brabham itself. Although we’ll have one more post covering the finishing touches. Specific aspects of tyre design will also be covered in the future too.

Now, continuing from last time. We have our basic tyre created, its basic geometry is done, a lookup table has been generated. How do we tune, and improve the tyre further? How do we know whether the tyre correlates well to a set of data? Data that we either have in our hands, or sometimes as an abstraction in our minds (if we’re unfortunate to lack hard data). It’s time to get plotting. To help with this, we have a new spreadsheet to generate realtime batch tests to be used for tTool available here.

Realtime Batch Tests
To begin with, realtime batch tests provide a way for us to analyze a tyre over a given range of conditions and measure the outputs. Essentially, via these means, we’re able to create slip curve plots, rolling resistance plots, aligning moment plots, deflection tests or just about anything else you might desire. The spreadsheet is simply a way to help generate these test cases. If you used the QSA Batch Test spreadsheet, then the realtime batch tester should feel somewhat familiar. I have tried to be somewhat descriptive within the spreadsheet, so be sure to check out the comments. To help get started, on the first sheet ‘1 General’, you’ll see another ‘Information Desk:’ describing some of the basics. Still staying with the ‘1 General’ sheet, you should specify some basic data on the left side. The most important are fields are highlighted in orange ‘Approx. Radius’ & ‘Max Load’, among others, which are used to define the starting point of the tyre dimensions. They also define test boundaries to make the tests run quicker and keep them more relevant.

Next is to tackle the ‘initial tests’, named as “1 Test-Initial” in the spreadsheet. In similar fashion to the QSA Batch Tests, we need to collect some data from the tyres before we can generate specific tests optimized for them. Of course, realtime batch tests are performed MUCH faster than are QSA tests. A single QSA test can take between a 30 seconds and an hour (or more in certain extreme cases), realtime tests typically take a only a couple seconds each. So this should be done rather promptly. It will look similar to the following:

A quick look inside the spreadsheet.

So what do all these things actually do?Start – this is just defines a starting value, or base value to work from.Step – Essentially, this is the linear value increment as for every step.Stepï¿½ – This is an increment based on the square of the Nth step value.# of Steps – The number of total steps before resetting itself and starting from base again.Step Count – How many times before lines we go before we actually consider the step to be an increment.Disable Before – Disables the value BEFORE this Nth step. If you have a ‘Fall-back’ value defined, it will use that instead of leaving this blank.Disable After – Disables the value AFTER this Nth step. If you have a ‘Fall-back’ value defined, it will use that instead of leaving this blank.‘Fall-back’ – A fallback value to use if the step doesn’t meet any criteria or results in an error.

For the initial tests, the pre-loaded values are set to recommended specifications, as such, if you filled the ‘1_General’ sheet correctly, it should not require any alterations. However, the spreadsheet remains open to edit as you wish if you feel you’d like to do things differently.

Vertical Deflections
You should have already adjusted the tyre correctly to make the vertical deflections match some set of expectations via the geometry model (QSM, quasi-static model). Nonetheless, you may consider testing them (your tyre) within the realtime model as a verification or to aid in setting up the .TBC tyres to correlate. You can also alter the ‘LoadVsDeflectionMultiplier’ variable in the realtime section of the TGM file, which when increased, artificially makes the tyre stiffer vertically, while values less than 1.0 will soften the vertical stiffness. If you need to use a value significantly divergent from 1.0, you should consider an alteration to the design your tyre construction properties. It is clearly easier to do this while you’re early in the design phase. In other words, it would be wise to ensure your tyre delivers accurate results in the quasi-static analysis section of ttool, prior to building entire lookup tables. Lookup tables may take 12-36 hours to generate, depending on your hardware, the detail of your tyre itself, and the number of test permutations of your lookup table.

Rolling Resistance
If you’re satisfied with the vertical stiffness, the next thing to move onto is rolling resistance. All tyres produce some rolling resistance. This is primarily due to energy dissipated by the tyre tread through a process known as hysteresis. Essentially, kinetic energy is lost through resistance to deflection, converted to the form of heat energy. Therefore the amount of deflection plays a role as well as visco-elastic effects (essentially damping). Generally speaking, tyres with greater hysteresis also have higher grip. This benefit will be greatest on surfaces with a rougher road texture, but also wet surfaces where the opportunity for chemical/molecular adhesion is vastly reduced. In the end, rolling resistance is one of the first things to adjust. It is also relatively simple to alter. The fact that it has a direct bearing on other tyre attributes also gives it precedence. When creating the tyres, you will have run with some placeholder values. You will then need to alter them based on the results from such tests.

The vertical damping multiplier refers to individual bristles in the cross section. From left to right, we have 7 of these ‘columns’. The reasons the individual columns are adjustable is mainly to do with the fact that some distortion is partially ignored in the edges of the tread. The calculation is based on how much the tyre has been deflected, while this is fine in principal, it ignores some secondary distortion and flex, so this is a compensatory mechanism.

If your tyre’s overall rolling resistance is about half what it should be, you’d roughly need to double the BaseDamperPerUnitArea (middle value) and HystereticVerticalDamperPerUnitArea. If it’s too high, you’ll need to reduce it by roughly the proportion that it’s too high by. If you need more at lower speed, and less at high speed, you would increase HystereticVerticalDamperPerUnitArea and decrease BaseDamperPerUnitArea. As I touched on previously, you will need to consider that at higher deflection, the bristle is moving though a greater range and this will increase rolling resistance.

For the Brabham BT44, the expected rolling resistance coefficient is approximately 0.015 for the front, and 0.018 on the rear tyre (using the TBC values as the basis). From the previous blogs, we also know that bias ply tyres have a predisposition to a higher rolling resistance than do radial tyres. Furthermore, racing tyres place a greater emphasis on grip, than they do rolling resistance. As such, these tyres generally use a rather high hysteresis compound. So these particular tyres will have just about the highest rolling resistance of those used for any car. For example, we might expect around 0.007-0.01 for a modern radial street tyre, and 0.009-0.014 for a modern racing radial. It should be noted that these numbers are certainly not a one size fits all, but the vast majority of tyres will fall within this realm, at least under normal operating conditions (and on a hard surface). Rolling resistance also varies with load, speed, and temperature. As you increase load, deflection rises, and with it, rolling resistance does too. As such, it’s a good idea to test under multiple relevant conditions.

One final thing to note about rolling resistance, is that the latest TGM variables, “StaticDiffusiveAdhesion=(,,) & SlidingDiffusiveAdhesion=(, , )” also slightly contribute to the overall rolling resistance. These variables effectively ‘bond’ the tyre to the asphalt, which in turn requires a force to separate from the asphalt, a phenomenon which also slightly extends the contact patch.

An example of the output of rolling resistance at various loads.

Lateral Sweep Tests
At this point you’ll probably be eager to see where the peak slip angle is, and the overall shape of the slip curve. These can be performed with the tests provided by 4_FullSweep or 5_LatPeaks. There are also preset longitudinal tests provided @ 6_LongTest. Finally, you can try the ‘7_Combined’ tests to generate a sort of 3dimensional table.

What do lateral tests look like? My own data for the BT44 tyres looks something like these:

Bias-ply tyres typically exhibit a wider peak slip angle, while more modern radials peak slightly earlier with a slightly larger falloff. Performing these tests will measure the data necessary to capture these characteristics in your own tyres. Of course, the lateral and longitudinal stiffness data for the tyres are ideally determined by the QSA batch testing spreadsheet I introduced last time. Those tests provide a good representation of the high detail model into the realtime model. Thus, if you find that the tyre ends up having too tight of a slip angle or too loose, you would ideally reconstruct your tyre with stiffer or softer belts, or bias-plies or whatever you feel might be the best way forward. The discrepancy between what you intended and the actual results essentially form the basis of how much you will need to alter the construction by. All else being equal, the peak slip angle is mostly dictated by the stiffness of the tyre in the tread area. Hence bias-ply’s exhibit a wider peak slip angle than do radial tyres. Rubber stiffness and properties also have some effect and obviously temperature effects are not to be forgotten here. Something to note that might not be intuitive, is that at higher temperatures rubber will grip more optimally at lower sliding speeds, than at low temperature, which will find grip at higher sliding speeds. The flip-side is that the rubber can actually distort more at high temperatures as the compound softens. So the actual sliding speed at the surface may actually reduce as the temperature increases. For these reasons, there’s no better substitute than testing the realtime model with the batch tester to establish these properties.

The sky is basically the limit when it comes to realtime batch tests, so feel free to test whatever you need, in whichever way you feel is best. For example, there are additional pre-configured tests (6 & 7) covering longitudinal slip or combined curves. They operate in a similar manner and are just basic examples of what is possible. The only difference is that for the longitudinal tests to be appropriate, we need to run an additional longitudinal slip offset value. Essentially, the purpose of this is to correct the ‘longitudinal slip’ to provide 0 longitudinal force at “0% slip”.

In part one, we mostly defined some generalized things about tyres, and a very basic implementation with the spreadsheet. Part II will go further into implementation. The final part, will cover mostly real time parameters and optimizations. Previously, we got as far as producing a ‘theoretical’ tyre in the spreadsheet, but never ran it in +tTool. Though, a ‘completed’ tyre is already in the V0.66 Brabham BT44B available on Steam, it should be noted that it is still a placeholder tyre. I never expect the first attempt to be the final attempt, either. Nor the second if I’m honest. It is rather difficult without trying it in-game (or at least in the ttool real-time model) to know how the tyre will react. Inevitably, we do need our tyre lookup table built up to help us make future improvements. Not all is doom and gloom, we can improve our odds by looking at some general properties.

Before I get started, David Wright had pointed me to a couple references in the comments of the previous blog entry. These confirmed some things and but also made me reconsider some design elements of these particular tyres. For one, the cord density was supposedly 25-30 strands per inch. This works out to a ‘strand spacing’ of 0.0254/25 = 0.001016m (1.016mm) to 0.0254/30 = 0.000847m (0.847mm). If we stick with our previous assumption of protective rubber coatings filling in about 50% of that gap, that would give us a strand diameter range of about 0.847/1.5=0.564mm to 1.016/1.5=0.677mm. I had previously used ‘24.2’ per inch but this also made them too thick as a result. The end result is not too dissimilar in this situation, anyway.

Design considerations
In general the best way to learn is via experimentation. A few rules or guidelines can be picked up, and of course reading existing materials out there is also highly beneficial. So this time, I’m going to be mostly looking at the analytical options that tTool provides.

Shape & Contact Patch Pressure Distribution
Last time around, I explained that we should shape the general tyre to match the dimensions of the real tyre. In the end, one of the goals of a tyre designer will be to create a smooth even contact patch pressure distribution. This essentially means the footprint of the tyre should have the no points where the pressure significantly varies from another. In tTool these loads are shown as blue vertical lines (if your tyre nodes are evenly spaced, they will correlate well with pressure). They appear in tTool as below;How a tyre contact patch appears up in the QSA section of tTool.
A tyre design will always have some trade-offs, though, which don’t allow the contact patch to be completely even throughout. To add an additional err of complexity, the trailing edge is also the most important when it comes to temperature. The rear of the contact patch is dominant when it comes to heating because the sliding speed is highest. So despite the load reducing at the rear of the footprint, we tend to see any disparity here will cause the majority of temperature anomalies in a tyre.

Michelin tyre modelling.

From this we can gather that, as a generality, a shorter and wider contact patch will create less friction heating than that of a tyre with a long contact patch. As such, if any of our tyre segments appear to be generating too much heat, we need to manipulate the tyre such that the trailing edge has a flatter pressure distribution. If our overall tyre is generating too much sliding heat in the corners or not enough, we could attempt to change the shape of the contact patch, either extending or shortening it. It’s not always black and white though, as the main source of tyre cooling is also contact conductance (ground contact, essentially). In order to lengthen a contact patch, the tyre must be made narrower or softer. This means a greater level of distortion in a relatively small space, further increasing heat generation. If our tyre dimensions are correct, the only thing left to tinker with will be the stiffness / construction properties (assuming we have a target internal tyre pressure). People might have noticed that the V0.66 version of the Brabham actually had excessive heating on the outer edges of the tyre. It’s not always a straightforward thing to correct. None the less, it can usually be achieved with subtle shape changes, by decreasing the radius of nodes that correspond have too much contact pressure.

Prior to generating the full lookup table, which takes many hours. We can analyze a tyre’s contact patch, using tTool. We’ll simply need to run a few deflection tests in the quasi-static model. After loading our .tgm file in tTool, we need to configure the gauge pressure, temperature and rotation to something plausible, conditions you would specifically like to check. Assuming the tyre is suspended above the ground plane you should have ‘Symmetric Test’ enabled, as this could speed up the test by about 200x (or how ever many tyre sections you have defined). This is useful only for tests where you are not deflecting the tyre, because it assumes the tyre forces are even the whole way around the tyre. Now click ‘number of iterations per frame’ and enter something like 500. After a couple dozen seconds or so, the tyre test will be ‘100%’. You can pause the test at this point by pressing ‘Perform One Iteration’. Now take a mental note of the ‘peak radius’. We’re targeting a plausible deflection, so let’s say we want a 7mm deflection and the radius is 0.255m. We’d want to set the ‘Ground Height’ to -0.248m (negative as the patch is below the tyre center). Make sure to unselect ‘Symmetric Test’. Now set iterations per frame to something like 9, press CTRL+D to disable graphics (this will speed things up a little bit), you’ll have to wait some minutes. The first meaningful results will come in when the percentage done reaches about 30%, but the shape of the contact patch will keep subtly changing until you reach 80% or higher. In other words, in the early design stages of your tyre, you don’t have to wait until this test is 100% complete. You will already be able to spot some patterns in the contact patch that require the tyre to be adjusted. In order to examine the tyre adjust the camera, to view the tyre patch from the side, and focus on the ground plate. You can manipulate the camera by pressing CTRL+Numpad keys, and CTRL+ALT for more precise adjustments. One of the best positions to view the patch is mostly from the side, zoomed in as far as possible (CTRL+Numpad3), CTRL+Arrow keys also help to position the camera. Which may look something like:A tyre contact patch and corresponding loads, with some room for improvement.

In this tyre, the contact patch is loaded too much on the outside, requiring either more pressure or a higher rotation speed to flatten the contact patch. As a designer, your duty will be to make the contact patch as smooth as possible, over different conditions that the tyre will see during track use. Such as high load, high speed corners and low speed corners alike. Of course, in reality, there is no such thing as an optimum pressure for a tyre. This is highly load dependent, so you will have to keep this in mind as you design your tyres. This is part of what makes tyre design an iterative process. Inevitably, when you think you have optimized a tyre, you will be able to make an even better version in the future. Just to note, a special emphasis should be placed under conditions you’d see in cornering. For example, the default front camber on the BT44B is 1.5 degrees. The typical load for an outside tyre is about 2500N, the grip coefficient at this load is about 1.5. This gives a lateral force of 3750N.
Another tyre:A different type of tyre and some plausible conditions under which it was tested.

The most important configurable aspects of this tyre have been highlighted. For this street car, loads are typically seen around 1900N on the outside tyres. The grip coefficient is also around 1, meaning a lateral force of ~1900N (ok I went slightly over). The optimum warm pressures are around 160kPa, and the tyre typically sees about 80ï¿½C during track use. The typical camber setup is around 1.8 degrees too. Camber is a somewhat difficult attribute to determine though, because the optimum cambers will vary, and the actual camber of the wheel changes due to suspension geometry, body roll and even flex. Still, this gets us in the ballpark. Interestingly, the lateral flex / spring rate for most tyres is actually similar or slightly softer than the vertical spring rate for that tyre. So I was nearly able to guess the distortion required to record a specific lateral force. The easier way to specify the correct lateral force is to type a “Patch Test Force X” value, but entering a “Patch Goal CG X”, typically returns a result slightly faster.

Vertical Stiffness
Vertical stiffness is a product primarily of the tyres construction properties. Mainly the thickness and type of materials used, however ply angles also bare significant influence. As a generality, a more laterally laid ply will grow more with both rotation rate and tyre pressures, while producing an overall stiffer tyre. As with any ‘rule’ there are exceptions as you reach toward either extremity the situation may completely reverse. It also gets more complicated as you add additional ply layers. For example, a 0 degree belt will severely inhibit growth of the tyre, retaining its original shape much more closely. In the end it will also produce a softer tyre when faced with pure vertical or lateral forces. Though I’m not aware of any such tyre, in theory, if you placed a 90 degree belt in the tyre, this would also produce quite a soft tyre. In contrast, this is mainly because the construction will be incapable of maintaining the tyres’ original shape. It will grow significantly with pressure & rotation producing a narrower contact patch resulting in a tyre with a soft initial spring rate that increases significantly with deflection. You’d essentially end up with a significant arc in the crown section, and mainly due to the small size of the contact patch, the tyre will be quite soft. The strongest construction angles would be at approximately 45 degrees, as this distributes any forces over the largest possible area.

Translating the QSA model to the Realtime model (Another Spreadsheet!)
In the previous blog entry, I mentioned that we’re using a brush model with a 6-DOF rigid ring. The nature of this model means that we need the bristles to flex independently of the ring, which in itself is infinitely stiff (this is common practice, as it saves on processor time). This flex model is done through the contact patch tests for vertical deflections, but requires the following the parameters for the lateral and longitudinal flex model. The parameters are provided by the following values from under the [Realtime] section:

In order to come up with reasonable figures for certain parameters, +tTool had introduced batch tests some time ago. To generate meaningful data from the batch tests, we have a new spreadsheet which is called “QSA Batch Tester V0.26 – BT44 Rear.ods“. You can grab this from dev corner on rFactor.net.

QSA Batch Tester Spreadsheet
Upon opening the spreadsheet, you’ll hopefully notice “Information Desk:” on the first sheet. This is a sort of step by step guide explaining its usage. Though I will further elaborate here on what it does, and how to use it. The spreadsheet is a way to generate a set of conditions in what to test a tyre in the QSA section. The Quasi-Static model is a very high detail stiffness model. Friction data is not simulated in this model rather, physical tyre dimensions, mass, inertia and stiffness is. While friction, wear, and thermodynamic properties are defined entirely within the realtime model (though thermodynamics are dependent on the QSA model too). The ‘QSA Batch Tester’ spreadsheet is prefilled with values designed to measure the lateral and longitudinal stiffness of the tyre, and how it varies over various conditions. These tests are rather slow and will take several hours to compute on most machines, so you might want to run them overnight or in the background. In short, the peak slip angles are dictated by the tyres overall stiffness, and also how the compound reacts to temperature. For those familiar with tuning the old rF1 .TBC tyre file, the bristle spring rates can be tuned in a similar way to adjusting the LatPeak= values. If you soften the spring rates, the peak slip angles will be higher. If you want the peak slip angle lower at high loads but similar at lower loads you’d typically reduce the ‘tread’ stiffness value and increase the belt stiffness. This defeats the purpose of using QSA data to build up stiffness tables though, but it can be useful in determining whether the tyre construction properties need altering. i.e. if a desired peak slip angle is say, 9 degrees, and your current tyre provides about 7 degrees then the tyre stiffness will need to be decreased to approximately tan(7)/tan(9). So we could then use that knowledge to tune our tyre to be that much softer in our next version. However, like with most things, care will then be needed to make sure this does not overly soften the tyre vertically. In such a scenario, the contact patch will be longer, which then may require the tyre to be even softer to keep the peak slip angle higher. All things being equal, it might look something like:

The angles are hypothetical, the fact that the contact patch is spread over a greater area effectively increases its spring rate. This is due to the fact that more bristles will be in contact with the ground. The end result is that the angle is far steeper because the patch is both shorter, and more distorted.

The next part covering tyres will be the last major one, mostly covering the Realtime model. It will be paired with yet another spreadsheet release, for generating Realtime batch tests. These tests can be used to build up friction curves, or other curves as desired.

I know people have been waiting for this for some time. What process do I actually use to create the tyres? What data do we need, and how do we use that data? These questions are deep and will have to be covered over at least a couple separate blogs. The first area is always going to be the data collection phase, and initial implementation, this is what I’m covering this week.

Research/Data Phase

This is a fairly time consuming aspect. You need to start here, you need to gather as much information on your tyres as possible. As long as it’s reliable, more data is always helpful. The key word here being reliable. The problem for most, is that you’ll likely have to rely on data from the internet. Even for those more fortunate, who are blessed with manufacturer data, tyre data is seldom measured in a way that correlates very well to real life. Niels Heusinkveld covers this well in an older forum post available here. The gist is that raw data is noisey, provided data may have been poorly ‘fit’ and incomplete and that surfaces and machines can produce vastly different results. Because the temperature of a tyre changes quickly with a little sliding, for example, a sweep test will yield different results loading up the tyre (upswing), compared to unloading of the tyre (downswing). Many video examples exist regarding how tyres are measured, for those interested. One such example can be seen here. In any case, we’ll try and outline useful data through a sort of list of what is required, and how it can be used. Obviously, we need to know the tyre size and any other codes (compounds, tread pattern, etc). The size for the Brabham BT44B, was collected during the first blog, when selecting placeholder tyres. As a reminder, they are Goodyear 9.2/20.0-13″ for the front and 16.2/26.0-13″ for the rear. Clearly, these are imperial units and the first number represents tread width, followed by overall diameter and finally rim bead diameter. It does not seem possible to buy these tyres from Goodyear anymore. Given the time that has elapsed since these were new, it also seems unlikely to get originals or that manufacturers would still have the data concerning them. Furthermore, if you could get your hands on 40 year old tyres, some of the data will be poor quality. Shore A hardness readings for example, would be completely irrelevant as tyres significantly harden with age. It’s always a good idea to ask manufacturers, which I have done. Unfortunately, I did not get back any meaningful data, other than some tidbits. Therefore, I’m going to have to find my own data. This is also partially why the Brabham was chosen as the blog car, because we knew manufacturer data would be scarce (and/or obsolete), and so the rules of confidential data need not apply. This then forces me into a situation most modders find themselves in, hopefully making the blog more relevant.

The closest current offering Goodyear has for the fronts are 9.5/20.0-13’s. This is listed in their vintage Sports Car Catalogue. Interestingly the catalogue actually lists them as having a 9.1″ tread width. This means they are likely very similar to the grand prix tyres of old. The application is listed as “FA” presumably referring to Formula Atlantic. A series which began running in the 1970’s. Obviously, they were not as quick as grand prix cars, having only 1.6L engines, and so likely also have slightly different tyre constructions.

Meanwhile, Avon seem to have taken up the near exclusive challenge of supplying historic tyres for older racing cars. Some basic dimensional specifications can be found at their website. These sources, combined, are still not really adequate to fully replicate these old tyres. So we have to continue searching, but at least we’re making some headway.

The 1970’s and 80’s…

So what do we know about 70’s F1 tyres? Generalized information can still be helpful. We know they were a bias-ply construction as Michelin introduced the first radial in 1977. If we travel back in time to 1975, what literature and/or data is out there? Untimately, not much. What we do know is that Goodyear had just come out on top in the tyre wars and didn’t need to develop heavily as a sole supplier. This wouldn’t be the case in 1977, as I mentioned previously, when Michelin would introduce the radial tyre to F1. Either way, this particular fact is irrelevant to us. The fact it was a slight lull in competition however, is relevant. Even though Goodyear would continue with some development in this time, it’s not likely they would have felt the need to play around with complex tyre structural changes to keep exploring the limits. Interestingly, even in the early 80’s Goodyear would keep the bias-ply competitive with Michelin, until finally succumbing and adopting the radial construction type in 1984. Unfortunately, information covering F1 tyres of any sort seems exceptionally hard to come by (and if anyone has found some good literature, I implore you to come forth and reference your source in the comments section). It would seem sensible that Goodyear may have indeed adopted some of the techniques of radial tyres and probably used something more like a ‘belted bias’ tyre in the early 80’s. This wouldn’t have been the case in the mid-70’s. One key source of data are old race reports. We can gather that tyres lasted the full race, without the need to change them unless damaged. Though pit-stops times had started to improve by then, it would seem the benefit of fresh tyres was still lesser than the time required to change them.

More on Construction Types

Tyres are complex, damn complex, feats of engineering. Sadly, this is a world steeped in mystery, secrecy and even ignorance. So I will try and share some of my knowledge, especially thinking in terms of what could help modders. In terms of construction, we have the 2 main philosophies, bias-ply and radial. The first, and earliest construction type is the bias-ply (AKA cross-ply). The main construction differences between the two are outlined reasonably well at Michelin. That said, construction is often complex and giving them these labels may even be partially misleading as construction designs can incorporate design elements of ‘competing’ methods. The belted bias tyre is a third design which broadly speaking, is acknowledged as a hybrid of the two. A belted-bias tyre is essentially just a bias-ply tyre with an additional ply layer, called a belt layer. Normally, the belt ply in a belted bias tyre operates at similar ply angles as the supporting carcass beneath. However, an exception to that ‘rule’ (rules are meant to be broken, after all) would be drag racing belted bias tyres, but I’ll come back to this later.

The Bias-Ply Tyre

What do we know about them? How do they relate to 1975 Grand Prix tyres? I’ve already outlined my suspicion that they were likely to be a more ‘conventional’ tyre of bias-ply. What I mean by that is, an even number of plies, running at exactly opposing angles. They probably numbered 4 in total, as was common practice, as 2 likely wouldn’t have been sufficient to curtail the enormous growth of the tyre at GP speeds (top speeds of around 310-320km/h). We also see that the higher the speeds required, the lower the ply angle in the crown of the tyre tends to be. This is again, to resist growth of the tyre at speed, and keep the tyre flatter at speed. If you imagine a tyre with radial plies only (operating @ 90° to the direction of travel, i.e. bead to bead). Such a construction would essentially create a round tyre at high pressures and or speeds, significantly narrowing the useful part of the contact patch. A hypothetical tyre with a 0° belt would stabilize and severely inhibit growth due to rotation, but would not provide any lateral support. Therefore, lowest ply angle for a bias-ply is typically around the 26° angle, with high performance road tyres in the range of 30-35° and normal tyres of the time around 38-40° (ref: page 8, Continental). Depending on the construction, the ply angle may also gradually increase nearer the bead of the tyre as explained under the bias-ply section of this Wikipedia entry. Therefore, those previously mentioned angles are typical crown / tread angles. The crown is simply the ‘treaded’ area of the tyre, the part which is intended to contact the ground in normal use.

A visual representation of the tyre crown from tTool

As a result of their structural attributes, bias-ply tyres also generate more friction between internal components. As a consequence, bias-ply’s generate more heat and have higher rolling resistance. This is due to flexing in the tread area, where inter-ply movement is far greater than with a radial. On the other hand, they also have a more forgiving nature and typically generate grip at higher angles of slip. The bias-ply was phased out very slowly since the inception of the radial in 1948, by the early 70’s, radials were the common theme for road cars, which were the first to adopt the new technology. The first race cars to use radials were Grand Prix, beginning in 1977 with Michelin. Since then, most major racing categories have adopted them, with NASCAR being one of the last to make the move in 1994. Lower tier categories may still use bias-ply tyres, such as Formula SAE, and while we certainly see them in karting.

The Radial Racing Tyre

A “perfect bias” would hypothetically be 45°, although it seems hard to find a clinical definition of where the cut-off is. It seems that a radial would have to have it’s casing structure be closer to 90°, than 45° in the tread region. Does that mean 67.5° is the cut-off for the definition of a bias-ply tyre vs a radial tyre? I believe so. To confirm this, patents happen to be a good source for generalized or specific tyre properties. For example, this patent states that a bias tyre has a ply angle of “at about 25-65° angle with respect to the equatorial plane of the tire”, leading further credence to my cut-off threshold. Most high-end racing radials actually incorporate a casing structure that operates at an angle of approximately 70-75°, giving them some bias-ply strength in their sidewall, while retaining the definition of a ‘radial tyre’. Racing tyres therefore, are really a hybrid of radial and belted-bias constructions. There may be other specialty tyres with ply angles of below 22.5° and such might be defined as another construction type altogether. Such tyres are unlikely to be used on race cars, or any other cars for that matter. If such a tyre exists, it would likely be reserved for novelties, such as for R/C (remote control) cars or similar atypical tyres. Radials are often more complicated though, tending to have a 0-degree ‘belt’ laid atop of the main belt, usually made of nylon or rayon. This is known as a cap-ply. This my not stretch the entire tread width either, and in the case that is covers only the shoulders, is known as a shoulder-cap ply. The purpose of such a “0-degree” belt is almost always to improve high speed stability of the tyre. For road cars, shoulder-cap plies are intended to reduce potential fatigue by softening the harsh transition from belt to sidewall. The edges of the belt can actually cut into the tyre, potentially damaging the rubber and carcass plies, eventually leading to failure. Even though race car tyres take far more abuse, they have a typical service life of only 50-1000km. As such, the overall fatigue resistant requirements are still lower.

To help visualize the different sections and components of the tyre, you may find the following diagram useful:

Please note that different engineers will use different terms to describe certain parts of the tyre. For example, one might call the rubber surrounding the bead, a filler rubber, while others call it the apex rubber. A shoulder-cap ply may also be known as a shoulder-insert. A cap ply could be known as a stabilizer ply, undertread ply, or even a fabric-belt or simply a belt. So be aware of aliases, though most are somewhat intuitive.

The belted-bias tyre

Belted-bias tyres are somewhat rare. Despite ‘racing’ tyres often being called a hybrid of radial and bias-ply tyres, not many actually fit the definition of a belted-bias tyre. Belted-bias tyres are essentially a bias-ply tyre with a ‘belt’ or ‘breaker’ layer in the tread section to improve rigidity. This belt ply tends to have a similar or slightly lower angle to the carcass plies that lie directly beneath. An exception could be drag racing tyres, which often have near 0° belts. This is due to the desire for additional strength only in the longitudinal direction. So for optimum longitudinal grip, tyres should generally have a near 0° belt. On the other hand, optimum lateral grip may be achieved with an approximate 30-33° belt angle. This mostly applies to radial tyres, as the structure of the carcass can influence this, but the general principal remains valid for belted tyres or even raw bias-ply tyres. As tyres are rarely designed for either application in isolation, typical belt angles operate in the 15°-27° range.

With all this in mind, I am constructing the Brabham BT44B tyres with a 4-ply bias-ply design. Using Nylon cord, and a crown belt angle in the region of 25-26°, about the lowest you’ll see with a bias-ply tyre.

Required Data

Mass

Why this is important, I hope is obvious enough. In detail however, it will help with a few things than is intuitive. It’s necessary in helping calculate the overall unsprung mass of the vehicle. Furthermore, knowing this will help determine certain tyre properties. In the case of the BT44B, despite their enormous stature, the rear tyre is only (approximately) 12kg, while the front tyres were about 5.3kg. Bias-ply tyres tend to be somewhat lighter than radials, this is mainly due to the lack of a heavy steel belt. However, as Kevlar belted tyres become available, negated much of this difference. Finally, knowing the mass of the tyre can also help us decide on how thick or dense the actual rubber materials might be. Slick racing tyres also have a typical tread thickness of 3-4.5mm (that’s the outer layer of rubber in the crown area). As we fill in as many known quantities as possible, we afford ourselves a better chance of bettering estimates of quantities for which we are unable to obtain data for.

Cross Sectional Geometry

The best is a diagram, a plot, CAD or scan of the tyre shape. This may or may not be difficult to come across. Failing that, at the minimum you’ll want a complete listing of overall dimensions (section width, radius, rim width and rim diameter, etc), along with high resolution photographs. A technique that you may want to employ is photo-overlaying. This can be done by trying to replicate the tyre state as much as possible, in tTool utilising the quasi-static analysis tool and comparing the results with photographs. Such as seen below:

An overlay of an rF2 physical tyre over a real photo.

For example, a static photo would be great, but perhaps if you know the corner, you can approximate speeds and temperatures and pressures too, along with any external forces applied (as in vertical, longitudinal or lateral forces). You may even base those estimates on telemetry you created with a TBC model or pre-existing TGM tyres. For the cynical out there, you can consider doing this even if you have been provided with a cross-sectional tyre profile, as verification.

Another overlay of an rF2 physical tyre over a real photo.

To do this, you basically find an appropriate photo (long range high-zoom photos are best, to minimize perspective), and try to duplicate the camera positioning as much as possible within tTool. This won’t be easy, and will take some iterations. If your geometry is off, it’ll also make the process that much harder. Doing so requires some patience and a lot of alt-tabbing between rF2 and an image software. When you’re happy that you’ve matched the position and FOV, so much as possible, you can grab a screenshot with F12. The camera manipulation keys in tTool are the num-pad keys while holding modifier keys Ctrl & Shift as needed. At this point you’ll probably want to create a new layer in the real life photo’ and make that layer semi-transparent, I generally use about 50% opacity. This may help you to make fine geometry adjustments to your tyres.

Construction Materials and Properties.

At the minimum you’ll need to know the construction type (that is radial, bias-ply, or belted-bias). If you have access to the tyre, but you can’t dissect it, without tearing a tyre apart, you can still measure the thickness with a long reach caliper. Ideally you’ll want to do so across as many points as possible, as well as using the depth scale to measure the tread depth as well (if you weren’t able to come by this data). The key parts will be the thickness of the tyre at the bead, the minimum thickness at the sidewall, and the overall tyre thickness at the middle of the crown (the equatorial center of the tyre). As a ballpark, these figures can range from approximately 12-17mm, 3.6-7mm, and 7.8-22mm respectively. The large variance in the crown thickness concerns road tyres or wet tyres which have a deep tread designed to disperse significant amounts of water. Whereas a bias-ply slick will have the thinnest equator / crown center of all tyre types. The tread depth (or thickness) refers to the thickness of the outer layer of rubber. Tread rubber is the only part of the tyre for which adhesive grip is a high priority. Whereas the rubber below will be a ply casing rubber, designed to bond the tread to the tyre casing or belt or cap-ply. Generally, this layer can have a poor abrasion resistance. The tread depth may be slightly thicker than wear indicators or tread pattern imply.

What if you have a tyre to dissect? Well, if you’re so lucky, you’d do best to start with as many external measurements as possible, before doing any damage to the tyre. This includes vertical deflection tests with 0 pressure and with pressure, if possible. Doing so would give you a very good idea of how strong the carcass is. The tests can then be replicated in tTool, once you have a basic implementation ready. This will help you to know if you’re on the right track. A magnet (preferably a powerful one, such as neodymium) can also help determine if the belts and tyre beads are steel. Certain tyres also use steel chafer plies, as is common in open wheeler tyres. This is common as they traditionally possess tall sidewalls, requiring some additional rigidity. Short of using an x-ray machine, further measurements generally will require literally pulling plies apart, measuring the thickness of individual plies and measuring ply angles.

Basic implementation

This is too broad and complex a topic to cover in a single blog entry. For now we’ll stick with some basics.

TGM and tTool

These have been defined in our old .TGM quickstart guide. We’ll partially cover it again, by defining what the TGM is. Essentially, this is is our Tyre Model. It is a brush model, encompassing a rigid ring model. It is our representation of what tyres behave like, and how to model them into a real-time simulation engine. tTool, is our tyre tool. It is used to generate stiffness data from our tyre properties (geometry and materials), into lookup tables. Which are then quick enough to be run in real-time. The full complex model, the Quasi-static model is something in the order of 2 million times slower to run than the real-time lookup table. The accuracy also tends to be within around 97% in the worst cases (on flat ground) and you can improve that by running more steps. Some people seem to be of the opinion that lookup tables themselves are somehow inferior, but every tyre model in the world compasses some elements of a lookup table, because no tyre model can possibly simulate things at an atomic level. Even then, you would still be implanting some human derived numerical values from somewhere. Until computers reach speeds an order of magnitude higher than we have now, no such models are feasible.

So how do we get something into tTool, then?

We need to define the overall size and shape of the tyre first. Then we need to give the tyre some basic properties. Finally, we need to measure the results and try get something that correlates well. The latter part will be covered in a future blog entry. The method that we’ll demonstrate all starts with a new spreadsheet. It’s called TGM Gen V0.29, and this is the first public release.

Shape

The first thing to do is define a general shape. This is done on the “Geo” page, in cells B8 and ending at cell D40. Asymmetric tyres are possible, by entering custom values in B41 to D72. The window on the right represents the tyre cross sectional view. The X,Y co-ordinates define the width and radius relative to the wheel center, while the 3rd value is the thickness of the material. Which directly defines the Inner X & Y values in columns E & F. Though the inner co-ordinates are also manipulable, meaning the thickness values could be unnecessary if you choose to use your own method. There is also a quick ‘size adjuster’ available at cells S4-T6. This is rather crude, and you will inevitably have to make small corrections to your tyre shape. The overall dimensions provided by manufacturers are also usually representative of an ‘inflated’ tyre. tTool requires a tyre shape taken without any inflation pressure. For a bias-ply tyre, this means the radius will grow a few millimeters, generally 3-7mm. Interestingly, for tyres with an aspect ratio far lower than 100, the tyre will also narrow as the tread-face pulls out. So you may need to factor this into your base shape. This is because the sidewalls are already curved and the carcass itself is quite firm, and resistant to growing. For a radial tyre, the radius growth is likely only in the order of 1-2mm. In contrast to bias-ply construction, the width actually increases, as the (usually steel) belt makes the tread significantly more resistant to growth.

The Brabham’s rear tyres profile in the spreadsheet. On the right is the visual representation, the text beneath is of low importance and thus partially covered by the diagram.

Construction

The next part is the tyre construction itself. Broadly speaking, this covers the materials, angles, and thicknesses. This is certainly one of the most difficult areas, and will also be very difficult to access data regarding. If you happen to be doing bias-ply tyres, they’re simpler. Likewise, road tyres at least list some of the construction materials used on the sidewall. Certain design traits can also inferred from what it written on the sidewall. Let’s look at an example, “Sidewall: 1 Rayon, Tread: 1 Rayon, 2 Steel, 1 Nylon”. The “Tread” materials are those found in the middle of the tread or center of the tyre crown. “Sidewall” materials are those found half-way up the sidewall. Meaning that it won’t include chafer plies or turn-up plies (except in rare cases where the turn-up plies extend far). For the record, turn-up plies are simply the ends of the casing that wrap around the bead for added strength. We know that because there is only 1 “Rayon” layer, that particular tyre will have a 90 degree ply angle, because it is listed in both the sidewall and tread. A tyre also has to behave roughly symmetrically, with some slight exceptions. If there were 2 Rayon plies, they could be at non-90 degree angles, by opposing the angles they would counter act any thrust. Generally twin ply carcasses are placed at equal opposing angles. I have seen tyres with 3 plies in the sidewall, this is where things become more confusing. It’s possibly they need 3x 90 degree plies for stability. But it’s more probable that one is 90 degrees and the others are opposing. It’s also possible one is a chafer that reaches quite high into the sidewall. So, you may need to get more creative. In the spreadsheet, construction details are entered from cells Geo.C90 and onward. Nylon tyre cords (thread, strings, rope, or whatever you want to call them) are among the most common in racing tyres. They are commonly available in anything from about 0.4mm to 0.8mm diameter for tyre cords. That doesn’t mean they can’t be thicker, or thinner, though. I chose to go with 0.69mm diameter cords for now. Given they are bias-ply tyres, the construction has to be strong enough to resist the tyre folding in. The spacing values should be roughly 30-150% greater than the diameters of the fibers. In reality, this is necessary to prevent fatigue resulting from cords rubbing. Steel cords will normally have a greater spacing than fabric cords. In the case of nylon cords, typical spacing are around the 0.8-1.5mm range. The Brabham tyres were set to 1.05mm, giving a clearance between strands of 1.05-0.69=0.36mm.

“TGM Gen V0.29” basic construction details.

Further construction details are edited on sheet “TGM”. This covers most of the important ply construction materials. It also allows you to specify the reign or span of plies. It also lists the test conditions that tTool uses when generating lookup tables. These are entered from C9 to C29. As the tyres are still an early in development, it’s not necessary to specify more than 2 gauge pressure values, 2 temperatures, and 2 rotation speeds. Flaws in the tyres are likely to show up without the need for more extensive and detailed tests, and this speeds up the process. In the future, when you are satisfied with the overall tyre characteristics, building a larger, more complete lookup table may bring about some small benefits. For this case, that will occur when the Brabham is close to final, probably next week. Construction materials are listed in TGM.C35+. It is difficult to explain what everything does, so be sure to read the comments provided in the spreadsheet. If you have done all these steps, you should be able to begin generating a basic .tgm file within tTool. However, this post is getting quite lengthy and I will elaborate further on the process next time around.

To repeat, be sure to read the cell comments throughout the spreadsheet, as *most* of them have somewhat detailed descriptions. However, if you feel the spreadsheet is lacking in that department, let us know by making your own comments below. It may make the difference for future versions. Likewise, agree, disagree, or just found something interesting about anything I said? Got some additional reading or suggested books for people learning? Feel free to post some comments!

This will be the last blog entry, before we finally start covering tyres. This time we’re going to cover the latest steering system. Add force and torque distributions afforded by UltraChassis. We’ll also format the brake pressure to match our other cars and add a couple other little bits.

Steering System

Fig.1, An example of the real life steering system, in action (Image Source: Motor–Sport™).

What exactly does the new steering system change? It’s essentially another, more powerful way to define the steering properties.

Inner geometry freedom

The steering system allows complete freedom in what the inner steering linkages do as you apply lock. This opens up the possibility of non-linear steer ratios for cars that have them. The C6.R GT2 is one such example of a vehicle with non-linear steering. It also allows for more uncommon steering geometries, such as those employed in go-karts, which rotate around a point and move around 3 separate dimensions. Typical rack and pinion systems generally only move laterally, so for the majority of cars this is not going to make an Earth shattering difference.

This is all done through SteeringInnerTable entries, which have the syntax as follows:

Each entry between “()” brackets are the X,Y,Z co-ordinates (relative to the relevant sub-body), of the inner steering joints. : denotes the next step in the chain, which alternates from left to right wheels. How many entries you have dictates how many steering points you have. You need at least 4 bracketed entries (4×3=12 total numbers). The first 2 will always be at maximum left lock. The final 2 entries will represent the inner locations of the [Constraint]s, “FL_STEERING” & “FR_STEERING” at maximum right steering lock @ LocalOffsetA. To set these properly, you need to know or at least estimate the maximum steering rack displacement. The constraints central location can be obtained from the ultrachassis.ini file, if you use the spreadsheet, these are done automatically if you supply basic information.

The steering shaft position, as it relates to the steering rack, is now split into 2 parts and adjustable. Left obviously forms the base for the left wheel, and right for the right wheel. Most cars only have 1 steering shaft, so they should generally have same values:

There is also a steering shaft axis variable, which is essentially the inclination of the steering shaft into the steering rack.

SteeringShaftAxis=(<AxisX>,<AxisY>,<AxisZ>)

You can manipulate the steering through special overrides in the .HDV.

The custom steering can also be used in special instructions, in case you need to change the inner geometry as well. The syntax is almost the same as when you put it in the HDV [CONTROLS] section, except you do NOT reuse SteeringInnerTable to add more entries. Instead you can concatenate with the backslash-plus (i.e. \+) combination. In other words, the above HDV changes put into a special instruction could look like:

Slightly more accurate forces at the wheel

The old steering system had a slight simplification to it. The new system is not going to revolutionize your vehicle, but the forces going through the wheel are more accurate. The difference is probably only in the realm of 1-2% for most cars. In the end, the steering forces are a direct result of the suspension geometry, tyre properties and forces acting upon them. They are a direct link to the physics.

Force & Torque Distributions

To determine measurements, simply count the pixels of a known measurement. I used the wheelbase, in this instance. In this diagram, I’ve overlaid various points of interest, using the parameters of the car. The first thing you might note, the front wing aero center is actually outside of any physical dimension of the car. This was not an error of the original author (remember from my first blog, I did not create the original vehicle). Rather it’s a mathematical trick to enable a more accurate aero center of pressure, or downforce balance, shift due to pitch changes. The rest shouldn’t look too strange. Aerodynamics is beyond today’s blog, but I will come back to it, at some point in the future.

The first “ForceDistrib” is that of the fuel tank. You may remember that the BT44’s one is rather complex, ‘divided’ into 3 parts surrounding the driver. I’ve done my best to outline approximately where they actually are below:

Fig.3, Approximation of fuel tank layout.

Using a paint program, the magic wand selection tool displays the ‘pixel area’. The side tanks give about 96,977 square pixels, while the mid tank is 45,249 sq pixels.
Multiplied by the vertical height of 160 pixels, that gives us 96977*160+45249*160=22756160 cubic pixels. The conversion for the image is ~1.9975 millimeters per pixel. The eagle eyed among you might have noticed that I only included one ‘side tank’ in the equation. Why? Because these tanks are actually triangular shaped (when viewed from the front/rear), therefore they basically take up half the volume of a cuboid, so if you use the full height, you only need to include one in your calculation. Of course Liters as a unit, is defined as decimeters cubed, as in a cube of 10cm length.

So the drawing results in a volume of about:

(96977*160+45249*160)*(1.9975/100)^3 = 181.37 Litres, pretty damn close to the real things’ claimed 186L. The ‘100’ number is really just a conversion from millimeters to decimeters. According to these measurements, the tank is also about 1.4m long. However, when you try to take a weighted average, due to the unusual shape, you may assume something like 1.1m. This is done to reduce the twisting torques on the individual sub-bodies. Because we’re splitting them into 2 sub-bodies, you need to use half the length of this as the basis (when you divide a uniform object in 2, their CG’s are spaced at 1/2 the length of the original object). We’re effectively dividing the fuel into 2 parts, the CG of each is then offset from the original CG. Because the fuel tank is mostly ahead of the CG, I will go with about 55% on the front sub-body. 1.1*0.5*(1-0.55) gives us a forward offset of 24.75cm. For the rear, with a split of 45%, it would be 1.1*0.5*(1-0.45), 30.25cm aft.

[DIFFUSER]

Technically, this car did not have a diffuser, nor was ground effects an exploited aerodynamic necessity in racing. However, just because they did not understand it’s potential, does not mean it didn’t exist. The car had a flat bottom, and it ran with some rake. Inevitably, it was going to produce *some* ground effect. The car was also considered a full ground effect precursor. We’re not talking huge numbers here, obviously, but we should think about where to place the sub-body offsets. In the prior diagram, I had also taken a ‘best guess’ kind of approach for the diffuser. Keeping in mind that some height sensitivity had already been attributed with the front wing. To simplify this, we’re going to assume that the diffuser pressure distribution is even. The length I used is 1.928m, halved, gives us a gap between sub-bodies of 0.964m. If I distribute 60% of the force to the front, this requires a foreward offset of 0.964*(1-0.6)=0.3856m.

[DRIVELINE]

The engine, clutch, gearbox and differential torques can now also be apportioned between the bodies. Being mid-engine, and a structural component, it will overwhelmingly have a direct influence on the rear of the car. It’s hard to know what to use without doing some kind of structural analysis, but using it’s position in the wheelbase is probably a good starting point. The numbers I came up with are as follows:

Some last little HDV bits

Pushrod connections

Again, the enhancement here is aimed at flexibility and accuracy. In reality, the geometry is that of a pull-rod layout on the front end. And we can’t fully simulate this. By placing the pushrods as upright as possible, around on the kingpin axis, we ensure minimal change in motion ratios or wheel rates.

1: refers to force distributed to that sub-body. FL_SPINDLE is the sub-body to which that force is applied. (0.111927,-0.11675,-0.01) is the position offset, relative to the center of that sub-body. Put another way the syntax is:

Again, the new parameters allows you to specify which rigid body the ‘pushrods’ attach to. While it previously forced one end to the spindle and the other to the body.

[CONTROLS]

For consistency with other vehicles, the “BRAKE PRESSURE” caption will be overridden by “MAX PEDAL FORCE”. Essentially, it is displayed in this manner to give the user an idea of how much brake pedal force is needed for that particular vehicle. This is useful if you have an adjustable load cell. The new values are equivalent to the old behavior for this car.

A short post again, covering the recently released Brabham BT44B (V0.21). First off, apologies for not syncing my blog post with the release. There were not a monumental number of changes, but the car was converted from the old rF1 style .pm (Physical Model) file to the latest UltraChassis file. This has a few advantages, firstly, the degrees of freedom are increased. Secondly, the steering response is slightly improved. Thirdly, some compliance’s can be included. Fourthly, the solver appears to be slightly more accurate. Fifthly, it allows special overrides to influence the mass, inertia, or re-positioning of rigid bodies or constraints. Finally, it allows chassis flex along with other constructions which are not possible with the .pm model. The final enhancement is the most significant change in relation to the BT44.

1. So what are degrees of freedom anyway?

Essentially, it means that each rigid body is able to move independently of another, have their position and orientation independently influence the vehicle dynamics. This results in an overall more accurate, more detailed behavior including gyroscopic effects. For the record, rFactor 1 has 15 degrees of freedom. This can be broken down as:
2 per wheel (height and pitch), 6 for the main body, and 1 for the engine (roll).
rFactor 2 on the other hand, had split the ‘wheel’ into 2 parts since it’s inception (as a result of the TGM tyre model). Which has split the wheel into a sort of tyre ring and wheel. Not only that, but each tyre ring had a full 6 degrees of freedom. This initially made rF2 a:
4*6+15=39 degrees of freedom model.
When UltraChassis was implemented this further improved the system by giving EACH sub-body the full 6-DOF’s. The main body of the vehicle is also typically now calculated in 2 parts. The result? rF2 now enjoys a 85 degrees of freedom system, consisting of:
4*6 (4 Tyre Rings @ 6 DOF) + 4*6 (4 Rims @ 6 DOF) + 4*6 (4 Spindles @ 6 DOF) + 2*6 (2 Sub-Bodies @ 6DOF) + 1 (Engine) = 85 degrees of freedom with a typical vehicle setup in rF2.
Furthermore, there are actually no restrictions on what you can do with UltraChassis, if you feel like adding more, you can. However, be warned that doing so will inevitably increase CPU usage. To compound this further, there is such a thing as diminishing returns. Therefore, we don’t typically recommend exceeding this, unless you absolutely have to. If you’re building a private project, to run on a very quick machine, then do feel free to go nuts.

2. Steering response

The improvement here, which is due to the need to incorporate some interpolation to the steering between input time steps. Simply put, UltraChassis does it slightly better.

3. Compliance’s

Compliance’s are basically flex / play in the suspension or other systems. Although a simplified compliance system, it does allow a degree of flexibility in the suspension components themselves. It would be possible to further enhance this, by adding more DOF’s, but this is impractical for a consumer based real-time simulation software.

4. Solver Accuracy

As with all complicated computations, there are multiple ways of doing things. Our coder had been very careful to make sure the solver accuracy was better than the old one. Therefore, the positional and reactive behaviors are slightly better than with the previous model.

5. Special Overrides

This is a great enhancement to the flexibility of setup parameters. You can adjust rim mass or suspension arm lengths, or pickup points. For example, you are able to change the geometry on the Formula Renault 3.5 as a result of this addition.

6. Chassis Flex, and Design Freedom

Yup, the biggest one, and quite significant in the case of the BT44B Brabham. I think it’s no secret that, as a generality, older cars were not as stiff as their modern counterparts. The BT44 is no exception, as we’ll see later on.

Implementation

So what was my process for implementing UltraChassis this time around? I feel the ‘auto-generate’ method, was already covered somewhat well on rFactor.net’s dev corner, back in 2013 (my how time flies!). It is still valid, and available to read here. However, this time I will use my spreadsheet to create the file.

Step 1: Copy/import the data.

If you’re working from an existing car, such as in this instance, you’ll need to “extract” the existing data from the .pm file, and import it into the “rF2PC” spreadsheet. Again, rather than typing each out manually (which can also result in errors), I’m going to special paste the entire .pm file into a .ODS spreadsheet. By selecting separated by “(,)” the important values are uniquely placed. I outlined this in a previous blog entry (rF2 engine model, and gear ratio restrictions). As a reminder, you can press Shift+Ctrl+V to access the special paste.

Step 2: Translate that data.

So we have the data in separate cells now. But the ordering and positioning is not correct for my spreadsheet. To translate it, I simply whipped up some cell references.

Basically, I prefer to find some kind of semi-automated method to do anything. So rather than copy each parameter individually, I’d rather set up a quick spreadsheet, such that, if you happen to have to do it again in the future, it will save time longer term. Here’s the quick tool I used to do it. PM Import V0.1.zip. It is absolutely nothing special, and a quick job, it also won’t work if the .pm file is formatted differently. But the time to create a parser for this purpose probably wouldn’t be justified either.

Step 3: Correct masses, inertias, and rotate pivots.

The unsprung mass in this case has to be matched, along with the inertia’s. Until I have some closer to final tyres, there isn’t too much point in trying to improve the existing calculations, or even go in my own direction with them. So I will try to mimic the original closely. Essentially the this step involves pasting the suspension co-ordinates into Susp.C6, (and C36 for the rear). Afterward, I have to go to Susp.D2 and Susp.D32. By entering the inverse of the default cambers (which are -1.5 and -1.0 front and rear respectively, thus inversed are +1.5 & +1.0). I correct the correction that was made to the suspension pivot points in the original vehicle. This was done because rFactor rotates the outer pivots when you change camber angles. So in order to get the original intended geometry, I have to account for this. The co-ordinates then have to be copied again from the bold text cells starting from AK8, as seen here:

Most authors did not actually account for this, and so for the majority this is an unnecessary step, fortunately! The end result looks something like:

The rotational masses and inertias can be corrected in sheet Susp2. You can add or subtract mass/inertia as necessary under the Front Left and Rear Left headings. Of course, the ideal method is to update ‘Rim’, ‘Brakes’, ‘Tyres’ and other spreadsheets with accurate data, which then produces more accurate automated results, but that’s for another day.

Step 4: Estimate the chassis torsional rigidity.

This is not typically something easy to calculate. Even then there can be substantial deviation to real life no matter how hard you try. One resource that I will be using is a thread on the F1 Technical forums. The figure I’m most interested in, which should be representative of this 1975 Brabham would be:

- First aluminum monocoques - 4500-6000lb/ft - 6102 - 8136 Nm

We also know that the Gordon Murray designed car was very light, and one of the smallest / narrowest chassis of the time. Indicating a rigidity probably in the lower range of these numbers. So we’ll settle on about 6200Nm/° for now. Which is ~355,000 Nm/radian for rF2 units. We’ll also need to set the damping, I’ll set that to 1,300 which gives us a critical damping coefficient of 0.15. This should be in the ballpark, given that the primarily metal chassis won’t provide too much damping. As for the other stiffness’s (bending, etc), that particular data is even harder to come by. Part of the rationale for that is because chassis’ tend to be stiffer in those directions. As a result, they’re of less interest to engineers. They are also not quite as important in overall vehicle behavior. Still, they’re obviously not infinitely stiff, and we do simulate these attributes, so they should be as properly configured as possible. What I can say from previous research, is that the stiffness when expressed as a frequency is generally higher in bending stiffness. Simply put, frequencies are the rate at which a body oscillates, and is derived from the stiffness of the object and relevant inertia. The formula is quite simple given as, Squareroot(Inertia/Stiffness)/(2*PI()) giving us a result in Hertz. Using 6200Nm/° the torsional rigidity of the car is about 13Hz. We’ll go for about 22Hz for Pitch/Pitch frequency (sometimes called the bending stiffness) and 28Hz for Yaw/Yaw frequency. With all that said and done, the Susp2 sheet looks like:

Step 5: Export ultrachassis.

So now I’m copying over the file, and pasting it into the new “BT44_Chassis.ini”. This is simply done by pressing the “Copy UltraChassis” button on the Susp spreadsheet, which copies out the data. All you have to do is paste this into the appropriate file. Finally, we have to reference the new file, in the HDV file.

Previously we had:

[SUSPENSION]
PhysicalModelFile=BT44.pm

This entire blog post is really about making the PhysicalModelFile, obsolete. In its place, we’ll need to add an UltraChassis= reference. So that it looks like:

[SUSPENSION]
UltraChassis=bt44_Chassis.ini

The latest BT44B is as always available on steam, be sure to subscribe if you haven’t as we’ll be asking for specific feedback soon!