Community Tire Development Project - Building Better rF2 Physics Together

Frederick Alonso

Frederick Alonso

Registered
After months of professional racing collaboration (under NDA protection), I've identified the key principles that make tire physics even more realistic in rFactor 2. While I can't share proprietary data, I CAN share the methodology and physics principles that create authentic tire behavior.

A special thanks to Mike Schreiner, Robin Pansar, and April Carlsvard; without them, there would have been some byproducts I would have taken weeks to figure out, not knowing what the cause was of the issue. :D


The Problem We're Solving:
Forget the dev corner tires in this plot - this shows an adjusted tire that works with realistic tire pressure and temps using a very narrow grip range. Starting on a cold track, it behaves slippery on cold tires, pushing them over pressure X and temp X would also hold your laptimes back.

tireplot.jpg

This MoTeC analysis reveals the core issue: rF2's devcorner tire behavior (red scattered points) vs real racing tire data (tight white ellipse). Notice how the simulation data looks like a noisy cloud while real tires form a predictable, controlled pattern (you can almost draw a line following the points)? There are many red point overshoots. The issue is at the blue line red points, it was heavy understeer at a few tracks we noticed this on. Real life never goes so extreme. All else was very similar in the data, aside of this weird thing I pulled my hair out for.

That's why drivers have been gaining lap time through drift abuse (the well-known rF2 issue) - literally sliding at 45° slip angles for faster times. This isn't just unrealistic; it's completely backwards from real racing physics. Not bragging here, maybe it is only on the devcorner tires, I don't know. Just sharing what we found.

The 992 and BTCC cars had a better candidate, could not find it in their Motec tests myself. So I knew it was possible with the current TGM system. Without a team, I would never have found the real cause.

It only manifests under extreme conditions - as if understeer or drift becomes uncontrollable, and you're forced to accept it as "normal." The feedback" from 3 Pro GT4 drivers was always honest and respectful: "This isn't how real tires behave." or "Trash" or "Can really push it like real life" or "Too much grip when overdriving now".
I always offered 5 candidates on the front and rear through the TBC file so you could select them in the options. Each candidate had gentle differences and always had a full tTool calculation over it to make sure the Lookup table was fully up to date.

Community Solution:
Working with professional racing teams taught me that tire physics needs surgical precision, not sledgehammer approaches based on graphs or online guesswork. You can't just be lazy and reduce sliding grip globally ([Realtime]SlidingBaseCoefficient), which affects braking, cornering, and everything normal.

The exploits are specifically pressure and load-related. Some modders just tweak overall grip levels, but that doesn't solve the fundamental issue I want to address.

I was gently going in the right direction with targeted fixes, one parameter at a time, to eliminate physics exploits while preserving realistic driving dynamics. The result? Tires that behave like actual racing rubber.

Real-World Validation & Community Vision:
While community tire models aren't available yet, I've prepared a foundation hub and created my V0.1 as I see it Tire Development Guide.
I hope many will join me to build a proper tire base that can upgrade existing mods and elevate the scene to what it should have been all along.

We can only make it better, but it requires testing as well, and I have no time to do 30 tires in a few months. That would be just a risk and might even do worse.

I cannot share proprietary data. However, I know what it should be like or why Michelin has longer degradation than Pirelli.


How YOU Can Contribute and get credits for it later :):

Experienced Drivers: "Sanity check" our tire behavior against real experience; it is a cool winter project.
Data Analysts: Help interpret MoTeC telemetry and validate our physics, help us share code scripts to pull data. (Robin)
Technical: Parameter testing across different scenarios and conditions (Robin)
Mod Developers: Integration feedback and compatibility testing (Robin)
Calculations: People who like to give their pc some work in the background. (Emery)

Development Focus:
Realistic Pack - Eliminates drift abuse, creates proper thermal windows, what tire sizes, series?
Endurance Pack - Realistic degradation over 30+ lap stints
Formula Pack - Temperature-critical performance with proper pressure sensitivity

Community Collaboration Framework:
  1. Download & Test: Get early tire candidates later shared on a subpage on my website, or if allowed, shared on devcorner by S397?
  2. Structured Feedback: Should I make evaluation templates? (no random opinions - we need data and document it all)
  3. Systematic Development: Test one parameter change at a time to avoid clutter
  4. Professional Validation: Real racing drivers will evaluate our final candidates (or what we think is fine)
  5. Open Source Results: All successful parameters shared with the community, like a holy bible with min-max range and how it affects each code line.
The Long-Term Vision - King rF2:
Create such high-quality community content that:
  • S397 features it in the official dev corner
  • Mod developers adopt it as the new standard
  • Racing teams use it for driver training with confidence
  • The community benefits from professional-grade tire physics and we all have more fun at the end of the day.
This isn't just about better tires - it's about elevating rFactor 2's physics to match its max potential. :cool:

I was seriously impressed after testing the final version myself. How different yet familiar the slip behaved. It gave an extra depth to the experience.


My final request is to start somewhere in the open here. How could we pull this together, collaborate over a GitHub maybe or is that too complex? Should I arrange a Google form, or is there someone who has a better idea for this concept? I really would love to pull this together for everyone.
 
Last edited:
On my website you can download the devinfo.tgm
A stripped down tgm to get you starting:


[QuasiStaticAnalysis]
NumLayers=2 // Number of layers in the tyre, at present, this must be 2 or ttool will crash
NumSections=132 // Number of layers in the tyre, must be at least 2 or ttool will crash, 3 should provide more accurate behaviour however becomes computationally expensive, higher needs to be tested
RimVolume=0.01589 // Volume of air (m^3) of wheel rim, used to determine actual tire volume
DisplaceBulkMassWithPly=1 // Whether plies displace existing bulk materials when calculating masses
PlyCompressionTensionTransition=(-0.002,0.0001) // Strain to use compressive or tension modulus. Negative values represent compression.
RealtimeCamberLimit=45 // Angle limit (in degrees) for bristle positioning. Higher values compromise driving under normal conditions but will provide superior results when driving on 2 wheels for example. Note this does not effect the QSA model as bristle positions are generated by the real time model.
GaugePressure=0 // Air Pressure in Pascals (Pa) for ttool's QSA tests. In the real time model, this entry is used to identifying results in the lookup table.
CarcassTemperature=273.15 // Temperature in Kevlin for QSA tests
CarcassTemperature=353.15
CarcassTemperature=423.15
RotationSquared=0 // Rotation speed (rad^2/sec)
RotationSquared=18447
RotationSquared=37080.3333333333
RotationSquared=55900
NumNodes=49 // Number of nodes defined in the tyre, generated by ttool from the number of [node] entries below, again adding more nodes increases the detail and accuracy of the tyre. A minimum of 31 is suggested and the recommended range of nodes is 41-49 to achieve the accurate results, numbers exceeding this are generally not worth due to increasing computational demands along with diminishing returns.
TotalMass=9.412522719792774 // tire masses and inertia's below as calculated by ttool

[Node] // 0
Geometry=(0.08899,-0.19015,0.0171) // Outermost geometrical point (X, Y locations and, Thickness)
BulkMaterial=(273.15,1258,19800000,0.472,1,1340,0.25) // Bulk material properties (Temperature at which following properties are valid, Density, Young's Modulus, Poisson's Ratio, Compressive modulus multiplier, Specific Heat, Thermal Conductivity)
BulkMaterial=(373.15,1235,16200000,0.472,1,1492,0.24)
AnisoCarcassConductivityMult=(1.1,1,1.5) // Directional heat conductivity multiplier X, Y and Z
TreadDepth=0.0024 // thickness rubber, thicker makes tires less flexible and resulting in more grip loss as tires are less forgiving
RingAndRim=(0,960000000) // Fraction of node that forms part of the 'rigid' ring, spring rate of nodes' connection to the wheel rim
PlyParams=(1,0.001405,3) // Ply Angle, Ply Thickness, Connect Flags (1 = previous node, 2 = next node, 3 = both)

// More nodes are in between here, removed for easy reading

[Realtime]
StaticBaseCoefficient=1.985 // base grip coefficient for static friction
SlidingBaseCoefficient=1.34 // base grip coefficient for sliding friction
InclinationExtrapolation=1.0 // 0.0=no extrapolation, 1=extrapolate one step, 2=extrapolate two steps, etc.)
AbrasionCurveWLFStartStep=(-8.5,0.5) // WLF lookup start and step value
AbrasionVolumePerUnitEnergy=(7.02e-10,6.90e-10,6.66e-10,6.36e-10,5.95e-10,5.40e-10,4.25e-10,3.16e-10,2.29e-10,1.55e-10,1.20e-10,9.49e-11,7.64e-11,6.55e-11,6.00e-11,6.27e-11,6.82e-11,7.75e-11,9.71e-11,1.23e-10,1.64e-10,2.35e-10,3.22e-10,3.82e-10,4.31e-10,4.53e-10,4.64e-10,4.73e-10,4.80e-10,4.85e-10,4.88e-10,4.89e-10) // m^3/J volume of rubber sheared per Joule energy, max 32 values
DegradationPerWearFraction=(0.993,1,0.9992,0.998,0.9972,0.9966,0.9961,0.9956,0.9951,0.9946,0.9941,0.9937,0.9933,0.9929,0.9925,0.9921,0.9917,0.9913,0.9909,0.9905,0.9901,0.9897,0.9893,0.9889,0.9885,0.9881,0.9877,0.9873,0.9869,0.986,0.98,0.88) // Degradation based on wear fraction, max 32 values
DegradationCurveParameters=(344.15,6000) // (<activation_temperature_K>,<heat_history_step_Ks>) heat history is a linear progression of temperature over activation point multiplied by time
DegradationPerUnitHistory=(1,0.9925,0.9862,0.9809,0.9765,0.9729,0.97,0.9677,0.9659,0.9643,0.9628,0.9614,0.96,0.9586,0.9572,0.9558,0.9544,0.953,0.9516,0.9502,0.9488,0.9474,0.946,0.9446,0.9432,0.9418,0.9403,0.9386,0.9367,0.9345,0.9322,0.93) // Degradation per heat history step, up to 32 values
MassInertiaMultiplier=(1.0,1.0,1.0,1.0) // multipliers for mass (m), inertia (p,q,r)
TemporaryRingDamper=(0.085,0.094,0.094,0.17,0.16,0.16) // tire ring damping for x,y,z,p,q,r
TemporaryBristleSpring=(21700, 14500, 28500) // bristle spring rate for Lat/Vert/Long
TemporaryBristleDamper=(0.95, 0.9, 0.95)
MarbleEffectOnEffectiveLoad=-0.06 // fraction of load available for grip when driving on maximum marbles (10% less load in this case)
TerrainWeightOnContactTemperature=0.1 // temperature used for WLF is influenced by the track temperature (in this case, 90% tire surface, 10% terrain surface)
WLFParameters=(228.15,50,-8.86,51.5) // glass transition temperature. Other values pretty much the same for all rubbers, except butyl. Most likely, you won't touch the last three values.
StaticRoughnessEffect=-0.2 // terrain roughness influence on static friction
GrooveEffects=(0.092,0.092,0.076,0.048) // maximum groove influences grip here for: static friction, sliding adhesion, sliding micro-deformation, sliding macro-deformation
DampnessEffects=(-0.075,-0.08,-0.06,-0.03) // fully damp track (at threshold of standing water or more) influence on grip for same things as GrooveEffects
TemporaryGripLossForWetness=0.16 // Temporary hack aquaplaning. Decreases grip due to standing water.
StaticCurve=(153, 0.66, 353, 1.176, 653, 0.65) // at -100C there's 52% of maximum static grip, at 100C it's maximum, at 400C it's back down to 52% of max static grip
SlidingAdhesionCurve=(-9.2, 0.4, -5.2, 1.68, -1.2, 0.2) // min sliding speed (log(10) aTv), grip multiplier (for min), peak sliding speed, grip multiplier (for peak), max sliding speak, grip multiplier (for max)
SlidingMicroDeformationCurve=(-5.2, 0.3, -1.2, 1.8, +2.5, 0.3) // these values are blended following a cosine rule
SlidingMacroDeformationCurve=(-1.2, 0.2, +2.5, 2, +6.0, 0.4) // to get the totals the adhesion, micro and macro curves are then multiplied by the surface types as defined in the TDF files, the defaults of which are 0.25 for adhesion, 0.5 microroughness, 0.25 macroroughness
RubberPressureSensitivityPower=(-1.17,4.04e5,5e5,1) // rubber contact pressure sensivity power, offset, nominal maximum, normalize (1=yes,2=no)
IgnitionParameters=(493,0.06,49) // ignition temperature of rubber in Kelvin, heat power factor, nominal max of area*temperature_over_ignition
SizeMultiplier=(1,1) // if necessary, an adjustment to the geometrical width and radius; default is (1,1)
ThermalDepthAtSurface=0.0001 // the depth of the temperature sample layer used for contact properties (i.e. grip and wear); if provisional second layer is disabled, tread will never be allowed to get thinner than this value
ThermalDepthBelowSurface=0.0004 // (if provisional code enabled) the depth of the second layer; value should be >= surface layer but not too big; tread will never be allowed to get thinner than these two layers
BristleLength=0.12 // tuned to aid collision detection, no other physical effects
DampingHeatEnergy=(1.0,0.4,0.8) // (Fraction of ring damping heat into sidewall (should probably be 1.0), fraction of bristle damping heat into carcass, fraction of bristle damping heat into tread) the 2nd and 3rd values should generally add up to 1.0
InternalGasHeatTransfer=(10,5,0.6) // (base, mult, power) - heat transfer coefficients to internal gas cavity = base+(mult*(vel^power)), where vel is linear velocity of tire
ExternalGasHeatTransfer=(8,4,0.6) // (base, mult, power) - heat transfer coefficients to external air = base+(mult*(vel^power)), where vel is linear velocity of tire
GroundConductance=(1000,0.003,0) // (base, mult, reserved) - thermal contact conductance coefficient to ground = base+(mult*pressure), where pressure is contact pressure and the reserved variable will be used at some later stage.
WetConductance=(710,730,0,0) // Additional conductance due to (<dampness>, <wetness>,<and reserved for future usage 1>,<reserved 2>)
TireRadiationEmissivity=0.936 // thermal radiation emissivity for external tire surface
InternalGasSpecificHeatAtConstantVolume=(250,716) // (temperature (K), specific heat at constant volume (J/(kg*K)))
InternalGasSpecificHeatAtConstantVolume=(300,718) // 719 J/(kg*K) is an approximation for dry air, but value
InternalGasSpecificHeatAtConstantVolume=(350,721) // changes slightly depending on temperature
...
InternalGasSpecificHeatAtConstantVolume=(500,742) // you may have other issues if the internal gas reaches 500 degrees Kelvin

[LookupData]
Version=1.103 //followed by a massive encrypted code block of 15k lines in binary, something that changed on each edit of the code lines after running the calculation. I also noticed a better feeling in most cases instead of not doing a calculation and just adjusting the realtime values. This creates a gentle offset with the lookup, I prefer running Calculations each time to make sure all is validated.
 
I will keep track of those willing to participate and add your name for now in the first post.
We need enough people on board first, and then see what and how we will arrange this.
 
Last edited:
Looking forward to read your guide in great attention.

You are totally right about the traction eclipse thing. Although it also depends on driving style. Real drivers driving should have same result in simulation though. It is true a there were a lot of tires in rF2 made, some are better and some are worse. Some models were less complex, some later ones were more complex. Some tires were all over the place, and some were rather decently locked in respectable performance windows, but they allways seemed to be madeto be a little too skittish, not allowing for proper locked in driving where the line at the limit would be sharp and clear.

This being said to me rF2 tires has only one drawback - no structural failures, this is why they can be had with ridiculously low pressures. And pressures doesn't seem to have proper relation to rolling resistance.... I also always struggle to get proper longitudinal grip dynamics, but they can be achieved.

I have been working on 50s and 60s and early 70s tires parameters for past six years. Currently I am looking to expand to late 70s and late 80s. To me it is as much art as science. There is enough to still find, learn, and master for next 15 years to get the juice out of what rF2 can do. Tell that to Niels Heusinkveld and GamerMuscle preaching poor unwashed masses about how "complexity is bad".

What the hell are those ?
"Realistic Pack - Eliminates drift abuse, creates proper thermal windows, what tire sizes, series?
Endurance Pack - Realistic degradation over 30+ lap stints
Formula Pack - Temperature-critical performance with proper pressure sensitivity"

Shouldn't it be just "tires pack" ? And of course all tires has their strenghts and weaknesses, espcially in this dumb motorsports era where there are million tire compounds for every tiny little specific combination of circumstances. In older years there used to be few compounds, or even no variety, and they were made to just simply do the job. Now they optimize tires, they don't develop them.
 
Last edited:
What a comprehensive post and belief in the future of Rf2.Your posts and writing inspire. I have visited your webpage and are very impressed with the depth of your interest and commitment. Some of your subjects are way above my knowledge and abilty.I continue to work on my own small vehicle projects and tracks. Thank you
 
A tire must behave like a real tire, driving style will make you faster or slower. The simulation should demand accuracy because that’s what drives people to improve. After testing the NDA tires, the difference was unmistakable: a tighter margin for error, yet far more rewarding.

My earlier “packs” had no hidden meaning really, they were simply a proposal, wild idea or something to get us going here. The goal is to create a proper baseline system or tool for generating TGMs that are calculated, validated, and credible. We need structured tire families that reflect real construction and compounds, not the current “stretch it wider and call it done” approach that guarantees bad behavior, or why some mods feel great and others less great. Still trying to wrap my head around this big concept.

Road tires, semi-slicks, slicks, rain compounds, formula carcasses. Many category requires their own construction, thermal profile, and pressure sensitivity.

Using one model for absolutely everything is exactly why things go sideways. I’ve seen it plenty of times in TGMs, like a copy of a copy of a copy that’s been photocopied so many times it’s starting to look like modern art.

It’s basically like taking the physics of a giant Bigfoot monster-truck tire and slapping them onto a tiny karting kart just because someone resized a few lines of code and said, “Yeah, that’ll probably work.”

Meanwhile, the tire stiffness and air volume are still set to “crush small buildings” because nobody remembered to change them. So now your kart corners like a rubber asteroid and bounces like it’s trying to escape Earth’s atmosphere (and probably will). :D
 
Last edited:
I don't want to spoil your fun but I have many concerns about.

During the measurement, how many laps were recorded and in how many different tracks and conditions? Also the measurements should be repeated with different drivers to reduce the driver influence.
Then you must also consider the possibility that the discrepancies could be due to errors, both from the measurement and the simulation as well. Did you include error bars in your analysis?
You also need to keep in mind that the friction circle is also affected by speed through aerodynamics.
The same behavior should be noted in different tracks and with other drivers to safely conclude that the discrepancies arise alone from the tires.
I also fear that by adjusting the tires to fit the data you could fall into the confirmation bias, ie finding one model to explain just one particular measurement.
 
We're very interested. Besides proper turbo behavior, we're currently incessantly revising tires for the Sauber C9 and just cannot settle on it to even get a beta out for people.
 
JEmilio said:
I don't want to spoil your fun but I have many concerns about.

During the measurement, how many laps were recorded and in how many different tracks and conditions? Also the measurements should be repeated with different drivers to reduce the driver influence.
Then you must also consider the possibility that the discrepancies could be due to errors, both from the measurement and the simulation as well. Did you include error bars in your analysis?
You also need to keep in mind that the friction circle is also affected by speed through aerodynamics.
The same behavior should be noted in different tracks and with other drivers to safely conclude that the discrepancies arise alone from the tires.
I also fear that by adjusting the tires to fit the data you could fall into the confirmation bias, ie finding one model to explain just one particular measurement.
Click to expand...

Fully agree with that, they have tested with 5 DLC tracks that have Motec data, one of the tracks had one corner different and we found out the track had a gentle update in real life since 2016. So we ignored that tiny offset.
In total, 8 drivers said the same things, 3 of them have later given feedback to finetune the final details.
These are no small names in the industry, one of them had 9 years in GT3 experience for example. It was a real honor doing this project.

The same issues with the grip were showing up, and the setup of physics itself was validated as well to make sure we had no weird cambers or steering angles on the fronts. Therefore, as shown on my website, I added in test tools to measure the in-game angles of wheels and so on. Just to make sure all was correct. Early on, they found my requests sometimes a bit strange, but figured out that it was very important to get all exactly the same. Front wheel rotation vs steering rotation is 1 to 1 for example. I had with my mod 5% difference before the upgrades.
The same complaints have been around as well on other cars I gave them to test. So it is for sure something that is not correct in the devcorner tires. Personally, I felt the difference as I can basically swap between the old and updated ones. It is all gentle, but the laptimes feel more realistic, and I need to drive more precisely to keep laps stable. While on the old ones, I could screw up sector 1, push harder on the sectors after with serious abuse, and gain back my lost time. That is unrealistic under heavy grip loss situations and drifts all around.

In total I have gotten data of 5 tracks, with sessions of 30 minutes between drivers on each track. As the afternoons for the team got full fast, they did what they can to offer enough testing and setup tips to get the maximum out of the private mod. Even without it, I always tested myself upfront of delivering new updates. I was fully aware of what behaved differently and then waited on feedback to validate what I experienced myself.

In total I can see real vs sim of over 300 laps with around 50-60 laps on 5DLC tests. That is not nothing. If you then see similar plot extractions of the same oversteering and drift issues in early stages, you can be pretty sure about it. It is all gone now.
 
Last edited:
Frederick Alonso said:
A tire must behave like a real tire, driving style will make you faster or slower. The simulation should demand accuracy because that’s what drives people to improve. After testing the NDA tires, the difference was unmistakable: a tighter margin for error, yet far more rewarding.

My earlier “packs” had no hidden meaning really, they were simply a proposal, wild idea or something to get us going here. The goal is to create a proper baseline system or tool for generating TGMs that are calculated, validated, and credible. We need structured tire families that reflect real construction and compounds, not the current “stretch it wider and call it done” approach that guarantees bad behavior, or why some mods feel great and others less great. Still trying to wrap my head around this big concept.

Road tires, semi-slicks, slicks, rain compounds, formula carcasses. Many category requires their own construction, thermal profile, and pressure sensitivity.

Using one model for absolutely everything is exactly why things go sideways. I’ve seen it plenty of times in TGMs, like a copy of a copy of a copy that’s been photocopied so many times it’s starting to look like modern art.

It’s basically like taking the physics of a giant Bigfoot monster-truck tire and slapping them onto a tiny karting kart just because someone resized a few lines of code and said, “Yeah, that’ll probably work.”

Meanwhile, the tire stiffness and air volume are still set to “crush small buildings” because nobody remembered to change them. So now your kart corners like a rubber asteroid and bounces like it’s trying to escape Earth’s atmosphere (and probably will). :D
Click to expand...

Ttool/tire construction phase is something I have not touched yet myself. It would be next step someday. It is enough of a learning curve to only deal with Realtime parameters and relocating nodes with online tools from Chris. Picking similar official good tire, and going from there is a valid way. You can get a very good tire still, and in much less complex down to earth mere mortal aproachable way. There is a leveling up too, for example: from super simple Howston G4 tire, to more complex Cobra tire model, to more complex Howston Dissenter tire model, to more complex March M761 tire, what is next after that ?

True about recycling tires very much, but as long as it is being done for similar tires, and not deviating too far away to extremes, this approach is giving very good results. Of course it would be better to be able to build a whole new tire from scratch, not needing to use size multipliers at all, with whole unique lookup data generated.

Average rF2 mod tire, is probably still much better than what is best possible in more simple simulation such as AC.

I would not push the notion that those who mod for rF2 must use all most professional highest level approaches. This is exactly why modding in rF2 is sparse, and rF2 reputation doesn't reflect what it is.

I would be super happy though if something in the community would work out with your idea @Frederick Alonso, and people would always have a good source to look up to when they are ready to make a next step improving what they can do with rF2.

As I said I would also encourage people to do what they can. Not always there is a possibility to work with pro teams with legit pure data, and real drivers. People also need to spend lots of time to learn. And sometimes "modern art" and guesstimating is the way to go. And I must say as much as there are negativity from certain physics gurus around from others sims, talking about how those more smple tire models are more straight forward when working with data. They don't talk about how this physical model is more intuitive and actually more straight forward in controlling what car is actually doing, what is truly happening with tire directly. This beauty of rF2 tire model is rarely promoted. You can do the "art" tire at first with limited data and based on observations. Then improve it later with data, and everything else if you are lucky to get it.

Recently AC Rally was released. It is first ever early access sim which people are praising from day one. However, I have noticed no one is comparing the sim to reality. Isn't it strange ?

Here I present you the most reliable data possible, but a "little bit abstract". Observing real car. And what you see ? Is it: "oversteer and understeer woohoo wow no grip, omg wow tire grip fast, now it is sliding", or do see beauty and dance of it, how the sliding and static grip grip are altering in many various ways, how dynamic it is - at times chaotic, and at times super steady. Does anybody have time to simple admire real beauty anymore ?


Well. If my post seems too much and lacking order. Perhaps I could at least end it with meaning. This beauty you can see of a real car dancing around. If you know rF2 tgms real time parameters super well yo uprobably already know what to tweak and i nwhat direction to get things happening in the ballpark. And should get something very highly realistic if you can build whole tire fro mscratch, and then also test it out trying to match verified data. Assuming you also get chassis, aerodynamics and all the "little" parameters somewhere about right.
 
mantasisg said:
Recently AC Rally was released. It is first ever early access sim which people are praising from day one. However, I have noticed no one is comparing the sim to reality. Isn't it strange ?
Click to expand...

There isn't a lot of real rally drivers that do sims. But Ryan's Road to Rally has been a really cool watch. He recently did a quick review.
 
All valid insights here. Yeah, also saw that video, that moment of real vs onboard in sim was nice to see. And then there is the one by Niels Heusinkveld, which goes into the throttle model again on the new ACR..

As there is not much feedback so far on tire sizes. I want to ask again, which would be good base sizes to go for?

Having different sets and figuring out a table with values that usually work might be an interesting route eventually. More a guide to get someone going, then a checklist that if that happens, then try ... and rebuild the TGM kind of workflow.
 
We all have multi-core computers these days (I've got 10 cores on the older one and a bunch more on the new one). Is it possible to run multiple instances of ttool, even if it required multiple screens?

***
In terms of processing efficiently, start with a single tgm, test it, then figure out which parameter to initially alter. Make 3+ new tgms with incremental changes to hand over to those of us offering calculation efforts. You'll get back the calculated files and can compare them back-to-back. Repeat with the next parameter.

Doing so will avoid the delays inherent in making a single change, having that calculated, testing it without any comparisons, and... well you can see what I'm thinking, right?
 
Emery said:
We all have multi-core computers these days (I've got 10 cores on the older one and a bunch more on the new one). Is it possible to run multiple instances of ttool, even if it required multiple screens?

***
In terms of processing efficiently, start with a single tgm, test it, then figure out which parameter to initially alter. Make 3+ new tgms with incremental changes to hand over to those of us offering calculation efforts. You'll get back the calculated files and can compare them back-to-back. Repeat with the next parameter.

Doing so will avoid the delays inherent in making a single change, having that calculated, testing it without any comparisons, and... well you can see what I'm thinking, right?
Click to expand...
I can only run one on my pc, don't know if a cloned logged in on Steam at the same IP on a second computer or laptop can run tTool in parallel.

Like your idea to collab and speed up TGM calculations.


Been thinking about digging into the topic of a big dragster race tire only at the rears. If I can create that typical flex, it might be a good concept in terms of tire dynamics. If this were to happen, we could show how great rF2 can be for unusual concept tires.


30366.gif


What I have also found out when making the race tires is that FFB comes from the front, sounds stupid, but having bad rear tires is only the behavior of the tire itself. I had a bad candidate, weird grain in FFB, placing good ones on the front and bad ones to the rear resulted in not being able to notice the grain, at least in my VRS wheelbase. I drop it as I also placed the rear tires on the front just to test for any abnormal behavior. It can be overlooked if someone is not aware of this and just goes along with the grip feeling in-game at the rear. We all know when the rear is starting to drift, hard to write down my point.
 
Last edited:
@Frederick Alonso That would be indeed an interesting project. We all know that rF2 tire is capable of realistic wobble when it is under heavy side force. It shows that rF2 mechanism of how tire grips is true to reality.

https://imgur.com/cDZ9hv1

It happens because tire works like this guy has explained:

In short slip angle doesn't really exist, tire turns in something like "torque frames". You can even feel it with your foot if you'd try to yaw it a bit pressed to floor (not too hard, because it is bad to your knee :D). This is one of the reasons why the way of tires simulation that rF2 does is largely superior to older more simple models as in rF1, AMS1 or AC.

It would be indeed very interesting to see if such "torque frames" are also true true to tires that are at complete wheelspin as seen in that dragster slowmotion gif.

It is very interesting trying to understand how it works . At first it looks like static friction is so large to keep tire in place while it stretches so much. Then when stretching becomes too strong, it simply makes the contact patch slip through. The slip through generates slight amount of thrust into little bit of roll at first. And with several more revolutions there will be enough of force to make tire roll out properly, and then dragster shoots up front like a rocket.

One interesting bit on topic (I guess it is on topic). When tires are developing drive force, they always have portion of contact patch that is fully sliding longitudinally, it is is the back of contact patch. The harder the driving force is the more of contact patch is sliding, eventually whe nall of it is sliding wheelspin is happening. I have complianed many times that in rF2 to me lack of wheelspining seems to be occuring, and when I make tires it is also difficult to get it realistic enough IMO.

Also interesting bit. The reason why wider tires are faster is because as contact patch goes wider, the relative portion of sliding contact patch becomes smaller to static contact patch portion. This ultimately means more grip. It also allows to use softer rubber, less slipping means less wear. Softer rubber gets fully embedded into tarmac irregularities, thus it is more load sensitive. At the end engineers ended up with tires that wear even more than narrow sane compound tires did, but modern compounds are so much softer and higher performing than they used to be...

rF2 is great because knowing things like these usually fits in, and rF2 also can give a feedback which might help understand real tires better.

For example try altering abrasive tire wear noticeably, and you'll see that tire feel changes, not just wear, because then it grips differently.

*****************

One of things I have been wondering about working with ttool. If I would ever get to handle it well. Would it be possible to make tire in rF2 that would allow controllable driving of a car on two side wheels. We all know IRL it is very possible, especially in United Arab Emirates. Perhaps it is not even possible in many sims, because it probably would require some different stage of contact patch simulation when tire is also using part of sidewall as contact patch. I would also like to know more about how tires needs to be setup IRL in order to successfully handle that track.
 
Frederick Alonso said:
All valid insights here. Yeah, also saw that video, that moment of real vs onboard in sim was nice to see. And then there is the one by Niels Heusinkveld, which goes into the throttle model again on the new ACR..

As there is not much feedback so far on tire sizes. I want to ask again, which would be good base sizes to go for?

Having different sets and figuring out a table with values that usually work might be an interesting route eventually. More a guide to get someone going, then a checklist that if that happens, then try ... and rebuild the TGM kind of workflow.
Click to expand...
Starting from the main tires from the decades is a good start, I'd say. In the 1980's you have Formula 1 and Group C, in the 1990s you have F1, the birth of the dominance of GT cars (ITCC, BTCC, STCC), and CART at its prime in the US, plus the super sportscars. In the 2000's you have more homogeneity but the rebirth of the Le Mans prototypes, FIA GT1, F1. Then what we currently have now, with F1, LMH, GTE/GT3.

This should provide an outstanding starting point for modders - including us - to borrow or build from a sample. It would help diminish the guess work or ironing of bugs when making the cars, including ratios between static and sliding values, etc.
 
You must log in or register to reply here.
Back
Top