I'm not sure you really understand what you're seeing in ttool, and I'm pretty sure you're not familiar with the TGM file and the changes over time. That's fine, you don't need to be aware of such things to enjoy the driving, but you should probably avoid making statements about what was and wasn't happening before.
Just to add that the "New CPM" will become old in itself one day, as Home Users PCs become more powerful then ISI/Other Devs are able to develop and give us better Tire conditions, think of it like this: - Dev creates a realistic Tire - Gives it to an F1 Team with a Super Computer: i.e. vastly more powerful than your average Home PC - Eventually time passes and Home PCs get more powerful, the Dev is able to introduce this into their Game of us - Dev continues to create advanced Tire - Gives it to an F1 Team with a Super Computer: i.e. vastly more powerful than your average Home PC - Eventually time passes and Home PCs get more powerful, the Dev is able to introduce this into their Game for us - ...and so the cycle continues ISI cars were perfectly good before "CPM" came along, they continue to be improved with "CPM" and no doubt the next "CPM v2" will be a further improvement over what we have right now.
yes, the ttool did show that, but this it. it show no other physical and thermo dynamic properties distribution in the contact patch area. Among the Nodes definition 7 parameters, I found only one: AnisoCarcassConductivityMult, that seems suggest they did have some sort of CPM for themodynamics but it could be very simple one (since only parameter is used). but the tool itself shows nothing about that, not even temp distribution in the contact patch area. Among 35 parameters for node properties in the TGM realtime model, none of them is specific to contact patch area distribution. I think the whole contact patch area could be just treated as a single logical point. The outcome can be scaled in according to number of nodes expanded. In the 15 displays of ttool on their realtime model, none of them show contact patch area properties distribution. The tool may need to be updated to work with new CPM(?), who knows....
If you understood what the tire model lookup tables are for, you wouldn't mix thermal modelling with mechanical modelling. Therere are several reasons for that: - The thermal scenarios are very varied and depend on many other variables than tire load: speed, road temperature, sliding... The amount of simulations to be implemented would be unhandable for a lookup table. - the thermal model is probably very linear in terms of solver. There is no need to use a lookup table to handle it. -The higher precision of the contact patch should benefit the thermal model since a better distribution of tire loads across the contact patch where due to the difference in slippage between the different nodes that compose it, a more realistic heat generation can be calculated. -I don't know where they are, but for sure the thermal properties of the tire are defined. Thermal conductivity, specific heat and density are for sure somewhere. With all this I am not saying that the actual thermal model is perfect. It clearly has room for improvement. I think that the heat generation/dissipation is being incorrectly calculated. I am not sure how much of the heat generation is being applied to the tire when sliding. For sure part of it is going to the track. I would expect that the higher the tire temperature, the less percentage of the heat generation will go to the tire. Wet driving is where this inaccuracies are more evident.
One question for those that have been messing with the tire tool... I know that several load cases are computed in order to create the lookup tables. Does anybody know which are the dofs that the tool uses as entry variables? For an ideal model I would expect: - tire load: defined as 3 axes force components plus a torque in the ground plane - camber setting defining where the horizontal (contact patch plane) is located wrt the tire. - pressure setting. Those would be 6 dof which imply a lot of scenarios to be calculated due to the huge number of possible combinations. A non linear system requires individual calculations where you cannot make the superposition assumption which only requires the variation of individual variables to be calculated. The lookup table indexing system would be interesting to know how it works to interpolate among such a high number of entry variables. Enviado desde mi SM-G130HN mediante Tapatalk
Why? We all know the Heat Eq is nonlinear. In the sliding state, the rubbers in the contact patch are in non-eqqulibrium, this is why there is huge temperature diff between inner edge and outer edge of contact patch. The heat transfer along the lateral, say one-D in this case, yields like this: rF2 uses a simple solution, but still non-linear, so-called "WLEParametes" that gives a temperature "shift" factor. This Shift factor is non-linear to current temp, hence they insert this shift into their SldingAdhesionCurve as baseline shift in according with microparticles as for their SlidingMicro(Macro)DeformatinCurves. Per my reading, those curves seem not function of x (laterally cross contact patch), or maybe implicitly.
I don't know why you say that heat equation is non linear. The fact that the tire is not in thermal equilibrium and that it shows big gradients doesnt make it a non linear system in terms of a FEM solver. It is a simply a dynamic calculation where the conductive coupling between nodes remains unchanged throughout the simulation. m•C•dT = dQ where Q is the overall heat balance at each node. The fact that the heat generation (heat not coming from the conduction betwen nodes) will vary a lot depending if a node is in the contact patch and its relative sliding wrt the road isn't a problem since it is introduced in each step calculation of the realtime algorithm. To simplify what I wanted to express. The thermal state of the tire is calculated in the realtime solver that simulates the global behavior of the car on track. The tire deformation is taken from a lookup table since it would be impossible to include this calculation in the realtime solver. The algorithm that calculates the thermal state and the rest of aspects of simulation uses data obtained from the tire deformation lookup table. At the same time the input data to be entered in the lookup table are coming from the results of the realtime solver. This process is continuous since the situation is changing all the time. Enviado desde mi GT-I9505 mediante Tapatalk
Wow, I think I found someone actually knows this stuff. Thanks for your reply. I was thinking in other direction, in a general way, that thermodynamics for heat equation (partial differential equation) with t and x variables. Given a period time, heat transfer from point x0 to point x1, that solution is non-linear. I now understand you that each node is “fix point” treat as “close system”. OK, let me expand my understanding after reading what you just described and I like your comment on , and along with my new question. To calculate Temperature (T) (by "Solver"-- a set of linear equations for InternalGasHeatTransfer, ExternalGasHeatTrnsfer, and GroundContactConductance), we need to know how much Heat (Q) transferred, which requires knowing how much energy being lost by friction (E): T <-- Q <-- E The E is calculated with WLF friction curves, which contains two parts: SlidingAdhesionCurve and SlidingDeformationCurve. The SlidingAdhesionCurve part depends on temperature too (function of T), but SlidingDeformationCurve is not. So the friction of SlidingDeformationCurve can be calculated with inputs of lookup table only (tire physical properties). But friction of SlidingAdhesionCurve part needs to have temperature T input. So here how is a Self-consistent “solver” doing I can think of (please correct me if I am wrong on this): The Solver start with starting temperature T(s) and uses a set of steps to calculate the SlidingAdhesionCurve, those initial (or start) values defined as (per their tTool doc): • AbrasionCurveWLFStartStep • AbrasionVolumePerUnitEnergy • DegradaitonPerWearFraction With the initial calculated friction lost energy E, the Solver yields temperature T initially: E --> Q --> T Now comparing the result T with initial input T, if there is a diff, then Solver will use the new T as input and step up with above parameters to calculate again. The rF2 tyre tool paper states max steps is 32, which means Solve can go through this process up to 32 times, or until there is no difference between input T and output T, or the difference is less than a certain defined range. You did not mention the “objective” of the Solver. I think the “objective” of the Solver is what I just described above. Is this correct? Of course this is just a single point at particular time t. The whole process will continue since this is realtime, as you mentioned.
Let me answer to your points in a general way from what I understand the physics engine does. There are several approaches that can taken when simulating things. So only the ones who programmed the tool could give more detailed explanations. Part of my job is to help developing industrial simulation software where thermal calculation is involved. Glass container manufacturing industry to be more specific where the temperature of the moulds (working at 500 °C) that form glassware needs to be calculated and controlled. Getting back to topic... From what you have explained, I understand that temperature works as an input to loookup for those sliding coefficients and several other parameters. Heat generation coefficients could also be seeked at those lookup tables to implement them into the real time thermal calculation. The amount of heat generation from sliding is something that depends on what is happening at the contact patch. There are 2 main situations: - There is a global sliding when the whole tire is sliding due to blocking the brakes, spinning... This causes a massive heat generational usually flatspotting. It just needs general tire load, sliding distance and friction coefficient to calculate the heat generation. - Local sliding when the wheel is rolling. In this case the heat generation is caused by the local sliding that occurs at some points of the contact patch. Due to the width of the tire, when turning, internal and external parts get some relative displacement which causes heat by friction. This relative displacements and load values can be calculated by the ttool program and later be used in the realtime calculations by seeking them at those lookup tables. In both cases a percentage of that heat will go to the track and the rest to the tire. I don't know how this ratio is calculated but it is for sure very important. A better answer could be given by ISI but in this case it would imply giving information about the simulation strategy they follow with the tire model. This is something that makes the difference between rF2 and other sims so I doubt they will go into details about it. Enviado desde mi GT-I9505 mediante Tapatalk
Hi Euskotracks: You responded to me on other thread, that got be deleted. I did not get a chance to reply to you. I thought I owe you a reply. That thread went too bad, and many troll and BS attacks. Hope OK here I response on your concerns of “real-life data on sliding state”, “flatspots”, “black art”. I drove the Corvette again today at only about 80 mph and purposely did a spin-off over sideway. My DD steering wheel vibrates pretty strong as well as my motion rig shakes madly. As I learned from that thread this could be caused by “flatspot” tire(s). I never had experience with those real race GT cars on track so I could not say either. But I did own couple sports cars. So I have my reason suspect the rF2 tire damage model. As some one argued that it is not “damage”, is part of tire wear. That is fine for his personal view, but to me it is “damaged” since I could not perform “normal” driving. I have a long time disbelieve the “realism” of rF2 in sliding state. Probably most sim players out there and real life drifters would agree. I always praise rF2 realistic grip state as the best sim around I can tell. So, I just do not have that confidence on “tire damage model” on sliding state. I suggested a tunable option to turn ON/OFF the “flatspot” feature on single play mode. That got flaming in that thread. I did not enjoy at all. In terms of “black art” and “real life data” etc., I took the words from him (see start at 20m): Bye
It does seem to me, that tyres in some mods flat spot similarly on pavement, grass, dirt, etc. I wonder how appropriate that is given the difference in frictional interface between the tyres and the various driving surfaces?
Grass and dirt are not properly implemented in rF2 yet. Been discussing that for three years. Check your tire temps when you "skid" across (even wet) grass. Some tires flat spot very easily (F1), others not at all unless you do a 1 km long skid (historic F1). The implementation is reasonably realistic, so if you don't want flat spots, don't drive in a way that wrecks tires. I always use 100% realism settings, but I would agree that if someone reduces the damage multiplier, the flat spotting (or lack thereof) should correspond to that. I would not be surprised if ISI failed to link those two (yet).
You should not believe everything you watch from YouTube. I still remember codemasters developer's diary with I can't remember which F1 driver saying how awesome it was. I don't know if the guy of Kunos is trying to justify something or what, but I can tell you the following: The data coming from telemetry do not stop working when the car slides. None of the sensors do. All the available data for normal rolling condition will also be available for sliding condition. There are tons of data on abrasion on tyre compounds and tire models. A quick search with Google will show you. As said. There are also tons of data for sliding friction test which are the easiest to perform and monitor under laboratory conditions. The reason why the previous thread was deleted is because all the crap you wrote, where you not only showed that you had no idea how to manage tires but also about how rF2 tire model works. Enviado desde mi GT-I9505 mediante Tapatalk
There is decades of literature on the subject, it's not a black art if you take the right approach. Assetto Corsa uses an ad hoc empirical tire model based on a slip profile. It takes different input data compared to rFactor 2's physically-based FE tire model.
As per your reference "black magic" is more appropriate term for what rF2 uses. AC is more simple in this regard and there are less ways of doing it wrong, but when both are done very well AC won't be as good as rF2.
Reproducing realistic vehicle dynamics in a highly dynamic and complex/variable environment ,such as when being driven hard around a series of straights and bends, is a black art. If it wasn't, driving every sim would be a super close experience to the other and it is nothing but the opposite of that.
Something being difficult might make it seem a 'black art', and we should never forget you can't simulate this stuff with complete accuracy, but at the same time 'black art' makes it sound like it's all guesswork. The OP is specifically referring to a completely sliding state (lockups etc) as being a black art, when as has been explained a few times now it's actually one of the simpler things to test. The OP is obviously also still very reluctant to accept that flatspotting isn't some sort of 'damage' separate to other tyre wear, when it seems apparent that tyre wear can lead to flatspots which behave in a quite realistic fashion for the same reason real flatspots behave the way they do - the fluctuating load partly due to the flattened area coming into contact with the road surface and the unbalanced weight of the tyre creating oscillations and associated load variations. The first was in rF2 from day zero as part of the tyre model (therefore wear causes flatspots, not as separate effects), the second was more recent and makes very old tyres unrealistically harsh when flatspotted because the abrasion rates tend to be a bit high, causing extreme weight imbalance.
And it is for professional simulators. Many of the limitations we have are related to hardware. Remember that simulation needs to be done in REAL TIME which is a HUGE restriction. The different approaches taken to simplify an otherwise impossible to calculate model explains the differences between sims. You should know that some simulations take days or even weeks to simply simulate some seconds. The available data to fine tune parameters is also an issue. Do not expect real F1 teams spending millions for not having something that is realistic enough to be valuable. Simulation has accuracy problems in all fields of physics. But that doesnt mean it is black art. Enviado desde mi GT-I9505 mediante Tapatalk
