Graphics, Sound and Network code from game
The main reason for choosing to build a simulator around a game was to take advantage of the audio and visual realism that is being developed for the consumer market and to inherit future developments in this area from a product that has to keep up with consumer demand. nVidia and DirectX can achieve more from a relatively low cost graphics card than even the budgets of an F1 team can from custom hardware. Similarly the network code, developed for internet racing, allows us to run multiple drivers on track together, together with other injected cars on the track following real-life telemetry. It also allows race engineers to view the simulation from their own screens and switch their viewpoint from the driver’s perspective to a bird’s eye ‘chase cam’ or from trackside cameras.
Vehicle Model
You have the choice of running your own vehicle model, developed in C, C++, Simulink1, SimMechanics, SIMPACK, Dymola, Modelica . . . in real-time within rFactor Pro, or developing a new model using rFactor Pro’s engine. This would involve describing every joint in the suspension – the hard-points and ball-joints for rFactor Pro’s rigid multibody model (including any variations that are allowed if there are multiple pickup options for wishbones, for adjustable caster, camber etc.); the masses and inertias for moving parts; spring and damper rates for ride and/or heave and bump stops, spring rates for roll bars or belleville stacks; there are several hundred options that are parameterized across the chassis, suspension, tyres, aeros, drive-train, brakes etc. – though we have tools that make this task less daunting than it sounds.
Should you run your own vehicle model then this will need to be in C, C++ or a tool which may be compiled. For example, we cannot run a native Simulink1 model as the Matlab interpreter is too slow, but we can run Simulink1 models compiled with their real-time workbench. All driver inputs and track surface detail would be provided by rFactor Pro, which would expect to receive back the current state of the vehicle: its position, orientation and other information that allow sounds and graphics to be rendered correctly (engine rpm, rad/sec for wheels etc.).
Individual aspects of the vehicle model may be overridden, so for example you could run with the rFactor Pro vehicle model, but use your own tyre model, or perhaps your engineers may develop a new system that was never envisaged by the rFactor Pro vehicle model: For example, perhaps you develop a completely new type of differential. We, or you, can use Simulink1 or C++ to add in a model of your new differential and the control strategies to drive it based on data available to the virtual ECU; maybe lateral acceleration, longitudinal acceleration, driven wheel rotational velocities and gear selected, or indeed any other ‘virtual’ sensor on the car. Your new model may publish its own telemetry channels, which will be added to the standard output at 100Hz.
Telemetry Out
There are over 150 channels of data, plus derivatives from the model, and being software, adding new ‘sensors’ or channels is relatively straight-forward. The data rate is 100Hz.
Telemetry In
When a human driver is on track, one or more AI cars may be injected, which we can optionally take control of instead of letting the AI drive. This is typically used to inject a ghost car that follows real-life telemetry for a lap or combination of best sectors. These laps may be from real-life telemetry, but they could be laps recorded in the simulator, perhaps by another driver. The upper limit is currently 72 injected vehicles, so theoretically we could run a very large grid alongside the human driver, should the data be available.
Audio video
The audio visual output from rFactor Pro can run through a standard PC LCD display, but it provides greater realism when output through multiple channels. Any odd number of screens / projectors may be used, 1, 3, 5, 9, 25 . . . to avoid a seam directly in front of the driver, though we now have technology to remove the expensive limitations of hardware warp and blend: Traditional warp and blend hardware, used to merge the seams, adds latency and reduces the effective resolution as it keystones and re-samples the video.
We can now perform the projection blending at source, transforming the video on the graphics card, colour-balancing the images at the same time - so the output to the projectors is already corrected and remains at native resolution. The useful life of the projectors is also extended, as we can recalibrate the colour balance automatically to compensate for the projectors ageing.
For cockpits with mirrors, separate channels can drive two displays either side and slightly behind the driver’s head which will be visible in each mirror. Additional network-connected PCs for the race engineer or other observers may view any car on track from almost any conceivable camera angle.
Control loading systems
The primary non-visual feedback to the driver is steering force. rFactor Pro comes with a sophisticated Control Loading System that allows modelling of variable power assistance, variable ratio racks, steering dampers and feeds the torque into an external motor or even into a USB connected wheel. Control inputs may be fed via the CAN bus or through A/D converters from the throttle pedal, a load cell in the brake pedal, steer angle, wheel mounted paddles, rotaries and switches. The CAN bus may also be used to drive the wheel’s displays and shift LEDs.
Motion platforms
We have experience of interfacing rFactor Pro to two of the major motion platforms. All the derivatives required to run onset cueing and filtered motion in 6DOF are available.
Overview | Benefits of using rFactor Pro | Using rFactor Pro with Simulink1