Kagoni Tyre Simulation A Rabbit Hole Into Tyre Physics DISCLAIMER: This project was developed with extensive AI assistance in programming, research and debugging, every system and functions are heavily tested, observed, compared against real-world/research references and refined through MANY iterations to meet expectations. How trying to understand why one game felt better near the limit somehow turned into rubber friction, brush theory, thermodynamics, pressure, carcass behaviour, contact patches and tread wear. 1. THIS STARTED WITH FORZA HORIZON 6 This was never supposed to become a tyre simulation. I was playing Forza Horizon 6 around the same time BeamNG.drive was receiving updates. BeamNG had already discussed ongoing tyre-related research and recalibration work, so whenever a new update arrived I found myself immediately checking whether that work had made it into the game yet. It had not. And I was getting impatient. So I had the wonderfully dangerous thought: “Fine. I’ll try fixing the part that bothers me myself.” That sentence aged extremely badly. At this point I was not thinking about tyre thermodynamics. I was not thinking about carcass temperature. I definitely was not thinking about thirty-six tread thermal cells. I was thinking about one thing: Why did the cars feel so different near the limit? 2. WHY DID FORZA FEEL SO MUCH EASIER TO READ? This question had been bothering me for a while. Forza clearly puts a lot of processing between controller input and vehicle response. There are steering filters, speed-dependent behaviour, controller adaptation and other layers designed to make a car controllable with a gamepad. BeamNG, meanwhile, exposes much more of the raw vehicle dynamics. So the obvious explanation seemed to be: “Forza feels progressive because it is filtered. BeamNG feels harsh because realism is harsh.” For a while I accepted that. But the more I drove both, the less satisfying that explanation became. In BeamNG, many cars could feel excellent below the limit, yet the transition around peak grip could become extremely unforgiving. A slightly late correction, a slightly faster steering input, or a little too much throttle could sometimes feel like the tyre had gone from: Code: I have grip. to: Code: Good luck. almost immediately. Maybe that really was realism. Maybe the smoother behaviour elsewhere really was just assistance hiding the ugly truth. But there was one annoying problem with that theory. My RC cars did not feel like that. 3. THE RC-CAR PROBLEM Obviously an RC tyre is not directly equivalent to a full-size road or racing tyre. The scale, loads, construction, compounds, temperatures and operating frequencies are all different. But spending a lot of time driving and tuning RC cars had given me one useful piece of physical intuition: Rubber approaching its limit does not necessarily behave like a binary switch. You can visibly exceed the ideal condition. The tyre can deform. The car can slide. And yet there can still be a surprisingly wide region where the vehicle remains readable and controllable. That made the simple assumption: Code: harsh = realistic smooth = arcade feel increasingly suspicious. So I started asking a different question. What if part of Forza's nicer limit behaviour is not merely input filtering? What if some of it comes from how the tyre itself transitions through and beyond peak grip? That was the question that actually started this project. 4. FIRST ATTEMPT: JUST MODIFY AN EXISTING THERMALS MOD I still had no intention of building a tyre model. The sensible thing was to start with something that already existed. So I downloaded Luuk's Tyre Thermals and Wear Mod. It already provided an extremely useful framework for experimenting with: tyre temperature pressure grip adjustment wear live wheel state My plan was extremely simple: Code: adjust grip adjust temperature adjust slip behaviour drive repeat Surely I could tune the numbers until the tyres behaved the way I wanted. And sometimes I could. For one particular test. Then I would try something else and everything would fall apart. I could make the tyre progressive around peak grip, but sustained sliding became too strong. I could reduce sliding grip, but then the transition became harsh again. I could reduce heating, but ordinary circuit driving stayed unrealistically cold. I could increase heating, but one short understeer event cooked the tyre. I could change pressure sensitivity and fix one tyre, then make another behave strangely. Every coefficient seemed connected to something it should not necessarily have been connected to. At first I assumed I simply had the wrong numbers. Eventually I started asking a much more important question: “What if the problem is not the values? What if the structure of the model itself cannot represent the behaviour I am trying to tune?” That was probably the point where this stopped being tuning and became research. 5. FIRST MAJOR RABBIT HOLE: WHAT ACTUALLY HAPPENS AFTER PEAK GRIP? The first thing I wanted to understand properly was post-peak grip. My original mental model was basically: Code: tyre adheres → reaches peak → starts sliding → kinetic friction is much lower That naturally suggests a large grip cliff. And it seemed like a reasonable explanation for why BeamNG could feel so unforgiving. Forza's wider post-peak region could simply be fake. So I started looking at rubber friction and sliding behaviour. And then I ran into something that completely changed the project. The very low friction states associated with sustained rubber sliding were strongly connected to thermal state. In other words: perhaps a tyre does not lose most of its force the exact instant it crosses peak slip. A much larger loss can develop while the tyre continues sliding, generating heat and changing the condition of the rubber-road interface. And suddenly the whole thing clicked. WAIT. Instead of: Code: peak ↓ HUGE mechanical cliff ↓ very low sliding grip the behaviour could be closer to: Code: peak ↓ small immediate mechanical loss ↓ still-controllable sliding region ↓ continued frictional work ↓ thermal state changes ↓ progressively worse sustained-sliding grip That meant the broad post-peak region I liked might not necessarily require an unrealistic arcade trick at all. It could come from separating: instantaneous mechanical saturation from: time-dependent thermal degradation. This was approximately the point where my scientific response was: “I’M A F***ING GENIUS XDDD” Unfortunately, being a genius lasted approximately five minutes. Because the next question was: Okay. Which temperature? 6. ONE TYRE TEMPERATURE IMMEDIATELY STOPPED MAKING SENSE Suppose a tyre slides hard for one second. The microscopic rubber touching the road can become extremely hot. But has the entire tread become that hot? Has the belt package? Has the carcass? Has the cavity air? Obviously not. Yet if one temperature state controls everything, the simulation effectively says: Code: surface became hot therefore whole tyre became hot therefore grip changed therefore structure changed therefore pressure changed almost instantly. That explained another thing I had been fighting during tuning. A short slide could cause far too much long-term tyre behaviour. So I started looking into tyre thermal modelling. And the next important idea appeared: Different parts of the tyre live on completely different thermal timescales. The microscopic interface can change almost instantly. The road-facing tread responds quickly. Heat several millimetres into the tread responds more slowly. Belts and carcass respond more slowly again. Internal air and the wheel assembly live on another timescale again. The solution was no longer: Code: find a better tyre temperature It was: Code: stop pretending there is only one tyre temperature 7. FLASH TEMPERATURE: 300°C DOES NOT MEAN “THE TYRE IS 300°C” Research into rubber friction led directly to flash temperature. At microscopic asperity contacts, rubber can experience very high local transient temperatures during sliding. That gave me a way to represent something I had previously been unable to reconcile: A tyre can experience extremely aggressive local sliding effects without instantly heating its entire bulk structure. So a separate flash state was introduced. It can: rise extremely quickly reach very high local temperatures strongly influence immediate sliding-friction behaviour collapse rapidly once the sliding event ends But it has almost no direct authority over slow structural behaviour. A 300°C microscopic flash event does not mean that the carcass is at 300°C. That distinction sounds obvious now. It was much less obvious when everything was still represented by one number. 8. THEN I REALISED SLIP ANGLE ITSELF WAS NOT THE HEAT SOURCE Fixing temperature revealed another problem. I could now store heat in better places. But I was still generating too much of it. A tyre only slightly beyond peak cornering slip could sometimes receive heating far too close to what happened during a fully locked slide. Again, the question changed from: “How much heat should ten degrees of slip angle generate?” to: “Why am I using slip angle as the heat source at all?” A tyre can have substantial wheel-centre slip angle while much of the contact patch remains adhered and elastically deformed. Only part of the footprint may actually be sliding. So I started looking at brush-style tyre models. That introduced a much more useful distinction: Code: adhesion region + sliding region Now heating could depend on the part of the footprint actually rubbing across the road. Conceptually: Code: frictional heating ≈ sliding force × actual local sliding velocity rather than: Code: slip angle × magic coefficient This created one of the most useful sanity checks in the project. A truly locked tyre should generate vastly more sliding heat than a tyre merely sitting slightly beyond peak cornering slip. Likewise: Code: rear wheel speed = road speed + a few km/h during mild power slip should not receive the same treatment as: Code: rear wheel speed = enormous burnout speed That sounds obvious when written down. It was surprisingly easy to get wrong inside a simplified model. 9. PARTIAL SLIDING WAS STILL CHEATING Even that was not enough. Suppose only the trailing part of the footprint is sliding. If I give that entire region the full wheel-centre slip velocity, I am still exaggerating how much frictional work is being dissipated. So the model had to distinguish not only: Code: how much of the contact patch is sliding but also: Code: how developed the local sliding velocity is inside that sliding region That strongly reduced the absurd heating immediately beyond peak grip while preserving the large energy input of genuine lockup, burnout or sustained drift. At this point a pattern was beginning to appear: Every time I removed one artificial shortcut, the handling became easier to tune rather than harder. 10. THIS WAS ALSO WHEN TESTING STARTED TO CHANGE Very early in the project, I realised ordinary tuning was no longer enough. The old loop had been: Code: change something → drive → does it feel better? But by now I had already seen several cases where a change fixed exactly the test I had tuned it for... and completely failed somewhere else. So I became increasingly suspicious of any result that only worked in one condition. The question gradually became: “What is the stupidest operating condition I can put this model into, and does the same explanation still make sense?” I started deliberately comparing situations that should be physically very different. The useful question was no longer: “Can I make both numbers look reasonable?” It was: “Does the same physical relationship explain both cases?” Whenever the answer was no, there was usually a shortcut hiding two different mechanisms inside one coefficient. That became the development loop for almost everything that came afterwards: Code: model appears to work ↓ try something completely different ↓ something ridiculous happens ↓ trace the cause ↓ discover that one shortcut represented several physical processes ↓ separate them Eventually my favourite test became: Find the test that makes the model look stupid. Because those tests were usually where the interesting research began. 11. THE EXISTING “CORE” STATE NEEDED A MORE PRECISE PHYSICAL MEANING Luuk's original model already contained a slower thermal state called CORE. As the thermal model became more detailed, that existing state became increasingly useful. But its physical meaning also needed to become more precise. It could not literally mean the geometric centre of the tyre. And once fast road-interface effects were separated from slow structural behaviour, it also no longer made sense to treat CORE as simply: Code: everything that is not the surface So I began treating it as a reduced slow structural thermal reservoir representing the combined behaviour of things such as: belt package carcass plies deeper structural rubber cap plies and other relatively slow structural mass That made it much clearer which effects should care about it. A one-second slide can drastically change the immediate rubber-road interface. It should not instantly transform the complete structural response of the tyre. So short-term friction could listen strongly to the fast thermal states. Structural stiffness could listen much more strongly to the slow bulk state. The variable itself had been there from the beginning. What changed was the physical question I expected it to answer. Sometimes the model does not need another variable. It needs a better definition of what the existing variable physically represents. 12. HEAT NOW NEEDED SOMEWHERE TO GO Once heating had been separated into different processes, I needed to model how that heat moved. A simple: Code: surface ↔ core relationship could imitate a general cooldown curve. But it could not represent an actual temperature gradient through several millimetres of tread. So the tread gradually evolved into a reduced finite-volume thermal model. The tyre was divided laterally into: OUTER | MIDDLE | INNER and each region was then divided through tread depth. Eventually this became: 3 zones × 12 depth cells = 36 tread thermal cells per tyre. Not because I woke up one morning and decided that 36 sounded impressive. It happened because every simpler version eventually failed some useful test. Now the tyre could genuinely contain something like: Code: very hot road-facing rubber warm shallow tread cooler deep tread still-cool structural mass at exactly the same instant. That made transient heating and cooldown behaviour much easier to understand. 13. THE TYRE STILL HAS A CIRCUMFERENCE The 36 tread cells resolve: Code: width × depth They do not explicitly discretise the entire circumference of the tyre. Doing that in Vehicle Lua would become expensive very quickly. But the immediate road-facing surface also should not behave as if one hot contact event instantly spreads around the whole tyre. So the fast surface model also carries lightweight rotating hotspot memory. The idea is not to simulate every centimetre of circumference. It is simply to preserve enough rotational history that: Code: one hot footprint event does not immediately become: Code: the entire circumference is equally hot This is one of the compromises that keeps the model reduced-order while still preserving an important transient behaviour. 14. THEN THE TYRE COULD FINALLY WEAR DIFFERENTLY ACROSS ITS WIDTH Once OUTER, MIDDLE and INNER already existed as independent thermal regions, it became increasingly strange for wear to remain one uniform health value across the whole tread. Real tyres obviously do not always disappear evenly. Camber can bias one shoulder. Pressure can change centre-versus-shoulder loading. Cornering repeatedly works one part of the tread harder than another. So the wear model was split laterally too. Now the tyre could begin developing independent: OUTER | MIDDLE | INNER wear states. This was still an early version. The exact abrasion model was nowhere near finished. But at least the tyre could finally produce a shape rather than one global percentage. Naturally, I immediately drove around trying to break it. Which led very quickly to one of the funniest bugs in the project. 15. THE WALL IS NOT THE FLOOR During one of those early uneven-wear tests, I crashed into a wall. The outer tread immediately destroyed itself at an absurd rate. My first reaction was: Code: great the new wear model is broken So I traced the load distribution. And found something much funnier. The camber / support-surface raycast had occasionally accepted the concrete wall beside the tyre as if it were part of the road supporting the footprint. The simulation effectively saw: Code: valid tyre support plane detected angle: approximately vertical Which then implied: Code: ridiculous apparent camber → almost all inferred tread load moves to one edge → outer tread gets annihilated So very early in three-zone wear development I had to add filtering that rejected surfaces far too steep to plausibly support the tyre. It was a useful reminder that even a physically sensible equation can produce complete nonsense if the measurement feeding it is nonsense. Sometimes the project involved reading tyre papers. Sometimes it involved explaining to the code that: the wall is not the floor. :X 16. ONCE UNEVEN WEAR EXISTED, PRESSURE BECAME MUCH MORE INTERESTING Having three independent tread regions immediately created another question. If OUTER, MIDDLE and INNER can wear independently... why should they always carry the same workload? I already knew the classic real-world patterns: Code: too much pressure → centre tends to work harder too little pressure → shoulders tend to work harder But simply hard-coding: Code: lowPressure = shoulderWear highPressure = centreWear would just replace one magic multiplier with another. So I started looking at tyre contact-pressure measurements. The useful lesson was not one exact universal number. It was the relationship. Inflation pressure, vertical load, structural support and camber all influence how the footprint carries its load. That meant OUTER / MIDDLE / INNER needed more than different temperatures. They needed different inferred workloads. Conceptually: Code: pressure + vertical load + camber + tyre structure ↓ cross-tread load distribution ↓ local heating + local sliding + local abrasion This became the beginning of the transverse contact-distribution model. 17. THEN I REALISED I WAS NOT ACTUALLY STARTING FROM ZERO At this point I had begun building a much more physical idea of how I wanted the tyre to behave. I had: partial brush saturation temperature-dependent friction pressure and load effects tyre geometry a growing model of structural stiffness So it was tempting to simply calculate the tyre behaviour I wanted... and apply it. Then I realised there was a fairly serious problem. BeamNG already has a tyre model. My Lua code was not replacing the underlying contact solver from zero. It was sitting on top of an existing tyre that already produced its own: Code: force vs slip vs load vs pressure vs construction behaviour. So I could not simply say: Code: desired grip here = X and multiply the existing tyre by X. The force underneath my correction was already changing. And it changed from tyre to tyre. 18. TO CONTROL THE TARGET CURVE, I FIRST HAD TO UNDERSTAND THE CURVE I WAS MODIFYING This created a completely different technical problem. Suppose I want the final tyre to produce a particular force at a particular slip state. The useful correction is conceptually closer to: Code: required multiplier =================== desired target force / predicted native BeamNG force Which sounds simple. Except now I had to answer: What force would BeamNG's native tyre have produced here if my correction were not present? And that turned out to be much harder than choosing a nice post-peak curve. I now needed a model of the model underneath my model. :X 19. RECONSTRUCTING THE NATIVE TYRE RESPONSE So I started characterising BeamNG's existing wheel behaviour. I ran repeated tests around: low slip peak lateral force slightly beyond peak deep post-peak sliding different vertical loads different tyre pressures different widths and aspect ratios different tyre constructions The goal was not to reproduce BeamNG's complete internal tyre solver. I do not have direct access to it. The goal was to build a sufficiently useful reduced prediction of the native force envelope that the correction layer would know what it was modifying. This required combining observed behaviour with information inferred from the vehicle itself. The JBeam structure became particularly important. Instead of looking only at labels such as: Code: Standard Sport Race I started looking for structural clues: tyre width aspect ratio / sidewall geometry configured pressure wheel and tyre node/beam structure effective stiffness cues vertical load front/rear construction differences There is no convenient variable saying: Code: nativePeakSlipAngle = 6.7 degrees I had to infer it. This was one of the more technically difficult parts of the project. 20. THE COLD / BASELINE TYRE BECAME THE REFERENCE POINT This was why understanding the baseline tyre became so important. Before thermal behaviour could start moving the tyre around, I needed to know: What does this tyre look like before the thermal model changes it? So a large amount of calibration went into estimating relationships between: Code: pressure + vertical load + geometry + structure ↓ cornering stiffness + saturation slip + peak force + post-peak behaviour Once I had a reasonable estimate of that baseline response, temperature could modify something physically meaningful. Without it, temperature would simply be multiplying an unknown curve with another unknown multiplier. And the entire model would become impossible to reason about again. 21. B100 BECAME THE BRIDGE BETWEEN NATIVE BEAMNG AND THE TARGET MODEL I use the shorthand B100 for approximately full brush saturation. At first it was tempting to assign something like: Code: Standard = X degrees Sport = Y degrees Race = Z degrees But that immediately fell apart when comparing very different tyres. A: Code: 145/80 old passenger tyre and a: Code: 285/30 modern performance tyre are not the same physical structure with different grip numbers. Pressure matters. Load matters. Width matters. Aspect ratio matters. Construction matters. Temperature matters. Available friction matters. So B100 became dynamic. A simplified brush relationship gives the general intuition: Code: tan(alpha_sat) ∝ μ × Fz / Cα The exact implementation is necessarily reduced-order. But now the system has a way to estimate: where this particular tyre, under this particular pressure and load, should begin to run out of adhesion. That became the bridge between: the native BeamNG tyre underneath and: the research-guided target response on top. 22. THE MOD COULD NOT JUST “ADD MY GRIP CURVE” This became one of the most important technical breakthroughs. The correction layer does not need to destroy BeamNG's useful low-slip behaviour and replace it with a completely unrelated tyre. That would erase natural vehicle differences and require enormous per-car tuning. Instead, the aim became: Preserve as much useful native behaviour as possible, then apply the correction required to move toward the target response. Conceptually: Code: low slip → mostly native BeamNG behaviour approaching saturation → blend toward predicted target envelope around / beyond B100 → stronger correction authority deep sliding → target post-peak + thermal-history behaviour So the system is not simply: Code: replace BeamNG tyre physics It is closer to: Code: understand BeamNG's existing response ↓ predict where it is going ↓ calculate where the target model says it should go ↓ apply the correction required to move between them That is a very different problem from simply choosing a grip multiplier. 23. THE COLD PERFORMANCE-TYRE PARADOX Once B100, structure and available friction were separated, cold performance tyres produced another useful contradiction. Cold rubber can be structurally stiff. So: Code: cold tyre → sharp initial response can make sense. But the available friction can also be worse. So the same tyre can simultaneously have: sharp initial response high structural stiffness lower peak force earlier saturation poor gross-sliding grip That is much more interesting than: Code: coldGripMultiplier = 0.8 And it helped explain why a cold racing tyre can feel both: sharp and: terrible at exactly the same time. 24. WEAR THEN REFUSED TO BE JUST A MULTIPLIER Once sliding fraction, temperature and cross-tread load distribution existed, the old wear logic started looking increasingly artificial. A simple game-style model might say: Code: more wheelspin ============== more wear But wheelspin itself is not abrasion. Engine torque is not abrasion. Wheel RPM is not abrasion. Rubber physically sliding against the road is abrasion. So wear moved toward a relationship more like: Code: local contact load × local sliding velocity × compound response × thermal material response That connected wear to the same contact-patch state already responsible for frictional heating. Immediately, a lot of strange edge cases became easier to explain. 25. THEN SURFACE TEMPERATURE STARTED EATING TYRES TOO QUICKLY Once sliding wear became stronger and more physical, another problem appeared. The immediate road-facing surface can temporarily become extremely hot during aggressive sliding. If that temperature is given full authority over abrasion, then: Code: surface / flash region: extremely hot deeper tread: moderately hot core: much cooler can accidentally behave as if: Code: THE ENTIRE TYRE IS EXTREMELY HOT DELETE RUBBER A brief surface event could therefore destroy far too much tread. So the thermal authority used for slower material degradation had to become slower than the authority used for immediate friction. The fast surface still matters. But it should not pretend the whole tread has thermally transformed. That produced a rule which kept reappearing everywhere in the project: Fast thermal states should dominate fast effects. Slow thermal states should dominate slow effects. That one idea solved an amazing number of apparently unrelated problems. 26. THEN PRESSURE STARTED ANOTHER THERMAL RABBIT HOLE By this point temperature already had multiple timescales. But pressure was still too directly connected to tyre temperature. That started bothering me. The gas inside a pneumatic tyre is a sealed thermal body. If the inside of the tyre warms, the cavity air warms. If the air warms, pressure rises. So I added a cavity-air state. The model now had to estimate things such as: cold configured pressure cavity volume sealed air mass air temperature absolute pressure This fixed one conceptual problem immediately: A one-second powerslide should not instantly add several PSI simply because the exposed tread became hot. The energy first has to make its way into the internal tyre system. Which is much slower. Great. Problem solved. Except... 27. THEN THE AIR TURNED INTO AN OVEN I drove for longer. And discovered that the air would not stop getting hotter. Code: tread: reasonable core: reasonable air: still getting hotter PSI: still climbing me: ?????? The cavity air had several ways to receive energy... and almost nowhere sensible to reject it. I had accidentally built an oven. That was the reason the rim received its own thermal state. The cavity air could now exchange energy with a substantial metal thermal mass, while the wheel itself could reject energy toward the surrounding environment. Conceptually: Code: inner tyre ↕ cavity air ↕ rim ↕ environment That finally gave the internal air a chance to approach equilibrium instead of becoming an increasingly hot pressure cooker. Pressure behaviour became much more believable. For a moment I thought: Okay. Now the long-duration thermal model is fixed. It was not. 28. THE PRESSURE STILL KEPT CLIMBING With the rim added, the air finally had somewhere to cool. But during sustained driving, especially with repeated braking, I still saw something strange. Pressure could become too high. More importantly: the slow structural temperature kept creeping upward. If I simply kept driving for long enough, the tyre looked as if it were destined to overheat itself regardless of how steady the operating condition became. That did not make sense. Under a sufficiently steady condition, a real tyre should eventually approach some thermal equilibrium. So I traced every source injecting energy into the slow tyre state. One of them immediately looked suspicious. Brake heat. 29. THE BRAKE DISC IS NOT INSIDE THE TYRE Brake-disc temperature was influencing the slow tyre state too directly. The shortcut was understandable: Code: brakes get hot → wheel gets hot → tyre gets hot So approximating that as: Code: brake temperature → tyre core temperature seemed convenient. But it skipped almost the entire thermal path. A very hot brake disc is not sitting inside the tyre carcass. The brake assembly can transfer energy through several paths: convection into the local air around the wheel thermal radiation toward nearby wheel surfaces conduction through connected hub and wheel structure The wheel then becomes part of the tyre's thermal environment. So instead of: Code: BRAKE ↓ CORE the reduced-order model needed something conceptually closer to: Code: convection ↗ brake disc ─────────→ local hot air │ │ radiation / structural transfer ↓ rim ↓ cavity air ↓ inner tyre / carcass That distinction mattered enormously. The energy now has to cross several thermal resistances and thermal masses first. The rim warms. The internal air warms. Pressure changes. The inner tyre gradually experiences a different thermal boundary condition. The whole response gains delay and thermal memory. Excellent. Surely the long-duration overheating problem was now fixed. Nope. 30. THE TYRE STILL SLOWLY COOKED ITSELF WHILE JUST ROLLING Even after fixing brake-heat routing, sufficiently long steady driving could still push the internal tyre temperature upward too aggressively. So once again I traced the heat sources. This time the suspicious one was labelled: Code: rolling heat And the reasoning behind it initially seemed perfectly sensible. A tyre rolls. A rolling tyre deforms. Rubber deformation creates hysteretic loss. Hysteretic loss becomes heat. Therefore: Code: rolling → heat → core Right? Almost. The mistake was hidden inside that final arrow. 31. “ROLLING RESISTANCE” IS NOT A LOCATION INSIDE THE TYRE The more I looked into tyre rolling resistance, the more obvious the problem became. Rolling resistance is not a heater sitting in the middle of the tyre. A large part of the loss comes from cyclic viscoelastic deformation as different parts of the tyre enter, travel through and leave the loaded region. The tread deforms. The crown and belts deform. The sidewalls flex. The carcass strains. Different materials dissipate different amounts of energy. So the question: “How much rolling heat should I add?” was already badly framed. The better question was: “What part of this tyre is actually deforming, by how much, under this load and this pressure?” And suddenly several variables I already had became important for an entirely new reason. Vertical load. Inflation pressure. Tyre geometry. Construction stiffness. They did not merely affect handling. They affected how the tyre deformed every revolution. And therefore how much hysteretic energy it could dissipate. 32. ROLLING IS AN EVENT, NOT THE HEAT SOURCE The earlier model effectively treated: Code: rolling speed ↓ generic rolling heat ↓ core as one process. But “rolling” only describes what the wheel is doing. It does not tell me where the energy is being dissipated. A better decomposition became: Tread / contact-region deformation as tread elements repeatedly enter and leave the footprint. Crown and belt deformation as the loaded tyre structure changes shape. Carcass and sidewall flex whose magnitude depends strongly on load, pressure, geometry and construction. And, once genuine slip exists: road-interface sliding friction which is another heat source entirely. That distinction matters because: rolling is not sliding, and deformation is not automatically “core heat”. So rather than simply moving “rolling heat” somewhere else, the model had to stop treating rolling itself as if it defined where the heat belonged. Rolling is the event. Deformation and dissipation are the heat-producing processes. 33. PRESSURE AND LOAD SUDDENLY BECAME THERMAL VARIABLES TOO This was one of those moments where several previously separate systems suddenly became one problem. I already had pressure. I already knew vertical load. I already had tyre geometry. Originally those quantities mostly helped determine: Code: grip stiffness pressure state contact distribution Now they were also needed to answer: How much is this tyre actually deforming every revolution? Pressure changes structural support. Load changes deflection. Aspect ratio changes available sidewall compliance. Construction changes how strongly the crown and carcass resist deformation. So the rolling-loss model moved toward something more like: Code: speed + load + pressure + geometry + construction ↓ cyclic deformation estimate ↓ hysteretic loss ↓ thermal deposition into relevant tyre regions At this point several pieces of the tyre model that had originally seemed unrelated were beginning to become one network. 34. THEN HIGH-DOWNFORCE SLICKS BROKE THE CONTACT MODEL For many road tyres, the pressure/load distribution model was already working surprisingly well. Low pressure could make the shoulders work harder. Higher pressure could move the workload inward. Camber could create lateral thermal and wear gradients. Then I put the model on high-downforce racing slicks. And immediately found another problem. At very high vertical loads, a simple compliance-based model wanted to make the shoulders work enormously hard. Almost as if the tyre were becoming a giant soft balloon under aerodynamic load. But a modern racing slick is specifically engineered not to behave like that. Its belt package and carcass provide substantial support to the footprint. So another shortcut died. The next important distinction became: Contact load distribution is not the same thing as carcass flex. A shoulder can carry significant contact load without the sidewall beneath it collapsing dramatically. Likewise, a stiff low-profile performance tyre can reach saturation at relatively low slip angle without generating the same shoulder-deformation heating as a soft off-road tyre. So the model had to separate: Code: where the footprint carries load from: Code: how much the structure flexes while carrying it This remains one of the areas still being refined, particularly for high-aero Sport and Race tyres. 35. STANDARD, SPORT AND RACE COULD NO LONGER SHARE ONE CURVE By this point it became increasingly difficult to justify treating every tyre as the same physical structure with a different grip multiplier. So the major asphalt tyre families separated more strongly. STANDARD More compliant road tyres with: broad temperature tolerance larger useful slip-angle range progressive breakaway lower structural thermal sensitivity stronger tread-depth influence SPORT / SEMI-SLICK Performance tyres with: lower nominal saturation angle stronger construction sensitivity greater temperature sensitivity more precise response stronger high-load crown / belt support RACE SLICK Eventually divided into: SOFT | MEDIUM | HARD with distinct: working-temperature ranges cold response warm-up behaviour overheat response structural-temperature sensitivity wear behaviour post-peak behaviour A cold Hard slick should not merely be a Medium slick multiplied by 0.95. 36. COMBINED SLIP CREATED ONE OF MY FAVOURITE HANDLING TESTS A tyre has one contact patch. It does not receive one unlimited lateral-grip budget and another unlimited longitudinal-grip budget. So combined utilisation had to matter too. During testing with a rear-heavy RWD car, I repeatedly found a sequence like this: Code: corner entry → front begins to push small throttle → rear gains longitudinal demand rear combined utilisation increases → rear lateral reserve decreases careful throttle modulation → vehicle rotates slightly too much → progressive power oversteer modulate again → controllable yaw There is no command in the model saying: Code: rotate the car now It emerges from load transfer and combined tyre demand. That was one of the first tests where I stopped thinking: “Does this multiplier feel good?” and started thinking: “The car is explaining why it is doing this.” That became one of the main design goals. 37. THEN TOUGE DRIVING SUDDENLY STARTED MAKING A LOT MORE SENSE There was another point during testing where the model stopped merely producing nicer numbers and started changing how I understood driving itself. I was driving mountain roads. And suddenly the relationship between: Code: grip driving rotation controlled sliding drifting started making much more sense. Previously, it was easy to mentally separate these into different driving “modes”. You are either: Code: gripping or: Code: drifting with some vague transition between the two. But once the tyre model had a progressive brush transition, combined slip and a usable post-peak region, that distinction started to disappear. The tyre did not suddenly become a completely different object when it crossed peak grip. Instead there was a continuous progression: Code: mostly adhesion ↓ increasing deformation ↓ partial sliding ↓ saturation ↓ controllable post-peak sliding ↓ larger sustained slide And that meant many driving techniques which previously felt almost like separate tricks were really just different ways of moving the tyres through the same force envelope. 38. THE LINE BETWEEN “ROTATING THE CAR” AND “DRIFTING” BECAME VERY BLURRY Consider a corner where the front is beginning to push. Adding a small amount of throttle does not need to activate some special “drift physics”. It simply changes the utilisation of the rear contact patches. The rear tyres now have to provide: Code: lateral force + longitudinal force from the same finite contact patch. Their remaining lateral reserve decreases. The rear begins to rotate. Add slightly more throttle and the rear moves farther into saturation. Add more again and it becomes visible power oversteer. But there is no clean mathematical boundary where: Code: racing ends and drifting begins It is the same tyre moving progressively farther through combined slip. That made something about touge driving suddenly click for me. A small controlled slide can simply be an extension of cornering, rather than a completely separate driving state. 39. AND NOW THE DIFFERENT DRIVING STYLES HAD PHYSICAL TRADE-OFFS This also made the difference between various ways of taking the same corner much easier to understand. A clean grip line attempts to keep the tyres close to their most efficient force-producing region. A more aggressive rotation strategy deliberately consumes more of the rear tyres' lateral reserve in order to change vehicle attitude. A larger drift goes farther beyond saturation and trades some peak cornering efficiency for: greater yaw angle different vehicle orientation a different longitudinal/lateral force balance a different exit trajectory And because sliding now also has thermal history, the decision is not free. A short, mild excursion beyond peak may remain relatively benign. A large sustained slide generates much more actual rubbing velocity, much more frictional work and therefore much more thermal consequence. So: Code: small rotation ≠ long sustained drift even if both technically contain some tyre sliding. That was exactly the kind of distinction the earlier simplified model struggled to represent. 40. A GOOD TOUGE CAR DOES NOT NEED TO FEEL “SAFE” Something else became apparent. A car can be very responsive and still be controllable. Those are not opposites. If the tyres communicate load progressively, a car can rotate aggressively without immediately becoming random. Likewise, a car can have relatively modest peak grip and still feel extremely confidence-inspiring if the transition through that grip is readable. This made me rethink the assumption I had started with: Code: easy to control =============== arcade A more useful distinction became: Code: predictable vs unpredictable A physically progressive tyre can be demanding while still giving the driver enough information and enough remaining force beyond the exact peak to manage the car. And on a mountain road, where weight transfer, braking, throttle and rapid direction changes are constantly interacting, that difference becomes extremely obvious. The funniest part is that nothing in the code knows I am “touge driving”. There is no touge mode. There is no drift-entry script. There is no: Code: if mountainRoad then makeCarRotateNicely() The model only knows things such as: Code: vertical load slip state available friction combined utilisation temperature pressure construction Yet once those relationships became coherent, the driving techniques started making sense by themselves. That was another important milestone for me. The goal had originally been: “Make BeamNG feel nicer near the limit.” But now I was getting something much more interesting: The same tyre model could explain why clean racing, controlled rotation and drifting feel related in the first place. Instead of adding a special behaviour for drifting... I had accidentally made drifting feel like part of driving. 41. TREAD WEAR THEN CHANGED THE THERMAL MODEL ITSELF Once wear had become local rather than global, another question appeared. If half the tread rubber is gone... why should the tyre still have the same thermal mass? Why should heat travel through the same thickness? Why should tread compliance remain unchanged? So remaining tread depth became part of the physical model state. OUTER, MIDDLE and INNER can wear independently. As rubber disappears: remaining tread thickness changes thermal mass changes conduction distance changes temperature gradients change structural behaviour changes future wear behaviour changes The tyre you have after many laps is therefore not simply: Code: new tyre × 0.82 grip It is a different remaining structure inside the reduced-order model. 42. ONE OF MY FAVOURITE “OH... THAT ACTUALLY MAKES SENSE” TESTS One particularly satisfying test involved an open-differential RWD car. The inside rear tyre became lightly loaded and started spinning. Normally I would expect: Code: spin = lots of wear But because the wheel was lightly loaded, the pressure/contact model also shifted its working distribution relatively toward the crown. So the model naturally produced stronger middle-tread wear. There is no code saying: Code: if openDiffInsideWheel then wearMiddle() It emerged from: Code: low vertical load + inflation pressure + contact distribution + wheelspin + local abrasion That reminded me strongly of wear patterns I had seen on smaller RC tyres. And it was one of the moments where I realised the model was finally doing what I wanted from the beginning. I was no longer scripting the result I wanted to see. The relationships were producing it. 43. AND THIS IS WHERE THE HANDLING FINALLY STARTED IMPROVING The funny part is that the entire project started because I wanted the car to feel better. But almost none of the later work directly says: Code: make car easier to drive There is no: Code: ForzaHandlingMultiplier There is no rule saying: Code: if player oversteers then give more grip Instead, the tyre gradually gained: a more physical post-peak transition history-dependent sliding behaviour separate fast and slow thermal states dynamic structural response partial-contact-patch sliding native BeamNG response reconstruction dynamic B100 cavity-air pressure memory rim thermal behaviour more realistic brake-heat routing load/pressure-dependent deformation cross-tread load distribution construction-dependent saturation combined-slip behaviour local abrasion physical tread-depth evolution And the handling improved as a consequence. That was probably the biggest surprise of the whole project. The more I stopped trying to directly tune “good handling”, the easier good handling became to obtain. 44. REAL-TIME SIMULATION ALSO FORCED SOME COMPROMISES At this point the obvious question is: How much of this can reasonably run in real time inside Vehicle Lua? The goal was never to simulate every millimetre of a tyre. That would defeat the point of a lightweight community mod. So the model deliberately uses different levels of detail and different update rates. Fast states such as: slip utilisation grip correction surface / flash behaviour handling-critical structural response need to update quickly. Very slow states such as: cavity-air temperature rim temperature slow bulk thermal evolution do not need to be recomputed at the same frequency. Their physical time constants are much longer anyway. So the simulation uses a reduced-order, multi-rate approach: spend computation where the physics can actually change quickly. This is also why the model contains 36 bulk tread cells rather than hundreds or thousands. It is a compromise between: Code: enough spatial structure to explain the important behaviour and: Code: still being reasonable to run in BeamNG 45. VALIDATION — THIS SECTION IS STILL BEING BUILT Throughout development I have continuously used the same basic philosophy: Do not only test the condition the model was tuned for. Try to find the condition that makes it fail. That has included: steady highway cruising high-speed cruising and cooldown slightly over-peak understeer full wheel lock small longitudinal speed mismatch large burnout slip sustained drifting repeated circuit laps cold race tyres high-downforce slick loading extreme pressure cases repeated heavy braking camber-driven uneven wear open-differential inside-wheel spin progressive tread loss However, I am deliberately leaving the final quantitative validation results out of this first version of the report. The next step is to formalise these tests using: a deterministic offline reduced-order test harness repeatable BeamNG telemetry sweeps native tyre response measurements controlled thermal and wear scenarios Once those results are finalised, I intend to add a dedicated validation section with actual numbers rather than simply saying: “it feels good.” The wear model in particular is still receiving absolute-rate calibration even though the overall architecture and handling behaviour are already much more mature. 46. WHERE OTHER GAMES FIT INTO THIS Forza and Assetto Corsa are still useful during development. But they are not ground truth. I use them more like this: Code: observe interesting behaviour ↓ ask why it might happen ↓ search for a physical explanation ↓ build or modify the model ↓ compare again For example, Forza originally made me question whether a broad post-peak region necessarily had to be unrealistic. It did not provide the answer. Rubber-friction research did. Likewise, seeing similar thermal behaviour in another independently developed simulation can be useful as a sanity check. But if a research paper and another game disagree, the game does not win simply because it feels nice. Other simulations are useful references for questions. They are not substitutes for physical data. 47. WHAT THE MODEL LOOKS LIKE NOW Only after following all of those problems does the current model make sense. Per tyre, it now contains or tracks reduced-order approximations of: microscopic flash temperature fast road-facing surface thermal state rotating surface hotspot memory three transverse tread regions twelve depth cells per region 36 bulk tread thermal cells slow structural / CORE temperature cavity-air temperature rim temperature sealed-air pressure brake-to-wheel thermal coupling load/pressure/construction-dependent hysteresis native BeamNG tyre-response estimation dynamic B100 / brush saturation temperature-sensitive structural response pressure/load-dependent contact distribution high-load crown / belt support combined longitudinal/lateral utilisation local sliding fraction local frictional heating local abrasion independent OUTER / MIDDLE / INNER wear remaining tread-depth effects If I had started this post by listing those features, it would probably sound absurdly overcomplicated. But almost every one exists because a simpler approximation failed a specific test. 48. THIS IS STILL A REDUCED-ORDER MODEL I also want to be very clear about what this project is not. It does not have: manufacturer tyre test rigs proprietary compound data full carcass finite-element analysis real measured BeamNG contact-pressure fields full three-dimensional tread deformation complete engine-level access to BeamNG's tyre/contact model Many quantities have to be inferred. The model is therefore an approximation of physical relationships, not a claim to reproduce every microscopic detail of a real tyre. There are also areas still being actively refined, particularly: absolute wear-rate calibration high-downforce slick carcass / belt support rolling-hysteresis heat distribution specialised drift compounds very unusual modded tyre constructions non-asphalt surfaces extreme off-road tyres And if BeamNG eventually releases a native tyre system based on better measurement data, proper tyre testing and deeper engine-level modelling that makes this project obsolete... I would consider that an excellent outcome. I would much rather see the base game become dramatically better than preserve this mod's relevance by hoping the official tyre model never improves. 49. WHAT THIS PROJECT ACTUALLY TAUGHT ME The biggest lesson was that tyre behaviour becomes strange very quickly when connected physical processes are collapsed into unrelated multipliers. Pressure is not merely grip. Temperature is not merely grip. Slip angle is not heat. Wheelspin is not wear. Rolling is not a heat location. Brake-disc temperature is not tyre-core temperature. Surface temperature is not carcass temperature. Saturation angle is not carcass flex. Contact load is not structural collapse. And “more realistic” does not automatically mean “more sudden and harder to control”. The tyre is a coupled system. Change pressure and you may also change: Code: structural support deformation contact distribution saturation heat generation wear Change vertical load and you may change: Code: available force contact shape structural deflection hysteresis temperature wear Change temperature and, depending on where that temperature exists, you may change: Code: surface friction bulk compound response structural stiffness pressure abrasion Change tread depth and you change: Code: mass stiffness thermal gradients future wear That interconnectedness ended up being more important than any individual coefficient. 50. THE QUESTION CHANGED At the beginning I was asking: “How do I tune BeamNG's tyres so that they feel better?” Later I was asking: “How do I make the tyre behave more realistically?” Eventually even that changed. The question I am interested in now is: “What physical relationships need to exist so that believable behaviour can emerge on its own?” That is probably the best description of the project. WHY I AM POSTING THIS I am posting this partly to document the development process, but also because I would genuinely love feedback from people who know more about tyre dynamics than I do. Especially if you can identify: an assumption that is physically wrong a relationship that should be modelled differently research that contradicts one of my interpretations a test case that should break the model please tell me. Some of the largest improvements in this project happened because a result looked wrong and forced me to question an assumption I had previously considered obvious. I would much rather discover that something is wrong than protect a model simply because I spent a long time building it. And if BeamNG's tyre developers ever happen to read this: I am especially interested in how far these relationships could be taken with proper tyre-test data, direct contact information and engine-level access to the underlying tyre model. Because this entire project began with me impatiently asking why the tyre update was not here yet. Apparently my coping mechanism was to accidentally build one. PROJECT LINEAGE & CREDITS This project originally grew from: Luuk's Tyre Thermals and Wear Mod by lucky4luuk / Luuk. That project provided the original framework and several important existing concepts used as the starting point for experimentation, including tyre thermal state, pressure, grip modification and wear. The project has since been extensively expanded and reworked as the questions described throughout this post became more detailed. Huge thanks to Luuk for creating the original mod and making that groundwork available to the community. All underlying vehicle, wheel, node/beam and road-contact physics are provided by BeamNG.drive. Kagoni Tyre Simulation is an independent community project and is not affiliated with or endorsed by BeamNG GmbH, tyre manufacturers, research institutions or other simulation developers referenced during development. SELECTED RESEARCH DIRECTIONS The project has drawn primarily from research in areas including: rubber friction and flash temperature brush / Fiala-style tyre modelling thermodynamic tyre modelling temperature-dependent tyre characteristics contact-pressure distribution inflation and vertical-load effects rolling resistance and viscoelastic hysteresis brake / wheel / tyre thermal interaction camber and carcass deformation rubber abrasion and tread wear combined longitudinal and lateral slip Some particularly useful research directions and authors during development include work by: Farroni, Russo, Sakhnevych and Timpone on real-time thermodynamic tyre modelling Farroni, Sakhnevych and Timpone on physical tyre-wear modelling B. N. J. Persson on rubber friction and flash temperature research into tyre contact-pressure distribution under changing inflation and vertical load research into rolling resistance and internal viscoelastic heat generation work on combined brake, wheel and tyre thermal modelling work on tyre parameter identification and brush-style force modelling These references are used mainly to constrain physical relationships and model architecture. They should not be interpreted as claiming that the reduced-order coefficients in this project reproduce the exact tyres investigated in those publications. A more complete bibliography will be added together with the quantitative validation section. THE ORIGINAL PLAN Code: make the tyres feel slightly nicer WHAT ACTUALLY HAPPENED FH6 feels strangely good near the limit → why? → maybe harsh does not automatically mean realistic → modify an existing thermal mod → tuning numbers keeps failing → research post-peak rubber friction → “I’M A F***ING GENIUS XDDD” → wait, which temperature? → flash temperature → one thermal state is not enough → brush / partial-slip heating → start deliberately trying to break the model → give the existing CORE state a more precise physical meaning → multi-depth tread thermals → OUT / MID / IN wear → crash into wall → discover that THE WALL IS NOT THE FLOOR → pressure / load distribution → WAIT, I am still modifying BeamNG's native tyre underneath → reconstruct the native grip-slip response → JBeam structure inference → baseline / cold tyre model → inverse native-to-target correction → dynamic B100 → cold tyre paradox → wear needs real rubbing → surface heat destroys tyres too quickly → separate fast and slow wear authority → cavity air → air becomes an oven → rim temperature → pressure still climbs → brake heat path is wrong → brake → wheel → air → tyre → tyre still cooks itself while cruising → “rolling heat” is not a physical location → viscoelastic deformation → pressure + load + geometry + construction → high-downforce slicks break the contact model → crown / belt support → compound-specific behaviour → combined slip → touge suddenly makes sense → grip driving, rotation and drifting become one continuous spectrum → physical tread-depth evolution --- Post updated --- Kagoni Tyre Simulation PART 2 — WHY TOUGE DRIFTING SUDDENLY MADE SENSE Grip driving, drifting, tyre temperature, and why the fastest line may begin several corners earlier. This is Part 2 of my Kagoni Tyre Simulation development write-up. Part 1 explains the model itself — the post-peak friction problem, brush saturation, flash temperature, pressure, tyre structure, native BeamNG response reconstruction, wear, and the endless sequence of things I broke while trying to make it work. [Part 1 link here.] This part is different. It is an observation that came after most of that work. I started driving mountain roads with the new tyre behaviour... and suddenly I realised: DRIFTING ANGLE IN TOUGE DOES NOT DECIDE YOUR RACING LINE. HEAT DOES. Okay. That sentence obviously needs some explanation. XDDD 1. THE STRANGE STARTING CONDITION OF A TOUGE RUN A touge run does not begin like a circuit qualifying lap. There are no tyre blankets. There is no formation lap. There is no carefully prepared out-lap. You may have driven up the mountain mostly around: Code: 50–100 km/h and then stopped at the top. People are talking. Cars are sitting. The tyres are cooling. Then the run starts. So especially on a Sport or semi-slick tyre, the beginning of the run can happen with tyres that are nowhere near their most useful working state. They are cold AF. And that makes the first few corners extremely interesting. 2. YOU SLIDE TO GAIN GRIP Yes. That sounds completely backwards. You normally think: Code: slide ===== lose grip But that only describes the immediate force state. Sliding also performs frictional work. Frictional work creates heat. And if the tyre begins below its useful operating temperature: Code: controlled sliding → thermal energy → warmer tyre → potentially more useful grip later So you are not necessarily sliding because it looks cool. Quite the opposite. It is not cool. It is warm. This matters less on an ordinary road tyre with a very broad useful temperature range. But on a Sport tyre it becomes much more meaningful. 3. THE FIRST CORNER CAN ALREADY HAVE THE WRONG GRIP BALANCE At the start, you accelerate hard. On a RWD car the rear tyres immediately receive longitudinal work. So by the time you reach the first serious corner: Code: REAR: already received acceleration load and heat FRONT: still comparatively cold That can give you too much rear stability relative to front authority. Turn in cleanly and the car may simply understeer. But initiate some rotation through braking, weight transfer or — where appropriate — a brief handbrake input: Code: rear lateral reserve decreases → car rotates → front begins pulling the nose inward → rear receives useful thermal work You have deliberately changed both the immediate force balance and the thermal trajectory of the car. 4. THEN THE FRONT TYRES WAKE UP After several corners, the fronts have experienced: braking load cornering deformation partial slip road-interface work They gain temperature. Their available grip changes. And now the car at Corner 5 is not the same car you had at Corner 1. The question becomes: How much slip and throttle do I need to keep the FRONT and REAR grip balanced? And suddenly touge becomes much more difficult than simply: Code: take corner as fast as possible Because you are not only preparing the car for this corner. You are preparing it for the next one. And possibly the one after that. 5. YOU ARE CHOOSING FUTURE GRIP Brake. Rotate. The front pulls the car inward. Add a little throttle. The rear begins to catch. Reduce slip angle while progressively adding more throttle. The rear starts producing more useful force. That force shapes the exit trajectory. So: Code: braking → rotation small throttle → rear begins to catch reduce angle + increase throttle → rear gains force rear force → shapes exit You are not simply choosing: Code: how many degrees should I drift? You are choosing: How much grip do I want on each axle now, and how much grip do I want to have later? The angle is visible. The tyre state is the strategy. 6. WHY POWERSLIDING CAN RUIN THE SECOND HALF OF THE RUN This is where power sliding becomes very different from useful touge rotation. Suppose the rear is already sliding. Now add lots of throttle. Wheel-speed mismatch increases. Local rubbing velocity increases. Frictional work increases dramatically. Rear surface temperature rises quickly. For a while this can feel fantastic. Code: big angle lots of power fast-looking exit car feels alive Meanwhile: Code: rear tyre: THERMAL DEBT ACQUIRED Several corners later: Code: hot rear surface → less rear friction → same throttle creates more slip → more slip creates more heat → rear grip gets worse again And suddenly you have murdered the rear tyres one third of the way into the run. This is why: POWER SLIDING IS NOT TOUGE DRIFTING. Useful touge drifting is not about holding the biggest angle possible. It is about managing: Code: rotation + front/rear force balance + thermal state + future grip 7. SOMETIMES THE EXIT POWERSLIDE WAS CAUSED BY HEAT, NOT ANGLE This was one of my favourite observations. I would enter a corner with a controlled slide. The car felt balanced. Then I would add throttle toward the exit... and suddenly the rear would continue into a powerslide. My old explanation would have been: Code: too much entry angle But that was not always what had happened. Sometimes I had simply generated too much rear surface heat while rotating the car. So when I later asked the rear tyre for longitudinal acceleration: Code: same tyre + more longitudinal demand + hotter surface ============== less available rear grip The tyre kept sliding. Not because I crossed some magical drift-angle threshold. But because: I spent too much of the rear tyre's thermal budget before I asked it to accelerate. That changes how you fix the mistake. Instead of: Code: less angle the answer may be: Code: less rubbing earlier catch less throttle during deep slip preserve the rear surface 8. DRIFTING BECAME A WAY TO MODULATE GRIP A simplified model makes drifting look like this: Code: GRIP | | cross limit V DRIFT A more useful tyre model makes it continuous: Code: adhesion ↓ elastic deformation ↓ partial sliding ↓ saturation ↓ small controlled slide ↓ larger slide ↓ high-energy sustained sliding So drifting is no longer an escape from grip physics. It is one way of moving the tyres around inside the same force envelope. You can deliberately reduce rear lateral reserve. You can increase rotation. You can let the front pull the car inward. You can progressively catch the rear. You can trade slip for heat. You can trade heat for future grip. You can spend the tyre now. Or save it for later. 9. WHY NATIVE BEAMNG NEVER MADE THIS FEEL OBVIOUS TO ME This is also where I finally understood what had bothered me about the original simplified behaviour. Near and beyond peak grip, it often felt as though there were only two useful states: Code: HAVE GRIP or: Code: HAVE NOT Once the tyre moved sufficiently beyond the narrow useful region, it could feel as if it had already reached its heavily degraded sliding state. That leaves the driver mainly trying to stay inside a very small window. There is much less opportunity for: useful partial sliding thermal strategy deliberately changing front/rear balance using one corner to prepare the tyres for another That is not necessarily “more realistic”. It can simply be more simplified. A more detailed physical system can actually be more controllable because it contains more intermediate states. 10. THERE IS STILL NO TOUGE MODE Nothing in Kagoni Tyre Simulation knows that I am driving down Akina. There is no: Code: if touge then enableDriftPhysics() end The model only knows: Code: load pressure slip local rubbing velocity temperature available friction combined utilisation structure Yet once those relationships became coherent... the driving technique started explaining itself. The project began with: “Why does BeamNG feel so harsh near the limit?” Then became: “How should tyre grip actually transition?” And somehow ended with: “Oh. This is why drifting can be part of racing.” Instead of adding special drift behaviour... I accidentally made drifting feel like part of driving.
Thank you very much for this very insightful exposé. I'm glad to see many if not all of the grievances I have with the current tire physics mods available mentioned. You hit the nail on head when exposing how framing a physics question differently can affect one's approach to it and therefore the results themselves. You have very refreshing perspective, and seem to be willing to go the extra mile to make tires as a whole behave properly, not conveniently, which is what really made me want to read your entire post. If there is any way I can assist you in your endeavor, feel free to reach out through the forums' DMs, as I am more than willing to support your endeavor while we all wait for Calspan and the BeamNG team to be done with their work.
NEW UPDATE: RALLY ROAD BEHAVIOUR + BUG FIXES still in researching/development but new asphalt/gravel rally tire physics updates are here!
This looks epic, good job I think you should change the ai generated picture on the repo though, at first i thought it was another slop mod but a lot of work went into this and it deserves more attention
First of all, I really enjoy the mod, it creates amazing enjoyment and experience. I can't play BeamNG anymore without it, and I really appreciate the work you have done I just tried 1.4 luckily, I backed up 1.3, Tried them back and forth. 1.3 Handles way waaay better. Testing car bx street drift on steering wheel.
Thanks for the very useful feedback! I actually feel the same when I compared Sport and Standard tyres between the two versions again, and I found the reason why this actual bug makes the tires feel better. BeamNG uses Jbeam structures for the tyre models and most of the tyres could feel "too stiff" compared to a similar tyre at the same filled pressure irl, and I am currently researching in actual methods that could preserve that more progressive feeling of my v1.3.1 tyre model instead of inplementing it as a "bug" again. Please revert back to v1.3.1 for now, thanks!
heya, i got a couple of questions does it support career mode? is it better in terms of realism compared to luuks thermals and wear+ggt? does it support modded tires? i know these questions are probably already answered in the original post but its just too big for my attention span lol
Currently no career mode supports yet, modded tires works BUT might need individual calibration to feel more "correct" when using this mod because some of them can appear to be too "grippy" when near siding as my mod already fixes the "snappiness" of the native BeamNG tire. Realism wise it is extensively calibrated to real life values and compared against a lot of Assetto Corsa's V10 tire mods and my version strongly agrees with them in many aspects, so yes, this is a extremely dedicated and realistic mod in terms of thermals and handling wise. Wear rate is currently still too high and I am still calibrating it and comparing to other sims as reference, please look forward to updates! Mod link: https://www.beamng.com/resources/kagoni’s-tyre-simulation.39079/
i saw some of the argument that was happening here i don't know what to think for 1 it's cool n all and he did disclose it's AI but for the other side it's weird you be glazing ts just cause of them pfps n shit (i understood it as such) anyways maybe i'll try this when i get the time to do it
I want to clarify something here. First of all, the description is made to be 100% transparent of HOW the mod works and WHY it was built this way. I spent a lot of time drafting it myself and polishing it through AI as English is not my first language and I simply lack the vocabulary to write it myself. (I tried Google Translate and it was bad) Second, the article published in this thread is genuinely authentic to how I started modding and evolved the mod through explorations, researches, observations and calibrations, which is why I intended to share them separately as I wanted to separate the technical and personal sides of stuff, hence why this here existed. Everything here is as real as it is, though I admittedly used AI to help translate all of my stories and thoughts into a coherent narrative, it does not mean that I just put this through AI once and call it a day. I read thoroughly about the stuff that is written and edit them myself to the best that I could.
There is a massive difference between AI Slop, AI generated code that is made without effort and not thoroughly tested or looked through; and using AI to accelerate research and prototyping. There's plenty of examples on the repo of such slop, where things are clearly broken, not tested, or not working properly. This mod is not such a case. The author clearly has researched, tested it extensively, and made many iterations to get it to where it is. And I've got to say, it works damn well in my experience (although the wear still needs work, as the author has commented on). I think Razka has some inherent biases against this mod. They've worked on their own Tire Physics mod, and presumably put a lot of work into it, so it can sting when another mod is released that does something similar to what you've already put a lot of effort into, and it's a natural bias to believe that your own work is superior to someone elses. But coming into another mod creator's thread to pick fights and demean their work, especially claiming that their own mod is 'proven to be better', is just toxicity that helps nobody. The end product is the driving feel, comparing source codes alone cannot determine whether one mod is 'better' than the other. If Razka's mod feels better, naturally more people will use it than this one, and vice versa. Let the results speak for themselves rather
You hit the nail on head there, mods made w/ AI aren't the issue, it's mods where AI is doing the heavy-lifting that suck balls. It's merely a tool, and it's what you do w/ it that matters and decides whether it's "slop" or not. I could not care less if Kagoni used AI to help achieve the results that they did. Plus, this kind of work is not creative in nature, so why all the fuss if the end result is as great as it is?
If you find any bugs in the mod, please report it in this thread! I'll do my best to patch things up as I'm aware that this mod has not been tested on extreme edge-cases yet. Thank you!
