rFactor 2 – Physics Behind The Scenes
Image Space Incorporated has released an interesting article, showing how the team acquires and works with real-life data as part of their physics development process:
How do we get shape and construction information of the car?
No two real-life race cars are built exactly the same, no matter how hard they try, so the best way to ensure an accurate simulation of all cars of that type, rather than one example car that could have fundamental differences to every other, is to go straight to the designer. By building cars for the software as they were intended to be built, you actually have a more realistic example of all the race cars of that type which were built, rather than one example of its differences.
The most simplistic method for building is from a designers blueprint drawing of four angles: Front, top, side and back. Everything is at the same scale, without perspective, and can be used as a background image of those angles during the modeling process. This is perhaps the least accurate of the methods we use, but is quite common for a lot of the older cars, which were designed and built before computers were widely used. When working from drawings, we often have to gain access to these cars to confirm some details. They often lack information on the internal workings of the car.
Similar to the example above, some modern car designers provide us with ‘digital blueprint’ files which have the cars in the form of vector shapes. Like the blueprint drawings, these have the same four angles shown, but can be zoomed in for greater accuracy during the model building process. For this example, and the one above, we build the model by tracing 2D shapes in a 3D space. While this can be very accurate, it relies heavily on the skill and patience of the person we have building it.
A standard vector blueprint layout.
The most accurate form of data, and the easiest to work with, is modern 3D data. This comes directly from the designer and allows us to trace the 3D shape in 3D space, giving amazing accuracy in our model when compared to the original design. A major benefit of 3D data is that it may include the internal portion of the car, and this ensures greater accuracy when developing physics. The 3D data we receive is often too high quality to be used in a retail software environment, and that is why we are still using it to trace the shapes for our own model.
3D Model of rear end, after using designer 3D Data.
How do we get data on vehicle physics and car setup?
With every car we build, we try to work with the designer or someone who had direct involvement with the car in a competitive environment. There is a lot of trust required from manufacturers and teams when sharing information, even when they are helping us with a car no longer in active competition.
The most common form of technical data we get is a ‘car manual’ from the manufacturer. These are the same manuals provided to racing team engineers to help them understand, setup and maintain the car they have purchased. In most cases these are quite detailed, but may lack important information that usually we can ask the manufacturer, or a team we have made contact with.
Data can sometimes be calculated using common sense. A crude example could be the exact weight of a brake disc, where if you know the material, you approximately know the density, and together with the dimensions you can approximately work out the volume, which allows you to calculate its mass and inertia.
Unfortunately, there are times when both the manufacturer and any teams using their vehicles are unable to help us. In those situations we can draw on experience we have building cars of similar construction, we can search in literature or archives (depending how old the car is), or we can use our own in-house physics simulator and design tools.
Our in-house physics development tool, which most PCs are not powerful enough to run.
The goal of a simulation is to simulate the real world as accurately as possible, our in-house tools help us check the data we are given is correct, and is how we plug any gaps in that data. We can run full physics simulations, and this allows us to complete both the most complex and simplistic tests we need to, all within real-world constraints.
In some cases the computations from our tools are too complicated to be run in real time on current home technology, but the attributes of vehicle dynamics are now fairly well understood, and anything that has a significant real world bearing must be simulated in some manner, even if it is using a simplified model (creating the same results) within retail software. As we go forward, and technology advances, those simplified models can become more and more advanced, and therein lies the benefit of ongoing software development over boxed products.
The most difficult data to acquire, is tire data. Many teams work under a non-disclosure agreement with tire manufacturers, and this means we occasionally have to purchase and test tires ourselves. We also use our own tools to verify any information we are given, or test various scenarios to build our own data.
TGM Tire Testing Tool.
How do we verify what we have in the software?
A lot of theoretical work and testing is required using our tools before anything is driven. When we reach that stage, and all the data is plugged into pMotor engine, other tools can be employed, in what is more of a verification stage than anything else. Methods such as video overlay, telemetry and driver feedback are used to further refine the vehicle. It is at this point where any discrepancies should become clear and the causes investigated.