Yearly Archives: 2016

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:

Tyre component diagram. (Ref: Page 6, Goodyear Radial Truck Tire And Retread Service Manual)

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!

Steering System

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

Inner geometry freedom

SteeringInnerTable=(<FL_STEERING_X>,<FL_STEERING_Y>,<FL_STEERING_Z>):(<FR_STEERING_X>,<FR_STEERING_Y>,<FR_STEEERING_Z>)

SteeringShaftBaseLeft=(<LeftShaft_X>,<LeftShaft_Y>,<LeftShaft_Z>) // Location of steering shaft relative to steering arm
SteeringShaftBaseRight=(<RightShaft_X>,<RightShaft_Y>,<RightShaft_Z>)

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

SteerLockSpecial(0,,,"SteeringShaftBaseLeft=(0.0,-0.07571448,-0.616415")
SteerLockSpecial(0,,,"SteeringShaftBaseRight=(0.0,-0.07571448,-0.616415)")
SteerLockSpecial(0,,,"SteeringShaftAxis=(0.0,0.0,1.0)")
SteerLockSpecial(0,,,"SteeringInnerTable=(0.464472,-0.065,-0.616415045):(-0.301488,-0.065,-0.616415)")
SteerLockSpecial(0,,,\+"(0.38298,
-0.065,-0.616415):(-0.38298, -0.065,-0.616415045)")
SteerLockSpecial(0,,,\+"(0.3014879,-0.065,-0.616415045):(-0.464472,-0.065,-0.616415)")

Slightly more accurate forces at the wheel

NominalMaxSteeringTorque=7.3
TurnsLocktoLock=1.8
SteerLockRange=( 10 , 1 , 14 )
SteerLockSetting=13

NominalMaxSteeringTorque=7.3
TurnsLockToLock=1.8
SteeringShaftBaseLeft=(0,0.265912,-0.378279)
SteeringShaftBaseRight=(0,0.265912,-0.378279)
SteeringShaftAxis=(0.17365,0,0.98481)
SteeringInnerTable=(0.32605,0.26,-0.377236):(-0.39395,0.26,-0.377236)
SteeringInnerTable=(0.39395,0.26,-0.377236):(-0.32605,0.26,-0.377236)
SteerLockCaption="WHEEL RANGE (LOCK)"
SteerLockRange=(22.192,0,9)
SteerLockSpecial=(0,"240 ","(8.2) deg","TurnsLockToLock=0.666667;SteeringFraction=0.37037")
SteerLockSpecial=(1,"270 ","(9.2) deg","TurnsLockToLock=0.75;SteeringFraction=0.416667")
SteerLockSpecial=(2,"310 ","(11) deg","TurnsLockToLock=0.861111;SteeringFraction=0.478395")
SteerLockSpecial=(3,"360 ","(12) deg","TurnsLockToLock=1;SteeringFraction=0.555556")
SteerLockSpecial=(4,"380 ","(13) deg","TurnsLockToLock=1.055556;SteeringFraction=0.58642")
SteerLockSpecial=(5,"450 ","(15) deg","TurnsLockToLock=1.25;SteeringFraction=0.694444")
SteerLockSpecial=(6,"540 ","(18) deg","TurnsLockToLock=1.5;SteeringFraction=0.833333")
SteerLockSpecial=(7,"630 ","(22) deg","TurnsLockToLock=1.75;SteeringFraction=0.972222")
SteerLockSpecial=(8,"648 ","(22) deg","TurnsLockToLock=1.8;SteeringFraction=1")
SteerLockSetting=8

Force & Torque Distributions

Fig.2, Scribbled on BT44 ‘blueprints’ Original Source: DrawingDatabase.com

Fig.3, Approximation of fuel tank layout.

FuelTankForceDistrib=(0.55:front_subbody:(0.0,0.0,-0.2475), 0.45:rear_subbody:(0.0,0.0,0.3025))

[FRONTWING]
FWForceDistrib=(1.0:front_subbody)

[REARWING]
RWForceDistrib=(1.0:rear_subbody)

[LEFTFENDER]
FenderForceDistrib=(1.0:Front_subbody)

[RIGHTFENDER]
FenderForceDistrib=(1.0:Rear_subbody)

BodyAeroForceDistrib=(0.55:front_subbody:(0,0,-0.45),0.45:rear_subbody:(0,0,0.55))

[DIFFUSER]

DiffuserForceDistrib=(0.6:front_subbody:(0,0,-0.3856),0.4:rear_subbody:(0,0,0.5784))

[DRIVELINE]

EngineTorqueDistrib=(0.182:front_subbody,0.818:rear_subbody)
ClutchTorqueDistrib=(0.07:front_subbody,0.93:rear_subbody)
GearboxTorqueDistrib=(1.0:rear_subbody)
DifferentialTorqueDistrib=(1.0:rear_subbody)

Some last little HDV bits

Pushrod connections

[FRONTLEFT]

PushrodSpindle=(0.006497906,-0.375634207131652,-0.0322502269795518)
PushrodBody=(0.006497906,0.42436579286835,-0.0322502269795518)

PushrodOutboard=(1:FL_SPINDLE:(0.111927,-0.11675,-0.01))
PushrodInboard=(1:Front_Subbody:(0.665,0.47,-0.4872))

<ForceDistribution>:<Body>:(<OffsetX>,<OffsetY>,<OffsetZ>)

[REARLEFT]

PushrodSpindle=(-0.01,-0.2,0)
PushrodBody=(-0.01,0.3,0)

PushrodOutboard=(1:RL_SPINDLE:(-0.002793,-0.158054,-0.1))
PushrodInboard=(1:Rear_Subbody:(0.55,0.485,0.2104))

[CONTROLS]

BrakePressureCaption="MAX PEDAL FORCE"
BrakePressureRange=(0.555556,0.011111,41)
BrakePressureSpecial=(0,50," kgf (56%)",)
BrakePressureSpecial=(1,51," kgf (57%)",)
BrakePressureSpecial=(2,52," kgf (58%)",)
BrakePressureSpecial=(3,53," kgf (59%)",)
BrakePressureSpecial=(4,54," kgf (60%)",)
BrakePressureSpecial=(5,55," kgf (61%)",)
BrakePressureSpecial=(6,56," kgf (62%)",)
BrakePressureSpecial=(7,57," kgf (63%)",)
BrakePressureSpecial=(8,58," kgf (64%)",)
BrakePressureSpecial=(9,59," kgf (66%)",)
BrakePressureSpecial=(10,60," kgf (67%)",)
BrakePressureSpecial=(11,61," kgf (68%)",)
BrakePressureSpecial=(12,62," kgf (69%)",)
BrakePressureSpecial=(13,63," kgf (70%)",)
BrakePressureSpecial=(14,64," kgf (71%)",)
BrakePressureSpecial=(15,65," kgf (72%)",)
BrakePressureSpecial=(16,66," kgf (73%)",)
BrakePressureSpecial=(17,67," kgf (74%)",)
BrakePressureSpecial=(18,68," kgf (76%)",)
BrakePressureSpecial=(19,69," kgf (77%)",)
BrakePressureSpecial=(20,70," kgf (78%)",)
BrakePressureSpecial=(21,71," kgf (79%)",)
BrakePressureSpecial=(22,72," kgf (80%)",)
BrakePressureSpecial=(23,73," kgf (81%)",)
BrakePressureSpecial=(24,74," kgf (82%)",)
BrakePressureSpecial=(25,75," kgf (83%)",)
BrakePressureSpecial=(26,76," kgf (84%)",)
BrakePressureSpecial=(27,77," kgf (86%)",)
BrakePressureSpecial=(28,78," kgf (87%)",)
BrakePressureSpecial=(29,79," kgf (88%)",)
BrakePressureSpecial=(30,80," kgf (89%)",)
BrakePressureSpecial=(31,81," kgf (90%)",)
BrakePressureSpecial=(32,82," kgf (91%)",)
BrakePressureSpecial=(33,83," kgf (92%)",)
BrakePressureSpecial=(34,84," kgf (93%)",)
BrakePressureSpecial=(35,85," kgf (94%)",)
BrakePressureSpecial=(36,86," kgf (96%)",)
BrakePressureSpecial=(37,87," kgf (97%)",)
BrakePressureSpecial=(38,88," kgf (98%)",)
BrakePressureSpecial=(39,89," kgf (99%)",)
BrakePressureSpecial=(40,90," kgf (100%)",)
BrakePressureSetting=31

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.

Ingredients:

• LibreOffice
• rF2 Physics Calculator 0.22 ODS
• Your old PhysicalModel (.pm) file (optional)
• A cup of coffee (optional)

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!

A lot of talk has been generated recently about the new build, and the apparent physics changes. I’m going to try and keep this brief. Build 1098 should not influence any physical attributes unless that vehicle contains the new [Realtime] parameters in the .TGM file. I had a blind test when diffusive adhesion was implemented, and found no discernible difference, furthermore, tests made within +ttool gave identical results (within the tolerance of error). For those that don’t know, +ttool is basically a bench test for the tyres.

What are they, and what do they do?

As I said, I’d like to keep this brief and will come back to them when I finally get around to my TGM pieces. Let’s just start with diffusive adhesion. Diffusive adhesion is basically a time lapse form of adhesion/bonding to the ground. The parameters required to unlock the code are as follows:

StaticDiffusiveAdhesion=(<halftime>,<pressure>,<curve>)
SlidingDiffusiveAdhesion=(<halftime>,<pressure>,<curve>)

The description for which, as given by our coder:

• <halftime>=Diffusive adhesion gains force on an asymptotic curve, so this defines the time at which we’ve achieved 50% of the maximum. You can make it effectively instant by using 0.0.
• <pressure>=The maximum adhesive force per unit area.
• <curve>=A value from 0.0-1.0 that says whether the maximum force is affected by the appropriate curve (StaticCurve or SlidingAdhesionCurve). 0.0=no effect, meaning it is always using the maximum force, 1.0=full effect, so maximum force only happens at optimum temperature (and sliding speed, in the case of sliding)

It will actually bond the tyre to the asphalt, requiring a slight upward force to detach it from the ground. This type of bonding is primarily why gravel or other debris stick to tyres after such an off-road excursion. High temperatures generally enhance this effect.

What about the “planar contact compliance”?

This replaced the old values of:

TemporaryBeltSpring
BaseSpringPerUnitArea, or the even older TemporaryBristleSpring

With:

SpringConditions=(<gauge_pressure>,<carcass_temperature>,<rotation_squared>)
  // conditions under which the base spring values were calculated
BeltSpringX=(<base>,<per_unit_pressure>,<per_unit_temperature>,<per_unit_rotation_squared>)
BeltSpringZ=(<base>,<per_unit_pressure>,<per_unit_temperature>,<per_unit_rotation_squared>)
TreadSpringXPerUnitArea=(<base>,<per_unit_pressure>,<per_unit_temperature>,<per_unit_rotation_square d>)
  // still per unit area, BTW
TreadSpringZPerUnitArea=(<base>,<per_unit_pressure>,<per_unit_temperature>,<per_unit_rotation_square d>)
  // still per unit area, BTW

The “old” variables you were only providing the <base>. So, essentially you can get it to behave the same, by copying the old values. <TemporaryBeltSpring1> can be used into <BeltSpringX1>, <TemporaryBeltSpring2>, can be used in position <BeltSpringZ1>, assuming the remaining values are set to 0.0, the tyres will behave the same as previously.

For BaseSpringPerUnitArea, <BaseSpringPerUnitArea1> = <TreadSpringXPerUnitArea1> & <BaseSpringPerUnitArea3> = <TreadSpringZPerUnitArea1>. However, I will tease a bit now by saying that I have a spreadsheet that will feeds data into +ttool to help you determine reasonable values to use here. I will not be releasing it today, however, so you’ll have to stay tuned to this blog .

I will end on a bombshell, by revealing that the “planar contact compliance” was actually first available in B1084. Information concerning the new feature was withheld because we were not quite sure if we wanted to go with this method. In the end this appeared to produce the best correlation vs performance. This feature has only been used on the 3PA Watson Roadster so far. It allows greater accuracy of the lateral and longitudinal bristle compliance with changes in temperature, rotation speed, and tyre pressures.

So far we covered the most basic import of rF1 style physics into rF2, followed by most of the HDV and TBC parameter updates / improvements. Now, it’s time to tackle the improved internal combustion engine model.

However, to start off this entry, a little something I forgot the last time around. In the HDV, under the 4 sections, from [FRONTLEFT]-[REARRIGHT]. We have another variable to add.

SpringAux=(0,0.0) // Auxillary spring (<allowNegativeSpringForce>,<helperSpringRate>).
                  // Allow the normal spring to produce negative forces (0 to disable),
                  // optional helper spring which is "always on".

Though, this most likely will not have any noticeable effect on the BT44. Springs would formerly go negative if you had enough rebound travel (stretching the spring), which usually isn’t particularly accurate as not many cars have clamped or welded springs. However, most modern cars already have some preload (the rebound stop), as such for those, this doesn’t have significant influence over vehicle dynamics. Furthermore, the damper tends to “stop” the wheel travel extending beyond this point anyway. So under most conditions, the effect will be very minor. Nonetheless, it has now been incorporated. The parameter also allows helper springs, as the 2nd parameter, but those are irrelevant to the BT44, so we’ll ignore them.

The Engine.ini

So on to the juicy topic, the engine file. How is the engine model different? In short:

• The new model allows throttle map adjustments. This can be achieved through 2 methods (or a combination), volumetric efficiency and fuel-air mixture manipulation (the latter is more directly related to diesel engines).
• Allows fuel mixture adjustments and this can lead to better fuel consumption controls. This requires the latest build (B1098).
• Engine braking maps also have greater control / freedom.
• Allows turbocharged engines.
• In theory has support for air pressure / density changes, although the latter has not been utilised. It does mean that we’re able to simulate ram air through a more accurate pressure increase, though.

We won’t need everything for the Brabham, but I’ll outline how it works. To start with, I’m going to copy the torque curves from the engine.ini and “import” them into my spreadsheet. I’m using the “rF2 Physics Calculator V0.22” (rF2PC) spreadsheet is available at the rFactor.net’s dev corner. V0.22 should be available shortly, and has been updated to fix a few minor bugs. LibreOffice Calc allows a basic text import, which will do nicely for us, allowing us to paste the data without having to type it manually or copy every single line. After opening the Cosworth_DFV_1975.ini, copying all lines that start with “RPMTorque”, they can be ‘special pasted’ into a blank LibreOffice sheet. Simply press CTRL+SHIFT+V (shift activates the special paste) to paste into LibreOffice. This will bring up a prompt called text import. Select “Separated by” and select “Other”, entering manually “(,)” as in this screenshot below:

A special paste with “(,)” tells the software to treat these characters as separate tabs.

We just need to copy the last 2 columns of data and paste them into the ‘rF2PC’ spreadsheet. Simply go to the engine sheet, and paste into cell F4. This will replace some formula, but that’s OK in this case, where I believe the original engine braking torque values are at least somewhat accurate. Now we need to change the RPM step to match, “187.5”, the MaxTableRPM to “12000”. We also have to set the max RPM to 10600 (redline RPM) in order for the automatic calculations to work properly. Finally, we need to look at the idle values, which were formerly:

IdleRPMLogic=(1800,2200)

Clearly the intent was an idle of about 2,000RPM, which matches my knowledge of the Cosworth DFV. Though in-game testing shows the idle was 1966RPM. A quick search has revealed a great resource, and awesome read here. Which indicates an idle above 2,000RPM for the DFV.

Essentially, the purpose of all this is to replace the old values of:

RPMTorque=( 0 , -30 , -15.4844999313354 )

Which I will define here. RPMTorque1 defines the RPM. RPMTorque2, the braking torque (completely off the throttle). And RPMTorque3 is the torque at full throttle for this RPM. Values in-between RPM steps are smoothed by rF2 automatically.

The roughly equivalent replacement of which looks like (I will not be pasting the entire table here):

RPMBase=(0,-30,-30,0.0339,0.96)
VolumeFract=(0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)
MixtureFract=(0,0,0,0)

Ideally, for the first point in the data, the ‘peak torque should match the ‘brake torque’. Which is why it’s slightly different. Defining RPMBase=(V,W,X,Y,Z), where V is the RPM, W is the maximum engine brake torque, X is the maximum torque, Y is the idle throttle application (minimum throttle applied) Z is ‘pressure power’. Pressure power represents the power change in the engine vs air pressure changes. It represents a mathematical power of the current air pressure over the reference conditions (see a couple paragraphs below).

VolumeFract, is the volumetric efficiency per throttle step, up to 16 entries. The first and last entry are always minimum and maximum throttle. So in this case, each value represents an increment in throttle of 1/15 or ~6.7%. Essentially, it’s the amount of torque you get, as a fraction of the RPM base 3rd and 2nd values. If VolumeFract is 0.5 and the brake torque is -30 while the positive/peak torque 100 at that RPM, you’d end up with about (-30*(1-0.5)+100*0.5), 35Nm, of positive torque. With a VolumeFract value of 0.8 you’d have (-30*(1-0.8)+100*0.8) 74Nm of positive torque.

MixtureFract operates much the same as VolumeFract, but it uses the engine mixture to achieve torque adjustments. I will elaborate on those a bit further in.

At the top of the file we must have:

ReferenceConditions=(101325,1.225,0.073) // pressure (pascals), density (kg/m^3),
                                         // fuel/air mass ratio, the presence of
                                         // this line activates the new engine model.

These reference conditions activate the new engine code in rF2. Pressure is the ambient pressure of the specified RPM base values that you’ve defined. The same goes for density, which is the air density, and the fuel/air mass ratio. Most power curves are generated in maximum power mode, which usually entails a somewhat rich mixture with an air-fuel ratio of about 12.5-13.5:1. Let’s say 13:1, we can reverse this to a fuel-air ratio to 1:13, or 0.077 in rF2’s measure. Methanol or other blends can alter this optimum significantly. The optimum for fuel efficiency could be around 1:15.0-15.5.

With this all said and done, my spreadsheet looks something like:

More stuff to add to the engine:

FuelDensity=0.74
FuelAirMixtureTable=(0.0, 0.091)
FuelAirMixtureEffects=(0.0, 0.0)
FuelAirMixtureEffects=(0.1, 0.11)
FuelAirMixtureEffects=(0.2, 0.22)
FuelAirMixtureEffects=(0.3, 0.33)
FuelAirMixtureEffects=(0.4, 0.44)
FuelAirMixtureEffects=(0.5, 0.55)
FuelAirMixtureEffects=(0.6, 0.66)
FuelAirMixtureEffects=(0.7, 0.77)
FuelAirMixtureEffects=(0.8, 0.88)
FuelAirMixtureEffects=(0.89, 0.99)
FuelAirMixtureEffects=(0.98, 1.0)
FuelAirMixtureEffects=(1.0, 0.97)
FuelAirMixtureEffects=(0.97, 0.9)
FuelAirMixtureEffects=(0.85, 0.8)
FuelAirMixtureEffects=(0.65, 0.6)
FuelAirMixtureEffects=(0.4, 0.4)
FuelAirMixtureEffects=(0.1, 0.1)
FuelAirMixtureEffects=(0.0, 0.0)

What does it do? Well fuel density is the mass of fuel, per liter. In this case, 1 liter of fuel weighs in at 0.74kg.

FuelAirMixtureTable=(<>,<>) Start, and step size of fuel/air ratio (normalized relative to reference mixture) for following table;
FuelAirMixtureEffects=(<torque multiplier>,<exhaust gas temperature multiplier>)
Basically, at each step, this defines a torque multiplier for the torque output by the engine, and also the exhaust temperature. From rF2’s perspective 2nd value is really only relevant to turbocharged engines.

A new parameter, related to the above:

EngineMixtureRange=(1.0, 0.1, 1) // Engine fuel-air mixture shift from baseline.
                                 // Affects fuel consumption and torque / power,
                                 // essentially a multiplier of current
                                 // "MixtureFract" tables.
EngineMixtureSetting=0

This shifts the entire MixtureFract table as defined previously in the engine.ini. It is adjustable on-the-fly (in-car). I will not be using it at this stage for the BT44 as I don’t believe the driver had any real control over what the engine was doing. It would have been risky. Lower values basically lean out the fuel mixture, and higher values make it richer. 1.0 is the default (0.073 in this case) fuel-air mixture, a value of 0.9 would give a fuel-air mix of 0.9*0.073=0.062 (15.22:1 AFR).

As the idle throttle is now adjusted per RPM step (through RPMBase4 values), the following line is obsolete:

IdleThrottle=0.4

The following values enable launch control:

LaunchEfficiency=1
LaunchVariables=1

Altered to:

LaunchEfficiency=0
LaunchVariables=0

Simply because this car does not, have a launch control system.

Another new line:

RevLimitHardTime=0.0

Sets a time threshold for the redline ignition cut.

The following:

OptimumOilTemp=110

Is replaced by:

OilTemps=(0.2,110)

The 2nd value is the same, it basically sets the thermostat temperature, when the engine oil heat exceeds 110-10=100°C, the thermostat will open to cool the engine block with water heat transfer through the radiator. The first value is new, however, and is a fraction between the current ambient temperature, and the optimum engine temperature. Many engines are used with block heaters to maintain a safer temperature before going out on track.

EngineEmission=(0.00, 0.0,-0.0)
EngineSound=( 0.00, 0.0,-0.0)

These values are not obsolete, but were never correctly configured. They represent the X,Y,Z location, relative to the rear axle centerline at the reference plane (remember ISI units are X=lateral, Y=vertical, Z=longitudinal).

EngineEmission=(0.0, 0.2,-0.4)
EngineSound=( 0.0, 0.2,-0.0)

The engine was missing a few lines, regarding ram air that were available in rF1. Thus, the following lines were not in the previous file, but I will illustrate them regardless:

RamCenter=(0.0, 0.9, -1.2) // location of ram air intake
RamDraftEffect=3.0 // multiplier for effect that draft has on ram air velocity
RamEffects=(2.0e-5,2.0e-5,2.0e-5,2.0e-5) // torque % increase per m/s,
                                         // power % increase per m/s and RPM,
                                         // fuel increase per m/s,
                                         // engine wear increase per m/s

The new values are:

RamCenter=(0.0, 0.9,-1.2)
RamDraftMult=5.6
RamPressure=(0,4.0e-6)

RamCenter, is the X,Y,Z location for ram air effects.

RamDraftMult, is the draft air speed multiplier. Utilization of this parameter exaggerates the drafts’ air speed (see my previous blog, radiator draft mult), thus decreasing overall engine power for the car behind. This is significantly above 1 because, A) air from the car ahead can be rather turbulent. B) it has been warmed by the car ahead (less dense), and C) it’s safe to assume that some of the oxygen has been spent by the car ahead for combustion.

RamPressure, now, instead of a direct influence on torque / power, ram air now builds up air pressure at the intake. It also, more accurately, allows this change to occur with the square of speed, as opposed to the old method which only allowed for a linear control with speed. RamPressure1 represents the linear pressure increase with the speed (in m/s). RamPressure2 represents the exponential increase with air speed or increase in intake pressure with speed squared m/s². So at 180km/h (50m/s) we have an increase in pressure of 4e-6*50^2. Approximately 1% increase in air pressure.

The Gearbox

What’s new? We have the ability to restrict gear ratios to specified gear indexes (such as 1st gear, or 2nd gear). But first, I believe the old ratios were not particularly accurate. Trawling the internet, the Brabham BT44B had a standard gearbox of the time, a Hewland FG400. I came across a nice resource:

Originally Posted by http://hewlandclassic.com/assets/manuals/fg_400.pdf

Crown Wheel & Pinion 7:31
Crown Wheel & Pinion 9:31
Crown Wheel & Pinion 8:31
Crown Wheel & Pinion 10:31

Whereas, the original values were:

[FINAL_DRIVE]
bevel=(20,32) // 1.6
ratio=(9,31) // 3.4444
ratio=(9,30) // 3.3333
ratio=(10,31) // 3.1
ratio=(10,30) // 3

Thus we’ll update them to:

[FINAL_DRIVE]
bevel=(1,1) // 1
ratio=(7,31) // 4.429
ratio=(8,31) // 3.875
ratio=(9,31) // 3.444
ratio=(10,31) // 3.1

As this car does not appear to have a separate bevel gear as such. The final drive gears are already beveled and thus account for the axis change of the torque vector (the engine spins around the roll axis, while the wheels spin around the pitch axis). I could have also used a special entry “FinalDriveSpecial” to define these ratios, but in this case there are no drawbacks to using the older “GearFile” method. Some cars have both bevel and final drive ratios adjustable, would very well benefit from using FinalDriveSpecial overrides, as it would allow you to create all the possible ratio permutations.

Another rather useful resource, particularly for Hewland gear ratios is available here. Digging through this site, the FG gearboxes evidently use the FT gear ratios. We can use that to fill in the data in the GearFile, and will also enable us to enact restrictions on gear ratios. On this site, “Std” gears can be used from 3rd ratio onwards. “2nd” can only be used for 2nd gear. And Integral “1st” can only be utilized as a first gear ratio. I will incorporate all of these into the GearFile, rather than as special overrides, simply because the new method would involve redundant entries.

In the HDV, under the [DRIVELINE] section what we end up with is:

Gear1Range=(0,0,6)
Gear1Special=(0,,,"13,46")
Gear1Special=(1,,,"12,38")
Gear1Special=(2,,,"12,35")
Gear1Special=(3,,,"13,35")
Gear1Special=(4,,,"14,34")
Gear1Special=(5,,,"14,33")
Gear1Setting=0
Gear2Range=(0,0,13)
Gear2Special=(0,,,"14,33")
Gear2Special=(1,,,"14,32")
Gear2Special=(2,,,"15,33")
Gear2Special=(3,,,"15,32")
Gear2Special=(4,,,"15,31")
Gear2Special=(5,,,"16,32")
Gear2Special=(6,,,"16,31")
Gear2Special=(7,,,"16,30")
Gear2Special=(8,,,"17,31")
Gear2Special=(9,,,"17,30")
Gear2Special=(10,,,"17,29")
Gear2Special=(11,,,"18,30")
Gear2Special=(12,,,"18,29")
Gear2Setting=5

Simply put, special instructions here allow us to allocate each gear. The ratios themselves must be in quotes. All special entries follow the format:
*Special=(<Index>,<non-translated value prefix>,<translated value postfix>,<instructions>)
Index is simply the entry you would like to replace the default values of. Essentially for non-translated value prefix, you can specify value of the display you’d like to show in the garage page, or leave it blank to use the defaults (recommended for gear ratios). Translated value postfix I would generally use the display unit. <Instructions> are special instructions to override the physical values. They can be unique for different sections of the HDV or engine files. For example, gear ratios need to take 2 entries, for example “17,29” which represent the teeth on the input, and output shafts respectively. The final drive ratio version takes 4 parameters, the first 2 being the bevel gears. If I were to add them for the BT44 the first entry would look something like FinalDriveSpecial=(0,,,”1,1,7,31″).

As always, the latest BT44B is already up on steam and likely already downloaded to your machine (if you’ve subscribed).

So last week, I covered the absolute (or near enough) minimum to get the physics to work in rF2, from an rF1 base mod. This week, continuing with the Brabham BT44B, we’re getting rid of a bunch of old lines, replacing some and adding a few newer ones. Some provide tiny corrections to calculations, or use more complex algorithms to solve problems more accurately. Others allow a bit more freedom. As good practice, it’s a good idea to clear out as much irrelevant or obsolete parameters as possible. Scrolling through the .HDV file, I will outline each parameter, that has been added, replaced, updated or defuncted. As I briefly touched on last time, our physics engineer, Terence, has worked very hard to ensure backwards compatibility. As such, these changes are optional, but can bring about certain benefits, the purpose of which I shall try to illustrate. We will proceed section by section.

[GENERAL]

The first line that can be replaced comes under the [GENERAL] section, and this is:

FuelTankPos=( 0 , 0.15 , -1 )

In this case, we have a newer version that is actually split into 2 parameters. FuelTankPosFull= & FuelTankPosEmpty=. If you hadn’t worked it out by their names, the fuels’ CG (centre of gravity) now migrates between a full and empty fuel tank. This represents a tiny influence on overall vehicle dynamics for a heavy GT car, but in a grand prix car (such as this), changes in fuel can be more influential. Let’s break down why, the car is 650kg, with a fuel tank size of 41 imp. Gallons, 186.4L. The specific weight of fuel is about 0.74kg/L, the fuel weighs in around 186.4*0.74=~138kg. As a portion of the vehicle mass, that’s 138/(650+138)=~0.175. This means, with a full tank, ~17.5% of the cars’ weight is fuel! As fuel is spent from the tank, the influence it has on the overall vehicle CG also reduces. By the time you get to an empty tank it has no influence on the CG at all. This means, using a weighted average, a properly configured version of FuelTankPos=, would have assumed an approximately 75% full fuel tank, or perhaps better yet, 75% of the typical starting fuel load (for certain series’ which don’t necessarily run full tanks). If we look at the first value of FuelTankMotion=(490.5,0.67), 490.5 N/m is the spring rate, per kg of fuel. 1kg of fuel weighs 9.81N, so just sitting there, the fuel has moved 9.81/490.5 = 0.02m downward due to gravity. Therefore the effective CG of the fuel is 0.13m above the reference plane, with the older variable. If we assume a 10mm clearance between the bottom of the chassis and the bottom of the fuel tank, an empty tank would give us a 0.13-0.01=0.12m change in height. A full tank will double that, (1/0.5)*0.12+0.01=0.25m. If I were to assume the calculation was done at 75%, (1/0.75)*0.12+0.01=0.17m. To correct for the movement we need to add that 2cm back to the vertical height of both variables, so what we end up with is:

FuelTankPosFull=(0, 0.19, -1)
FuelTankPosEmpty=(0, 0.03, -1)

These values are quite plausible, given the triangular shape of the fuel tanks. A triangle has its CG at 1/3 of its height (assuming the lower 2 co-ordinates share the same height). The BT44 essentially has 3 fuel tanks, 2 in the ‘sidepods’ and one behind the driver. Yes, the driver was effectively surrounded by fuel. Calculating a proper CG will be difficult, but it looks like we have a good base.

This screenshot shows how the fuel tank location looks in-game. To view this mode, press CTRL+U in developer mode. There are additional display options here, pressing CTRL+U again will disable vehicle body rendering, the last display will be an engine power / torque curve, which may also be of interest. The yellow cross-hair is the current fuel CG, while the gray cross-hair is the origin. The blue lines represent the center of gravity, both total and body only. While taking the screenshot, I noticed there was an orange cross-hair in limbo. These orange cross-hairs are undertray points which you can find a bit lower in the HDV file. The BT44 was only using 11 of the available 12 undertray points. Generally, more will give a better collision response with the ground, as the cars shape is better represented.

From:

Undertray10=( 0 , 0 , 0 )

To:

Undertray10=( 0.25, 0, 0)
Undertray11=(-0.25, 0, 0)

With any luck, this might allow the car to ‘catch’ more accurately on sharp terrain edges, like embankments, tall curbs or rough grass.

Next up, another supersession, quite optional again:

CGHeight=0.238

Replaced by:

CGHeightRange=(<base>,<stepsize>,<steps>)

This feature was required by our Go-Kart implementation in rF2. Those vehicles allow seat height adjustments and this is an important tuning option for them. Go-karts are very unique in that they have locked rear axle and limited adjustability. They don’t have a true suspension, and are extremely light too. For these reasons, they are unique in that they don’t always want the lowest possible center of gravity. Full-size racing cars by contrast, virtually always want the lowest possible CG, and thus this feature is probably irrelevant to anyone reading this (unless you happen to be working on your own karts). I will use the newer variable regardless, but it makes no difference in this case.

We end up with (the equivalent value of):

CGHeightRange=(0.238,0,1)
CGHeightSetting=0

Next we scroll down to:

AISlipReaction=(650,20)

This particular line is obsolete, and so can be safely removed.

Next up on our radar is:

AIAimSpeedsPerWP=(25,50,75,97,120,145,170,190)

You may choose to copy these values to your talent (.RCD) file. In all likelihood though, they can probably be improved and may not even work as well in rF2 as they did in rF1. If you do want to copy these, the best way is by starting in dev mode and loading a circuit with your vehicle. Once the track has loaded, go on track, Pressing CTRL+\ with bring up the AI editor and selecting the “Edit Driver Stats” option will bring up the relevant parameters. There you can ‘Create New Driver’, which will generate a new .RCD file (if one doesn’t already exist). Select the driver “default” and enter the previous values, as the speed step values. Note the first value is “StepDistance” and was hard-coded to 5 meters in rF1.

This is what the Brabham driver talent (.RCD) file, looks like now.

Completely obsolete:

AICornerReductionBase=180

We can safely eliminate this line from the .HDV file.

AIMinPassesPerTick=10

While this is not obsolete, I will briefly cover it. While higher is ‘better’ it does cost us some processing power. This is not recommended as it might take people with lower end systems over the edge of being able to run in real-time, and that’s really bad news. Generally, AI will already look fluid with values of 4, and in practice this works well with softly sprung vehicles. Really stiff cars or cars with a lot of aero that tend to run on bumpstops are sometimes in need of an increase here to cope. So in general, try to get away with the lowest value you can.
Anyway, it has now been changed to:

AIMinPassesPerTick=4
AIRotationThreshold=0.25

Defaults to 1.0 in rF2, it’s no longer really a necessary parameter, so I’m removing it from the BT44. This variable increases passes per tick by 1 when the AI exceed this yaw rate (rad/sec) intended to give the AI slightly higher fidelity physics in corners, basically. But if you have a AIMinPassesPerTick value of 4 or higher, then this is unnecessary.

AIEvenSuspension=0

Is completely obsolete, say hello to our old friend, the delete key. In short, it was formerly a hack for the AI that could be used to improve their stability. Use of this variable would increase the disparity between AI and player physics, hence we no longer offer the option to use it.

AISpringRate=0.9

Has been replaced by:

AICornerRates=(0.9,0.9,0.9,0.9)

Basically, does the same thing as the old parameter. More intelligently however, it allows us to manipulate the AI’s spring rate per corner of the vehicle. Because the AI run a simplified suspension, this should factor in the motion ratio squared from each wheel. The motion ratio is essentially the ratio of wheel displacement vs damper shaft displacement (assuming a coil-over). The ordering is <FrontLeft>,<FrontRight>,<RearLeft>,<RearRight>, and we’ll continue to use the old value of 0.9 everywhere, for now.

AIDamperSlow=0.8
AIDamperFast=0.8

Replaced by:

AIDamping=(1.0,1.0,1.0,1.0)

If you use the old variables, (which do still work), the AI will remain using a simplified damper. This improves their correlation by giving them more human-like dampers, we’re going to stick with 1.0 multipliers. Note that damping rates are already multiplied by “AICornerRates”, which means you can hopefully stick with 1.0 values for all cars.

AIDownforceZArm=0.0
AIDownforceBias=0.75

In theory, these haven’t changed, but hopefully with some subtle improvements in the AI’s physics we might be able to change AIDownforceBias=0.75 to 0, which gives us a better correlation with player physics. Basically, it’s a hack to move the AI’s aerodynamic downforce distribution. AIDownforceBias 1.0 tells the game to put the aero distribution at a fixed hard-coded location, based on the weight distribution, for which AIDownforceZArm acts as an offset to. While AIDownforceBias=0.0 gives us the most human like aerodynamics. If AIDownforceBias is 0, then it’s irrelevant what you do with AIDownforceZArm, it has no effect. It can sometimes be useful as a tuning agent when AI experience either high speed understeer, or oversteer. High-speed understeer can often be cured or improved by moving downforce bias forward. If AIDownforceBias is set to 1 and AIDownforceZArm set to 0, it will place the center of downforce at the vehicles’ center of gravity. Generally race cars are designed and setup with the downforce behind the center of gravity, in the realm of 2-15% behind (with larger disparities possible in very low downforce, or positive lift vehicles). The AI may not always react perfectly to that, though as their suspension, despite improvements, remains simplified to reduce CPU utilization.

Completely obsolete:

AITorqueStab=(1.0,1.0,1.0)

This was an old hack, no longer needed, it’s been hard-coded to 1.0. Delete.

Completely Obsolete:

FeelerFlags=0
FeelerOffset=(0,0,0.262636)
FeelersAtCGHeight=1
FeelerFrontLeft=( 0.7 , 0.22 , -2 )
FeelerFrontRight=( -0.7 , 0.22 , -2 )
FeelerRearLeft=( 0.45 , 0.77 , 2.1 )
FeelerRearRight=( -0.45 , 0.77 , 2.1 )
FeelerFront=( 0 , 0.22 , -2.1 )
FeelerRear=( 0 , 0.22 , 1.7 )
FeelerLeft=( 0.7 , 0.22 , 0 )
FeelerRight=( -0.7 , 0.22 , 0 )
FeelerTopFrontLeft=( 0.82 , 0.22 , -1.5 )
FeelerTopFrontRight=( -0.82 , 0.22 , -1.5 )
FeelerTopRearLeft=( 0.99 , 0.22 , 1.56 )
FeelerTopRearRight=( -0.99 , 0.22 , 1.56 )
FeelerBottom=( 0 , 0.27 , 0 )

As the collision feeler system was replaced by a generally better mesh based system. For rFactor 2, it’s recommended to remove these lines.

[FRONTWING]

FWLiftHeight=(0.5)

Replaced with:

FWLiftHeightPlus=(0.0,0.5,0.0)

The old value allowed only a linear variation in downforce with changes in front wing height (above the ground). The new version allows a Square root relation to ride height, in addition to squared relation. The value I used here is equivalent to the old value, but this allows a bit more power / freedom should we need to change it in the future. Aerodynamic data is hard to come by for older vehicles but we’ll have to investigate this in the future.

[BODYAERO]

There are few changes here. But the HDV was missing a couple rF1 entries,

DraftBalanceMult=1.0
BodyDraftLiftMult=1.0

We’ll add them now, in the event that we might need them in the future.

In addition, we now also have:

RadiatorDraftFract=1.5

A new feature for rFactor 2, allows draft to interfere with the engine cooling of any car that may follow. What this variable does is to multiply the difference in air-speed due to draft. Therefore, it will mostly affect the car behind. We choose values above 1.0, because we can assume that the air coming off the car retains some additional heat (race cars get hot). In addition, turbulent air flows usually reduce cooling efficiency some. In practice, a 50% exaggeration (1.5) seems to correlate well with most cars, it should probably always be above 1.0.

One section was previously commented out (disabled), and thus falls back to defaults. I speak of:

//BaseDropoff=0.18
//LeadingExponent=80.00
//FollowingExponent=1.75
//VehicleWidth=2.10
//SideEffect=1
//SideLeadingExponent=2.0
//SideFollowingExponent=3.5

Additionally, BaseDropoff= has been superseded by BaseDropoffLeadFollow=(<lead>,<follow>). The main reason for this addition is that open wheeler aerodynamics behave somewhat dissimilarly to closed wheel type race cars (particularly sedans / GT’s). The leading wake of open wheelers tends to be much weaker due to a lower frontal area. Additionally the frontal area is broken up and sporadic. A little research from our previous vehicles (namely the Dallara DW12 and FISI 2012) has shown that for an open-wheeler the leading value should be approximately half of the following value. The BaseDropoff= generally tended to be configured with a greater emphasis on accuracy of the trailing draft. Therefore I will use the following values for the BT44, for now:

BaseDropoffLeadFollow=(0.09,0.18)

For sedans or GT’s, you might want to keep the same or similar values for both the lead and follow component.

Going down the list, “//LeadingExponent=80.00” was set this way to prevent sudden snap oversteer when a car followed too closely in an open wheeler. The proper fix has been the improved parameter outlined above, and no longer do we need to exaggerate this value to prevent such issues. LeadingExponent=2.2 it is.

//FollowingExponent=1.75, the default is 2.0, and that’s what I’m going with for now.

VehicleWidth=, this variable, should be roughly the width of the car, maybe a little bit higher. The car’s track width at the rear is 1.5494m (61 inches, ref: statsf1.com). According to our trusted source of last week, the rear tyres are approximately, 476mm (ref: Avon). It’s always good practice to get at least 2 references to any claim, as errors do crop up. And no, that doesn’t simply mean going to 2 sites like Ultimatecarpage or Conceptcarz, as they both usually use the same source and are often a copy / paste of each other.

SideFollowingExponent is the only other variable I will alter, our default of 3.5 is probably inappropriate for most vehicles. I’m using about 20 for this car.

The section now looks like:

BaseDropoffLeadFollow=(0.09,0.18)
LeadingExponent=2.2
FollowingExponent=2.0
VehicleWidth=2.10
SideEffect=1.0
SideLeadingExponent=2.0
SideFollowingExponent=20.0

A visual representation of which, in-game looks something like:

You can view how these parameters affect the draft while driving around in dev mode, by pressing CTRL+Z. The aqua arrows are ‘forward’ draft, reducing drag, while the purple arrows are areas where other vehicles will see an increase in effective air speed, and thus, drag.

[DIFFUSER]

DiffuserBase=(-0.5,-4,16)
DiffuserBasePlus=(-0.5,0,-4,16)

The new values are <Base (1st as before)>,<SquareRoot (New)>,<Linear (2nd)>,<Squared (3rd)>.

DiffuserFrontHeight=(1.5)
DiffuserFrontHeightPlus=(0,1.5,0,0.16)

New variables are with front ride height <SquareRoot (New)>,<Linear (Old)>,<Squared>,<Max Front Height>. Max front height acts like a cap, the rest are multiplied by the diffusers’ current front ride height. I’m using 0.16 as the max height used for the front diffuser height.

This:

DiffuserDraftLiftMult=1.4

Had a bug in rF1, whereby it wasn’t working properly. So in rF2, you may want to make sure it is configured properly, I’m setting it to 1.0 which basically maintains the effective air speed while in draft, for lift calculations. The old value would exaggerate the effective air speed due to draft, on the lift coefficient of the diffuser by 40%. Say we were headed at 100mph, and the car behind was going close enough that the effective air speed was 90mph, due to the effect of draft. Continuing on, that represents a change in air speed of 10mph, which would have been exaggerated as a 14mph draft on the lift coefficient. Every “*DraftLiftMult” parameter follows the same logic.

[SUSPENSION]

Out with the old:

CorrectedInnerSuspHeight=-1

And in with the new:

CorrectedInnerSuspHeightAll=(0.00655,0.00655,-0.0067,-0.0067)

This allows individual control over each wheel (FL,FR,RL,RR), rather than the old behavior. This also contains a fix for live axle inner heights. -1 is not particularly accurate because the inner suspension heights would get changed based on the ride height setting in garage, for default ride heights, it should make no difference with properly configured files. How should it be set? The correct usage is to subtract the suspension design ride height (ground clearance) from the static tire radius.

The example using the BT44 would be, taking a look at the 2nd “Pos” value of the relevant wheel, in the .pm file (or ultrachassis.ini):

// Front wheels
[BODY]
name=fl_wheel mass=(16) inertia=(0.5419344,0.32774128,0.32774128)
pos=(0.7112,0.188,-1.456436) ori=(0.0,0.0,0.0)

Looking in the .TBC, for the front tyre the relevant values are:

Radius=0.254
SpringBase=20000
SpringkPa=1150

In the HDV, the default front ride height is:

RideHeightRange=( 0.045 , 0.001 , 11 )
RideHeightSetting=7

Giving us 0.045+0.001*7=0.052m

Using the same technique, the default pressures are 127 kPa.

The deflection or static tyre radius could be calculate from the weight acting on the tyre divided by the tyres’ spring rate. The vehicle is 650kg with 50% weight on the left side and 38.8% on the front axle, these can be multiplied with the acceleration due to gravity constant 9.80665. 650*0.5*0.388*9.80665 giving a result of ~1237N vertical load on the front tyre. The spring rate is 20000+1150*127=166050. The deflection of the tyre is therefore, 1237/166050=~0.00745
So, TyreRadius-TyreDeflection-WheelHeight(.pm file)-RideHeight
0.254-0.00745-0.188-0.052=0.00655
This is close enough to 0, that I will assume for the time being, that the car is simply running a lower ride height than it’s design parameters.
The same math yields a result of -0.0067 for the rear.

Following on:

FrontWheelTrack=0
RearWheelTrack=0

According to a few sources on the internet, the front track width is 56″ and the rear is 61″. So we can replace the above values with:

FrontWheelTrackRange=(1.4224,0,1)
FrontWheelTrackSetting=0
RearWheelTrackRange=(1.5494,0,1)
RearWheelTrackSetting=0

The change of track widths to a range allows wheel track adjustments, as possible in some cars via wheel spacers. This was added particularly for the go-kart, but has its uses with some other vehicles, too.

A more important one here:

SpringBasedAntiSway=1
AllowNoAntiSway=0

These have been replaced with:

FrontAntiSwayParams=(1, 0, 0)

And a separate one for the rear (RearAntiSwayParams). The values follow <SpringBasedAntiSway>,<AllowNoAntiSway>,<AllowOnbo ardAdjustments>. This allows different behavior for the front and rear anti-roll bars, which was not possible in rF1. The activation of the new 3rd parameter activates onboard / in-car adjustments to anti-roll bars. I do not believe they had in-car adjustable anti-roll bars in F1 in 1975, so I will set this to false unless I find anything that tells me otherwise.

Continuing on:

FrontAntiswayRange=( 20000 , 5000 , 9 )
FrontAntiswaySetting=2
RearAntiswayRange=( 0 , 5000 , 13 )
RearAntiswaySetting=4

This is not obsolete, nor have the variable names changed. However, the rates need to be divided in half. Why? rFactor 2 has changed from a stiffness at ground approach to more of a component stiffness or “AntiSymmetric Model”. This is all just a really complicated way of saying that you need 5,000N of force, on each side to change the wheel displacement of a 5000N/m anti-roll bar, by 1 meter between the left and right wheels, as each side now receives the full force. Each side requires 5,000N, one upward, the other downward, totaling 10,000N.

It would have looked like:

FrontAntiswayRange=(10000, 2500, 9)
FrontAntiswaySetting=2
RearAntiswayRange=(0, 2500, 13)
RearAntiswaySetting=4

However, after testing, I realized from a driving perspective that I preferred a stiffer ARB setup, while this is largely driver preference an anti-roll bar as firm on the rear as the front generally makes little sense. So I decided to allow a larger maximum front stiffness and set up the front accordingly. The rear is slightly softer than v0.11 overall, but still firmer than the original base.

The final values are:

FrontAntiswayRange=(10000, 2500, 13)
FrontAntiswaySetting=8
RearAntiswayRange=(0, 2500, 13)
RearAntiswaySetting=6

[CONTROLS]

A new addition to rF2:

SeatRangeLongitudinal=(-0.4,0.16) // Eyepoint camera longitudinal adjustment range
SeatRangeVertical=(-0.07,0.04) // Eyepoint camera vertical adjustment range

Allow you to change the adjustment range of the seat position. Defaults are -0.1, 0.1 for both variables.

TractionControlGrip=(1,0.15)
TractionControlLevel=(0.6,0.95)
ABS4Wheel=0
ABSGrip=(1.0,0.2)
ABSLevel=(0.4, 0.95)

Although functionally equivalent, we’ll replace it with:

TCRange=(0,0,1)
TCSpecial=(0,,"Aid (Weight Penalty)","TC=(1.0,0.15,0.6,0.775,0.95)")
ABSRange=(0,0,1)
ABSSpecial=(0,,"Aid (Weight Penalty)","ABS=(0,1.0,0.2,0.4,0.95)")

The *Special= overrides are not something I have covered yet. They allow special instructions and garage display overrides. Different parameters allow different special instruction. In this case, “TC=(1.0,0.15,0.6,0.775,0.95)” is formatted in relation to the old parameters as, TC=(<TractionControlGrip1>,<TractionControlGrip2>, <TractionControlLevel1(Low)>,<TractionControlLevelMedium(New)>,<TractionControlLevel2(High)>). Traction control grip variables basically define the slip at which TC begins to engage. A better name might be ‘predicted slip curve slope’ or something like this, with the first value essentially being the slope gradient multiplier, while <TractionControlGrip2> is basically an offset, and positive values assume the tyres always have some grip. Increasing either ‘grip’ variables allows TC to engage later allowing more slip in the car. While the traction control levels basically adjust how much torque to cut when the tyre is slipping. It’s basically the maximum torque reduction that TC will allow. <TractionControlLevelMedium> is a new entry that allows you to override the TC level with “Medium” aid setting. 1 is for “Low” traction control and 2 is for “High” traction control. The only actual new functionality is that A) unlike before, you can change the medium TC level’s aggressiveness and B) you can now have garage adjustments to change these values. Because this car never had traction control in real life, I won’t be allowing any addition garage adjustments to be possible on the traction control (or ABS, as below).

ABS= follows a similar convention ABS=(<ABS4Wheel>,<ABSGrip1>,<ABSGrip2>,<ABSLevel1> ,<ABSLevel2>). “ABS4Wheel” is whether we use 4 separate channels for the ABS system or 1 channel. All cars that don’t have a real ABS system should have “ABS4Wheel” disabled, as it would basically allow vectoring different wheels based on individual grip levels. That could basically be considered a cheat as humans only have 1 brake pedal to play with.

Finally, we can also add this:

PitcrewPushForce=750
MarshalPushForce=750

The former tells the pit-crew how much force they can use to push the car, when it’s out of fuel in pitlane for example. The latter is how much force track marshal’s are able to use if you get stuck somewhere. 750N is about what we’d expect for a couple of average people.

[ENGINE]

This is following line is completely obsolete:

RestrictorPlate=Cosworth_DFV_1975.ini

Anything that you could have done here, can be done (better) through the upgrades.ini. You still need “Normal=Cosworth_DFV_1975.ini” to point to the right file, of course. At this stage, it’s looking likely that the next blog will cover the engine file in-depth, so stay tuned!

[FRONTLEFT]-[REARRIGHT]

I will cover these sections as a whole, because they duplicate parameters. In other words, every parameter under [FRONTLEFT] can be duplicated under [REARRIGHT] or any of the other 2 wheel sections. This means a single explanation can be applied to all 4 sections.
First up:

BumpTravel=0
ReboundTravel=-0.11

With:

BumpStopTravels=(0,-0.11)

A small improvement to the calculation of motion ratios has been done, making the bump-stop positioning more accurate. The bumpstop heights assume a ride height of 0. So the wheel can move up to -0.11m (negative being a downward direction) from the current 0 ride height before hitting the rebound stop, because the default ride height is 0.052m, the rear rebound travel is 0.058m from the static height.

SpinInertia=0.5419344
SpinInertiaAI=0.55

SpinInertia is obsolete, as part of the new “ModelWheelsinIncludeTireMass=1” variable (covered last week). SpinInertiaAI is still available, but we recommend to delete both. The default is to use the same as the player gets, meaning a closer correlation. Previously in rF1, the default behavior was to double the SpinInertia of the player vehicle when running AI physics (for stability reasons). Running AIMinPassesPerTick above 3 or 4 usually alleviates the need for this in all but the most extreme vehicles. However, before deleting it, one thing to check first is whether it matches with the first “Inertia” value in the .pm (or ultrachassis.ini file) for that particular wheel.

In this case that section looks like (with the relevant parameter in bold):

// Front wheels
[BODY]
name=fl_wheel mass=(16) inertia=(0.5419344,0.32774128,0.32774128)
pos=(0.7112,0.188,-1.456436) ori=(0.0,0.0,0.0)

People had a tendency to set SpinInertia correctly, but not its equivalent form in the .pm file, which was neglected because it was previously overridden by SpinInertia. If it didn’t match, I would have changed it (the bolded text) to match whatever value the SpinInertia had. In the end, SpinInertia was, 0.5419344 which is a match that defined in the .pm file. It’s important to check the remaining 3 corners as well. It is especially important to make sure the inertia’s of the wheels are set appropriately as this can lead to stability issues in rF2.

The rears are:

SpinInertia=1.439222928
SpinInertiaAI=1.44

Which also matches the .pm file. Therefore, there’s no need to change anything on that front.

TBC

Before I end this weeks’ session, let’s open up the TBC (AI tyre model and reference) and update that as well.

Firstly, we need to consider the effect that real-road rubber has on grip. Grip now increases with the road surface rubber. As cars generally used to be configured as having optimal track grip levels, we’ll need to reduce the base grip coefficients under, DryLatLong. To do so, we’ll need to open the TGM files, and look for the line GrooveEffects=(0.1,0.1,0.083,0.057). We need to find a sort of average that will work for the TBC, the 3rd value is usually close to that average, because of the way track surfaces are designed. So we’ll use 0.083 and we’ll assume the mod was designed for a 90% saturated track in mind, but we’ll also assume another 1% loss (which will come from GrooveSqrdEffects= line, not currently in the .TGM). In the end we’ll need to divide the current grip coefficients (DryLatLong), by (0.083-0.01)*0.9+1=1.0657.

Secondly, we’re missing the WetLatLong=(<Lateral>,<Longitudinal>), variable. It is now only used for some seldom used aids, like braking help, but it is still be wise to include this. What to set it to? Well, it would be quite complicated to match perfectly, because the TGM variable depends on many things, fortunately, this isn’t terrible accurate and for slicks a value of about 0.7x the dry value works quite well. The front tyre looks like:

DryLatLong=(1.72887,1.67634)
WetLatLong=(1.2102,1.1734)
RoadGripEffects=(0.083,-0.1,-0.16,-0.36)
RoadSqrdGripEffects=-0.01
RoadModifierMults=(0.5,0.8,0.8,0.5)

I’m using for the first value RoadGripEffects, I’m using the 3rd entrant of GrooveEffects=, from the .TGM value.
For the 2nd value, “MarbleEffectOnEffectiveLoad=-0.1” from the .TGM.
For the 3rd value, the 3rd value from “DampnessEffects” in the .TGM file.
Finally, for the 4th value, “TemporaryGripLossForWetness=0.36”. The RoadModifierMults, are multipliers for the real-road rate, say, if you have a rubber that particularly marbles up, or whatnot. Eventually, I will go through aspects of the .TGM file and explain the rationale behind some of these .TBC multipliers, too.

These are out:

AIPeakSlip=0.09
AITireModel=1.0

AITireModel is now hard-coded to be 1.0, as the tyres are exclusively for the AI, and also it more closely resembles a typical tyre slip curve. A value of 1.0 there, also nullified AIPeakSlip.

Finally, in their place we can add:

AIHeatRate=7.5e-6
AIPitThreshold=0.85

These were technically around in rF1 as well, AIHeatRate is how quickly the AI tyres get up to temperature (with the default being 6.6e-6). AIPitThreshold=0.85 is how much grip left, due to wear before the AI finally gives up on their tyres.

This is not a comprehensive guide, and this could be seen as complimentary information to the comments provided in the SkipBarber.hdv, which is included with the developer SDK (if you’ve migrated to Steam, it’s included, with the default path of C:\Program Files (x86)\Steam\steamapps\common\rFactor 2\ModDev\Vehicles\SkipBarber). Or you can download the SDK from the rFactor 2 website. On the same website you can also check out “rF2 Physics Calculator 0.21 ODS | Information – Feb 15, 2016” which has a complete parameter listing, although slightly out of date (missing AIDamping= only, I believe). I will try and update that one as soon as possible. All feedback is welcome and I hope you enjoyed this record breakingly detailed changelog! If you haven’t yet, be sure to subscribe to the Brabham BT44B V0.17 on Steam. Don’t understand something? Don’t be shy, you can seek clarification in the comments section.

In this blog, we’ll be taking you through the process of optimizing vehicle physics in rFactor 2. This will eventually include some spreadsheet releases and more in-depth explanations along the process. Furthermore, this also allows an organized way for us to receive feedback. I’m a firm believer that via example is the best way to learn something, and so that is the plan!

This first installment will delve into a question that many people have. And that is, so how do I get my rF1 physics into rF2? From a basic standpoint, you don’t need to do much at all, but you DO need to have some form of placeholder .TGM files. To do so, you need to look through the vehicles we have at the moment, and decide which is the most similar to the vehicle you’re working on. Pay a visit to the Dev Corner of the rFactor.net website, you’ll see a TGM archive (v0.8) which contains a (mostly) complete archive of ISI & donated .TGM files, if you feel like contributing to the project please feel free to submit them.

Filenames

It may help to know the filename structure that we employ when naming tyres. Looking at the somewhat recently released 2012 FISI, by opening the FISIR_Car.mas file, we can see a bunch of TGM’s which go by something like “245-660-13×12 Medium 2012.tgm”. Normally we put an abbreviation of the brand up front, in this case it could be preceded by a P_ but I elected not to do so, in this particular case. The next thing you’ll see is “245-660”, if you’re American, you might well be thinking, the heck is that? Generally, the first numbers represent the size of the tyre, in this case, in metric and, more specifically, millimeters. In this instance, the tread width is 245mm, with an overall diameter of 660mm. The following numbers “13×12” should hopefully be more obvious, the represent the rim size in inches, diameter, width. Following on, “Medium” is the compound name, sometimes we’ll write “Slick” (if there’s only one dry compound) or “S8” or whatever, as the compound. Finally, we include the tyres intended production year “2012” which helps us keep track of the evolution of the tyre. Although, it can sometimes get confusing, we prefer to follow brand naming conventions for tyre sizes. Different brands may use imperial, or different ordering of sizes (diameter first as opposed to width first). Racing tyres usually list tread width and overall diameter but street tyres are usually defined by their section width and the ratio of the height of the sidewall to that section width. Older tyres often went just by their section width and rim diameter, and so naming used to be even more confusing.

Let’s look at another tyre. The rabbit out of my hat points to the Dissenter tyre, “G_27.0x11.0-15×9.5_Slicks_1974.tgm”. “G” is a random brand association (I’ll let you guess the implication here). “27.0×11.0” is the size code, as used by that brand. “15×9.5” the rim size. “Slicks”, the tread pattern or compound. “1974”, the year of the tyre. If you happen to look up “27.0×11.0” on your favorite search engine, you might tend to find the correct tyre (of which this is a representation of). “27” is the diameter in inches, while “11” is the tread width, also in inches. This is the primary reason to stick with brand naming structure, even if it might be confusing to some, it tends to remove all doubt of which tyre it’s actually supposed to be. If in doubt, typically the last 2 numbers before the compound/tread name will be the rim size in diameter and width. The prior numbers should hopefully be obvious enough, but you may have to apply some logic as some brands measure in millimeters, others in centimeters, and others yet, use inches.

So I mentioned an example car?

Enough stalling, it’s drum-roll time. I am proud to announce a car we at ISI are working on. It just so happens that we’re working on bringing the Brabham BT44B (1975) into rFactor 2.

That’s this thing, if you didn’t know:

We’re doing things a little differently this time around, and this will be a Steam exclusive development release with details available here. The car and blog will develop together. Every update to the car via Steam will also coincide with a new blog entry outlining developments and changes.

Back to it, tyre choices

So which tyres did I choose for the Brabham BT44B? With it being a cross-ply / bias-ply tyre that I’m looking for (racing radials were first introduced by Michelin in 1977), I went to the cross-ply folder in our (recently updated) TGM examples archive. There I found something I know to be an approximate match (construction wise) to a 1975 Formula tyre. A 10-20-13.tgm and A 13.0-24.5-13.tgm, these are a representation of an early 70’s Can-Am type tyre and will do the job. A quick search revealed that the relevant Goodyear tyres of the time were sized at 9.2-20.0-13″ for the front and 16.2-26.0-13″ for the rear.

So at this point, I need to adapt these tyres into a suitable place-holder. To do so, as a minimum, we need to set the size multipliers and then we’ll see if our car works in-game. The tyre sizes are 10.0/20.0 for the front which compares to 9.2/20.0, so the radius is already OK, but the front tyres are slightly too wide. 9.2/10.0 gives us 0.92. A search for “SizeMultiplier” in the TGM file (which I have renamed to G_9.2-20.0-13x10_Slick.TGM) I simply replace the existing value with:

SizeMultiplier=(0.92,1)

This entry will be under the [REALTIME] section, and will adjust the overall tyre dimensions. The rear tyre has a larger size discrepancy. Comparing them, 16.2/13.0 for the tread widths and 26.0/24.5 for the diameter results in a SizeMultiplier=(1.246,1.062), actually a better result is to use:

SizeMultiplier=(1.246,1.07)

The reason for this is because the 24.5 is actually a bit smaller in radius than indicated (24.3″). [URL=”http://www.avonmotorsport.com/historic/racing-slicks/13-historic-slicks”]Avon’s[/URL] website has quite a catalog of historic racing tyres for reference. For this reason, it is wise to try and get measurements from the manufacturer directly, or at least from their website when all else fails. Tyre sidewall numbers are not always precise but may act as a last resort.

Before we can try the car in-game, and see if it behaves acceptably, we have to point the TBC file to the direction of the TGM files, so that rF2 knows what to look for. Under Front, we need to add a TGM= entry, it should look like this:

Front:
TGM="G_9.2-20.0-13x10_Slick.tgm"

While the rear should contain:

Rear:
TGM="G_16.2-26.0-13x17_Slick.tgm"

Looking ahead

And that’s it, we have a crude physics set working in rF2. Because the original physics were quality, they will remain mostly intact, and additional rF2 physics improvements will be made over the course of a few weeks, with each update having a corresponding blog post to show what has changed.

A short list of future changes will look something like:

• Updating, replacing and removing all old parameters.
• A proper new dedicated tyre that utilizes the contact patch model and all the latest tyre parameters.
• New internal combustion engine model.
• Ultra-chassis conversion (which allows chassis flex).

Steering range

But before I stop, let’s do something to make sure the steering range is reasonable. Under the [CONTROLS] section of the HDV file was an entry:

SteeringFFBMult=2

This line is obsolete and irrelevant in rFactor 2, so can be safely replaced. To determine a reasonable figure for this, while driving around in the developer SDK version of rFactor 2, press the key combination CTRL+V, which will show the Force Feedback outputs from the game. To keep FFB clipping to a minimum and FFB strength to a maximum, you can enable / disable this FFB output as needed. I came up with a torque of about 7.3Nm. Without any references, I used a conservative value for TurnsLocktoLock of 1.8 (likely too high). The top of the controls section now looks like:

[CONTROLS]
NominalMaxSteeringTorque=7.3
TurnsLocktoLock=1.8

There is one more thing left to do with a high importance. We need to add another line ModelWheelsIncludeAllTireMass=1 in the [SUSPENSION] section of the .hdv. With this parameter active, rF2 considers the tyre mass as already contributed the .pm or .ini file, as was the case with rF1. The preferred location for this line is just under “PhysicalModelFile=”. The top of this section now looks like:

[SUSPENSION]
PhysicalModelFile=BT44.pm
ModelWheelsIncludeAllTireMass=1

A quick test at this point has shown the car handles reasonably well in-game, so this will wrap things up for now. If you are trying a similar project and have strange grip issues, or whatnot, the likely cause is that your tyre radii between TGM and TBC don’t match. We will coincide future updates to the Brabham BT44B with new blog posts outlining the processes and changes, along with some of the tools that enable creation and analysis of certain things (like tyres). This will be done roughly in weekly installments and is likely to get more technical as we proceed. I hope that you enjoy our new section and look forward to reading your comments.