Greetings, motorists!
With the 0.28 Update, openable doors and panels were added to most vehicles in BeamNG.drive. Today, we would like to show you the work the audio team has done to support this feature.
When plans for interactive doors first came up, our initial reaction was, “Okay, doors can be opened and closed. How hard can it be to create audio for that? It’s just a simple opening and closing sound, right?“
Wrong!
The complexity of doors in videogames is often underestimated, but in BeamNG, this is amplified even further. If you are a frequent driver, you might have noticed how doors from different cars sound significantly different from each other. The type, material, size, age and condition of a door all contribute to its sonic identity, and all of that affects what kind of audio assets will be required.
However, simply creating a lot of content wouldn’t have been sufficient. Doors in BeamNG.drive are driven by physics, so factors like the force used to open the door, or obstacles that stop it from opening fully, would affect the sound. The same door from the same car can sound completely different, depending on characteristics such as closing speed, distance or environment. For closing intensity, we ended up using both various audio files and real-time physics control. But more on that later!
While our conversation so far has mainly centered on doors, BeamNG offers an extensive range of interactive elements. We also support openable hoods, trunks, props such as the BeamBox, and unique features like the tailgate and spare tire holder found in the Gavril D-Series. For each latch type, the closing assets are split in 2-3 different intensity categories (low-high or low-mid-high). To avoid repetition, every intensity category uses a set of 3-4 subtly varied audio assets, one of which is randomly triggered with every closing motion.
By now you might realize why supporting the latch system with audio was not quite as simple as we initially assumed.
Let’s do a simple calculation with the following presumptions: In BeamNG.drive, there are 30 vehicles with interactive latches, 3 types of latches (door, hood, trunk), 2 ways of interaction (open, close) and on average 6 similar sounding assets for every interaction. Admittedly these numbers are not 100% accurate: not all vehicles have hoods, and some have more interactive elements than others. Moreover, all hoods actually consist of two separate opening sound events: one for pulling the release handle in the cockpit and one for opening the hood panel. Still, the above presumptions are close enough for a rough estimate of the amount of required assets: 30 * 3 * 2 * 6 = 1080 individual sound files, just for latches! Since some of the content could be shared across several latch types, the actual total of used sounds is not quite as high - in the end we needed only 821.
Asset Creation
When creating the scrape audio system back in 2019, the key challenge was the implementation of sounds with our audio middleware FMOD. Just a handful of audio files are used for the scrape system, but the sound character continuously changes based on physics properties like speed, pressure, size or the material of the scraping parts. For the latches though, the most demanding and time-consuming task was the creation of the assets.
Although batch processing would have saved us a lot of time, it could only be applied to a few steps of the asset creation process:
- Mono conversion: all assets are in mono
- Sample rate conversion: all assets have a sample rate of 48kHz
- Loudness normalization: all assets are normalized to -24LUFS
- General EQ-ing: a 20kHz high-cut and a 30 Hz low-pass filter were applied to all assets
- General limiting: some very subtle limiting was applied to all assets
- Asset naming: all assets follow a similar naming convention
Ultimately, every single asset needed to be manually edited on a second run. This involved:
- Cutting: all assets needed to be trimmed to a desired length
- Fades: all assets needed to have a natural fade-out
- Individual EQ-ing: many assets required a manual re-adjustment of certain frequencies
- Individual limiting/compression: some assets required a manual re-adjustment of their amplitude
- Cleaning: some assets required a manual cleanup of unwanted clicks, crackles or noise
Why couldn’t this be done with batch processing? All assets of the same type (for example all 6 opening versions of the Bruckell Bastion hood) needed to have a similar length, volume envelope and sound character. In other words: individual assets that stood out too much had to be avoided. The source recordings were also made with different microphone types, from different positions and in different environments, so some recordings captured too much bass, others sounded too ‘close’ and others were too reverberant. This needed to be addressed by evening out certain frequencies or by applying compression and other forms of audio processing.
The tools De-click, De-crackle and Spectral Repair from the audio restoration software iZotope RX were particularly useful to reduce the amount of detail on recordings that were captured too close to the source. In BeamNG.drive, the player can interact with latches from arbitrary distances, but the audio system will always use the same set of audio files. Therefore, the assets needed to be generic enough to sound realistic no matter the distance - whether the camera is right next to a latch, or a hundred meters away.
Using the abovementioned tools, we managed to remove ‘close-up’ clicks, crackles, and rattles, and reduce ‘close-up’ volume or frequency peaks, without having to sacrifice the dynamic range that we would have lost with more conventional approaches. When the source material was sparse, we created new latch versions by putting together small waveform chunks from other audio files and/or by copying an existing version and editing the phase and spectrum. The difficult part when designing similar assets of the same intensity was to make them sound different enough to be slightly distinguishable, but not so different as to sound as if they belonged to another intensity category.
Implementation
Compared to other audio systems in BeamNG.drive, connecting the latch sounds with the game engine was relatively simple. One of our programmers provided us with a dynamic parameter to determine the force with which a door, hood or trunk is closed. This closing intensity RTPC (real-time parameter control) has a normalized range from 0 to 1. For every closing event, one number within that range is sent from the game engine to FMOD. A high value is transmitted when a door is slammed, and a low value is sent when a door is closed carefully. In FMOD, this number then changes the following sound parameters:
- Assets: low intensity audio assets from 0 to 0.3, medium intensity assets from 0.3 to 0.6, high intensity assets from 0.6 to 1.
- Volume: a linear volume increase of 4dB from 0 to 1.
- Pitch: a linear pitch increase of 3 semitones from 0 to 1.
- EQ (only for doors and trunks): a linear, subtle increase of very low frequencies from 0 to 1.
(The following video shows the behavior of the closing intensity RTPC in FMOD)
Closing intensity is the only parameter that is unique to the latch audio system. As with most other vehicle-related features, the sound of the latches also changes based on the following parameters:
- Distance (how far am I away from the door?)
- Direction (am I looking at the door, or is the door behind me?)
- Perspective (am I inside or outside the car?)
- Environment (am I inside or outside a tunnel?)
We obviously reduce the volume of a latch sound with increasing distance, but also gradually apply a high- and low-cut filter and increase the send signal for the environmental reverb. Based on the angle between the direction the listener is facing and the direction of the sound, a second dynamic high-cut filter is in place to faintly push the audio focus to what is in front of the camera, and to simulate the muffling effect of the human ears for sounds behind you. Yet another set of filters and a special reverb is enabled when the camera is inside a vehicle, to simulate the acoustic attributes of the cabin. For tunnels we apply a geometric reverb, also dynamically: The further you drive into a tunnel, the more reverberant the latch will sound like.
(This video demonstrates the broad spectrum of latch sounds in BeamNG.drive in various game situations)
Overall, we are quite happy with how the latch audio system turned out. That being said, we often find ourselves revisiting existing features, on the lookout for opportunities for further improvement. Certainly in terms of asset creation, additional work will be required for doors, trunks and hoods of upcoming vehicles. Stay tuned!
If you have any questions or feedback, feel free to share them in the dedicated forum thread.