Sneak Peek: Tire Physics Development

To keep expectation in check, I'll repeat that this is not something we'll be looking at in the short term. We need to focus our available dev time in what we feel matters the most. The lack of debeading is very secondary compared to improving the overall tire behaviour. Our tire testing data also does not include debeading scenarios, so if we ever work on that, it would be unrelated to the data we're currently gathering.

Yup, as others mentioned, this is not necessarily the case: we've already done tests with higher and lower amounts of nodes, and the results are not as simple as one might expect.

The smoothing is not happening necessarily in terms of 3D node positions (tho the positions may slightly change too). Rather this is about how the collision detection system works internally, as well as the subsequent physics engine calculations. And in addition to that, a smoother result happens due to the higher sampling rate at high speeds (more vehicle speed = more data per second = smoother overall result).

Gyroscopic effects stabilize a wheel in the plane of rotation. This is not "in consideration" so much as it's an inevitable part of our soft-body physics engine: we didn't implement this explicitly, it simply happens. Just like the dzhanibekov effect happens naturally even though we didn't intentionally implement it. And probably more effects that we never considered or we may not even know about

All these "effects" of course will play some role in the general vehicle behaviour, and luckily we don't need to worry about them like other physics engines may have to.

Very roughly it's... around 3 people who sometimes do work on tires, I guess. They are not focused exclusively on "tires" tho, tires are just one of their numerous areas of work.

Grip levels are not tuned for FFB feel. That would be similar to modifying earth gravity in order to "improve" vehicle handling... not only would that be horribly wrong, but would likely lead to an explosion of unexpected issues down the road, each issue requiring even more horrible hacks, and so on. We prefer to do things "right" from first principles (to the extent that we can, being a computer simulation running on regular computers in real time).

Funnily enough, most people ignore this, but those behaviours also happen in real life to a lesser extent. They can be quite dangerous, and are the reason I often remove the ABS fuse in trackdays for my own safety (specially in tracks where wheels may lift off the ground, or if I'm drifting in rainy days). The underlying reason for these issues (both IRL as in BeamNG) is that we use realistically constrained sensor data, rather than magic omniscient game data (like our 'Arcade' ABS can use, and which avoids entire categories of ABS issues).

For example, we have no clue what real speed the car is travelling, neither in real life nor in beamng. We have to work with educated guesses, based on analysis/fusion of various data streams (like wheelspeed sensors, accelerometers, etc). Normally the guesses are quite accurate, but sometimes it's not entirely right, or it can be completely wrong.

As for why our ABS replicates IRL issues but sometimes they have a greater effect, it's simply manpower: we only have 1 person who works on these systems (as part of their other numerous tasks!), while real manufacturers have the budget to contract companies with entire divisions dedicated to engineering and selling these modules.