beamNG how trustworthy is this simulator

I would like to see you speak polish dude. Not everyone is a native speaker

 

Before starting, a disclaimer. We do not claim that BeamNG is suitable to be used for any "serious" engineering, or other purposes, where lives or money is at stake. There are other (non realtime) simulation software packages that are created specifically for these purposes.

Having said that, i want to say that under the realtime constraints that we are working under, we are doing our best to keep the simulation fidelity as high as possible.

Right now, the simulation works by calculating at 2000 physics steps per second. The 2000 steps number, is the same as what some of the *non realtime* movie SFX physics simulators use. The more steps that a physics simulator does, the stiffer the materials that it can simulate in a stable manner. 2000 steps, is enough to approximate materials that are used in normal cars (but not exotic materials like carbon fiber).

For each step, we do the standard (for physics simulators) integration - force calculations - collision detection processes. All of these steps are using the correct physics equations. For example, to deduce the equations for material deformation i had to read through a lot of papers from the civil engineering, and other relevant, fields.

We try to avoid any physics simulation "cheating" as much as possible. For example, most of the realtime physics simulators play fast and loose with friction, for example by increasing it as much as possible to stop the objects early so they'll be able to sent them to "sleep" (stop calculating them completely). Another "trick" that other realtime physics simulators do with friction is that when an object is stopped, they "glue" the object to the ground by "freezing" its position completely. In our case, we don't do any tricks at all. When an object is stopped, it is stopped by having the friction forces continuously keeping it still. We also try to use (friction and other) parameters that are taken from real engineering tables.

Concerning collisions, most of the realtime simulation engines try to reduce their collision processing workload using a number of tricks, like skipping calculating collisions on some of the physics steps, or doing the collisions on a bounding box. Because we wanted to be as accurate in collision processing as possible, we had to develop an extremely fast collision processing algorithm that is able to calculate the collisions in all of the physics steps, using the same physics skeleton that the rest of our physics also uses. This is an extremely hard thing to do, and most probably we are the first ones to do that and still remain realtime.

For the next update (sorry it is taking that long), we wanted to make sure that the physics simulation is as correct as possible. So i'm re-checking and re-deriving (by hand) all of the equations of the core to make sure that they are correct. The most visible problems that this checking process has uncovered, are some problems with the brakes/parking brakes and another problem concerning "ignored" collisions (the major cause of the vehicle "shaking" after a crash). These, and a lot of other not so visible problems, have been fixed.

All of the above physics engine work, would be wasted if the vehicles weren't designed correctly. The way our physics works, requires vehicles designed in a realistic manner. We are lucky that our vehicle designer (gabe), is a perfectionist when he designs his vehicles. This isn't an easy task, because if you want a simulated vehicle to behave like a real one, then you have to design/construct it like the real one. This means that the weights of the parts need to be correct. The suspension needs to be of the same type and configuration as the real one's. Think of how many different things a real vehicle is composed of, and you'll realize the amount of effort that is needed to recreate it in a virtual setting. If there are "flaws" in the design, then weird things happen. Like the extreme wheel vibration that we had some time ago, because of the gyroscopic effects caused by the unrealistic weight distribution of our simulated wheels.

Best of luck with your Master Degree defense.

Edit: For an example of how far we are willing to go concerning simulation fidelity, look into "drivetrain.lua" and try to deduce how fuel consumption is calculated...

 

RoR's dynamic collision subsystem was coded by me.

If RoR's collision subsystem is thought as generation 1, the one that is used in the released BeamNG, is generation 3, and the current one (in development) is generation 4.

To give you some idea of the differences between generations. The difference between generations 3 and 4, is that in generation 3 the collision subsystem could scale up to around 3-4 vehicles. Generation 4 can scale up to around 7-8 vehicles, while at the same time being more precise than generation 3.