In this series, we’ll have a look at how to set up a sound design for a simple loop-based car engine using Wwise Authoring, accompanied by appropriate amounts of related audio and automotive geekery! 

If you aren’t a gearhead, fear not; neither am I. Despite the talks revolving around the gas-guzzling internal combustion engine (or “I.C.E.”), the workflow can be applied to any similar design. That is, where you need to maintain consistent pitch tracking over a range of sampled assets and control this pitch using in-game parameter data. We’re really just talking about a large and very complex wind instrument. Air goes in, air comes out.

On the other hand, if you’re just starting out with automotive sound design, or looking to learn how this very traditional method of implementing car engine sounds in games is handled in Wwise Authoring, then what I’m about to share will be right up your alley!

Over this part, we’ll focus on understanding key engine simulation concepts, parameters we need for our design and how they work. Finally, we’ll go through some pointers for creating loop assets specifically for this use.

Pictures used in this article are taken from source recordings or in-game assets used in Wreckfest, a banger / folk racing video game developed by Bugbear Entertainment and published by THQ Nordic. 

Why Loop?

If you know the least bit about car audio designs in games, you might be quick to mention granular synthesis and its superior quality over loops, for said designs. So why bother with loops if there’s something better?

Even if granular synthesis often yields better results with less design setup work than loops, it rarely is a turn-key solution alone for lively designs and interesting sonic details.

Maybe you need to create a light-weight version of a complex granular synthesis design, to perf-optimize for where processing overhead has priority over fidelity or sound reproduction quality... Say, when going cross-platform from consoles to mobile. Or maybe you want to add some texturing over a very specific range (or combination) of parameter data, where running an instance of a granular synthesis plugin would be overkill. Or, as is often the case, you may not have the budget to license as many 3rd party tools as you’d like, or have the code muscle available to cook up a custom tool for the project.

Regardless of the design being based on loops, granular synthesis or whatever (even subtractive synthesis), each of these tools have their use. It’s our task as sound designers to figure out which of them serves the purpose best.

Most of the time, of course, the best designs occur where techniques can complement one another.

Basic Engine Parameters

So, to configure the design for our engine, we need to have an overall understanding of how an I.C.E. works together with the drivetrain, to propel the car forward; Which key simulation parameters we need to control our design and how they work.

In Wwise, these parameters are set up as RTPCs that are linked to appropriate physics simulation data on the game engine side. They are:

1. Rpm, how fast the engine is running (or turning);

2. Load, the type and amount of work the engine is doing; and

3. Throttle, user input to regulate the amount of work the engine is required to do.

Physically, a throttle controls the amount and mixture of air (intake) and gasoline flowing through our wind  instrument. With complex engine simulations there can be more parameters, but this set (of three) is what’s needed to simulate the basic engine sound behaviour.

Next we’ll have a look at how Rpm and Load work. If you’re familiar with these, feel free to skip over all the way to asset creation.

Turn, Rotate, Spin, Cycle

Rpm, short for Revolutions Per Minute (or cycles per minute), represents the amount of full 360-degree rotations that the crankshaft of the engine would turn during one minute, if steady Rpm was held. For the average consumer car with a four-stroke engine, the actual Rpm range could be, say, between 900 to 6000.

The upper limit of this range, commonly referred to as ‘redline’, defines the maximum Rpm at which the components of a particular engine are granted to operate without breaking up. Most I.C.E.’s come with some type of rev limiter that will prevent the Rpm from exceeding redline even if the combination of Load and Throttle would allow exceeding it.

One RTPC behavior to keep in mind here is that if the RTPC value fed by the game engine to Wwise exceeds the min-max limits of the Authoring object, this can cause our engine sound to stop. Since Wwise Authoring objects do not clamp the value, this needs to be implemented on the game engine side.

The picture below shows one example engine from Wreckfest, where Rpm is used to automate Voice Volume of a Blend Track. For now, just admire the near-smoothly looping screen capture I made. We will get back to this automation later on with some hands-on examples.

For the RTPC object in Wwise, the Rpm range is commonly configured either as actual, normalized, or actual converted to Hertz (Hz). The choice between these three depends entirely on the use-case.

The normalized Rpm is the actual Rpm scaled to a percentage-based range, say, with parameter data going from 0 to 1, or 0 to 100. These min-max values represent idle and redline Rpm of the engine, respectively.

Using such a range helps to disconnect our design automation from the actual Rpm. Should the actual Rpm range change on the game engine side, any previously configured Wwise automation would still work within the min-max boundaries. And this also makes our design more copy-paste compatible over a larger set of vehicles.

As for actual Rpm converted to Hz (Hertz), we know that audio tools are primarily Hz-based, as in cycles per second rather than cycles per minute. Depending on the design you’re working on, any Hz converted parameter data readily provided by the game engine can greatly reduce the time you spend configuring designs in Wwise. Trivial for (cue a dramatic stinger) the Wizards of Code (ta-dah!) to set up too.

Nonetheless, working with vehicle sound designs you often come across the need to convert between the two units. To go from Rpm to Hz, divide by 60; and vice versa, multiply by 60.

Load “Engine”,0,1

To understand engine Load we need to also consider the drivetrain of a car. This is the chain of parts that connects with the engine (via a clutch), to transfer the engine output power (torque) all the way to the road surface. Drivetrain also affects engine load via physical effects like tire grip.

Similar to normalized Rpm, Load parameter data is best off for audio design use, when scaled onto percentage-based values. Here the range commonly goes from 0 to 1, or from -1 to 1. Load tells us whether the engine is:

1. Applying torque; or

2. Resisting any existing torque; or

3. Just turning by itself.

In game audio designs, these are referred to as on-load, off-load and neutral load. The harder the engine is working to accelerate or decelerate, the higher the load value. The three load states work out as follows:

1. On-load occurs whenever any throttle is applied. A burning mixture of air and gas flows through the engine. If the clutch is engaged, the engine is applying its torque to overcome the resistance of the driveshaft. As in, either to accelerate the mass of the car to (or to maintain it at) the set speed.

2. Off-load occurs whenever no throttle is applied, but Rpm is above idle. Air and gas flow are cut off and the engine is passively turning against either its own resistance (clutch disengaged) or that of the drivetrain (clutch engaged).

3. Neutral load occurs whenever the clutch has been disengaged and engine Rpm has dropped to its idle value, regardless of whether the car is standing still or in motion.

Neutral load is also referred to as idle load. Note that "neutral" doesn’t mean 100% disabled (as in, "a Norwegian Blue", bereft of life, resting in peace, etc.) but rather the minimum power output that the engine needs to deliver to sustain its lowest configured running state (idle Rpm).

In audio designs, the on-load and off-load sides are commonly handled with unique assets for their distinct tonality. These tonalities depend on a larger set of physical parameters of the engine, drivetrain and exhaust configuration.

From Recording to a Loop

Coming up with a set of prepared, design-ready loops can require quite the range of tools and experience on how to operate them. From recording hardware to an audio editor, a DAW environment with plugin effects and synthesizers, etc.

Take a task like recording a car for example: If you’ve ever done any studio engineering work, one close equivalent to recording a car would be a drum kit. Not that the kit is moving at high speed, but it needs a multi-mic setup to capture detail and can output sound pressure levels over a wide dynamic range... And become extremely LOUD in the process! Even selecting which mics to use and how to position and angle them for this use is a form of art on its own.

Considering all of the above, it’s quite too much to include a step-by-step tutorial here. But I can still present some generic guidelines to help you get started with editing. There are a few links at the end of this post that will help you expand on some topics.

Let’s assume you have some vehicle recordings. To flip those into assets for a loop-based engine design, each asset you make needs to:

1. Maintain as static a pitch as possible over the length of loop (= steady Rpm);

2. Come with a known ‘natural’ Rpm value (= f.ex. at which Rpm the asset was recorded); and

3. Loop seamlessly.

Additionally, you want to try to edit assets so that their starting phase remains as consistent as possible over the full set. The actual engine cycle (when a cylinder fires up) is often clearly visible in the recorded waveform, and the starting phase of this cycle should be maintained between assets whenever possible. Before you start cutting, look through the detailed waveform of the entire recording to get some idea of the cycle shape and its change over Rpm for that particular engine. See if you can isolate a single cycle at any Rpm.

When creating sets for on- and off-load, the natural Rpm of overlapping assets between these two layers don’t need to match. This Rpm/pitch matching we will deal with in Wwise Authoring.

A Detail to Split for

Talking about on- and off-load sets, sometimes you might have separate engine and exhaust takes to work with. In this case, making separate unique Load sets for both (as in, four sets total) will allow your design to connect better with the game world simulation, all to increase player immersion.

With assets split this way, you could control things like tone and mix balance of each group separately based on camera position, angle and distance, or even obstruction. Or add Wwise plugins to process the recordings separately.

One real-world example is when you circle around a parked but running car. Its sound can change a lot depending on your position and distance to the car, and is primarily attributed to the relative location of the exhaust pipe(s). If on the opposite side of the chassis, the pipe(s) can then become an emitter configured with some amount of cone attenuation, and the direct line-of-sight from the pipe (to your ears) becomes obstructed.

Being able to incorporate this type of behavior to your design will make the in-game car feel more real.

Driving Pitch-Perfect

As you prepare assets from recordings where a vehicle has been recorded while being driven, you will often need to do some amount of pitch ‘flattening’, to hold a reasonably constant pitch over the loop.

Spectral visualizers like the ‘Spectrograph Spectrogram Meter’ JS plugin included with Cockos' Reaper, or Span VST by Voxengo running in a DAW of your choice, come in handy with tracking pitch change. Fire up something like Sonic Visualizer, and it can even track most prominent frequencies and their exact tuning for you!

Whatever the tool, using anything similar will provide you with visual confirmation of what you are hearing. This will help you figure out the natural Rpm and edit for a static-enough pitch.

Let’s look at an example. Below is a screen capture of a single loop asset from one of the vehicles in Wreckfest, looping over and over, and its output visualized with Span. This asset is a static mix of exhaust and engine recordings, with a length of about 3.5 seconds and a natural Rpm of 2910:

Make note of clearly visible peaks that I’m pointing at, roughly centered around 195 Hz, 380 Hz, and 790 Hz. Maybe you already noticed by glance that the numbers look pretty much like a series of harmonically related tones!

While the fluctuation of harmonic peak levels can occur for many reasons (including amount and type of Load), any large sideways movement of a group of harmonically-related peaks will indicate pitch change that you need to address with the asset. Keeping an eye out for this movement can help you create matching automation to flatten the pitch.

If the asset you’re working on needs any pitch flattening, it’s recommended to keep the total change below 3 semitones. Going beyond this will often result in clearly audible artifacts caused by the pitch correction algorithm itself. The less you can get away with, the better.

The Hz values above bring us to conversion between natural Rpm and Hertz, specifically related to engine recordings. If you run Rpm-to-Hz conversion using the value 2910, you will get 2910 / 60 = 48.5 Hz. Multiply this by 4 and you end up with 194 Hz, which corresponds with the lowest peak I’m pointing at. Multiplying 48.5 Hz further, first by 8, will result in 388 Hz and by 16, with 776 Hz. These also correspond with the roughly estimated frequencies of the Span visualization.

But why multiply by 4? We do this because the formula to calculate fundamental frequency of a four-stroke engine in Hz is:

(Rpm ⁄ 60) × (Number of Cylinders ⁄ 2)

Here, we divide the number of cylinders by 2 because a four-stroke engine will need 2 full rotations of the crankshaft to complete one full engine cycle. The recording used for the example above is from an engine with eight cylinders (a 5-liter V8). So in fact what I pointed at in the picture were the root, 2nd and 4th harmonic. The 3rd harmonic (582 Hz) is also present but at quite a lower level compared to the others.

How Many, Too Much?

Besides the recording properties, you also need to consider the amount and length of loops. Using a large set of lengthy loops for both on- and off-load will bloat the memory footprint of your design. Case-by-case evaluation is needed at all times, and often you may need to go back and forth between your audio editor and Wwise Authoring, to find a nice balance between the amount and length.

For the amount, one good starting point is to space natural Rpms at about 1000-1500 apart. Sometimes you might need even smaller intervals depending on how lively your recorded vehicle is, to capture nuances over a specific Rpm range. Smaller intervals equal less re-pitching at run-time.

At the very least, try and steer clear of having just two or three loops over the entire Rpm range. Doing so will add very audible imperfections to the sound, because in this case, the loops are then played far beyond their natural pitch.

One place to proceed with extra caution are recordings that contain a lot of intake or radiator noise. Intake noise will increase with Rpm, some cars can have the radiator running at constant speed regardless of Rpm, etc. Sampled noise will get real nasty in no-time when pitched and, even more so, when any pitch-flattening effects are combined with the Rpm-to-pitch changes in the game. Talk about adding insult to injury!

If opting to include a lot of such noisy elements, you definitely want to look closely at how to space out your loops. Better yet, rather implement the noise procedurally as a separate layer. In real-world scenarios, any tonal changes in intake noise would occur more as a bell-type EQ boost, over a relatively static frequency range, and sometimes even up to a point of being mildly resonant.

As for the length of loops, one rule of thumb is to have each run for at least four seconds. Less than that can expose repetition in the loop too easily, especially when you go above natural Rpm. Driving on a higher gear will expose a loop even more as the engine will rev up slower than on neutral gear. If you don’t exceed the natural Rpm by much, then even less than four seconds can work out fine.

No Less Than Seamless

There’s really only one correct way to make any droning sound loop seamlessly, and it’s this age-old audio editing trick:

That is, split the recording at a known good zero-crossing point, switch the halves around and visually check and align for a phase-compatible crossfade.

In this video, I’m specifically editing a near-constant Rpm engine recording using Reaper, but any modern audio editor ought to be up for the task… And never-mind that the loop on the video isn’t perfect.

Depending on the recording, some editing techniques, like duplicating and reversing a clip, can cause sharp transients present in the recording to play in reverse, and can also break phase over a set of loops. You want to try and avoid such effects at all times. If there are any pitch flattening artifacts or other textures fading in and out over the loop, try increasing the crossfade length.

Last but not least, and not like in the video above (!), always include natural Rpm and Load state with the asset filename for quick reference later on. They will be needed when setting up objects in Wwise. Especially when looking at your assets many months or years later, it will make you extra happy knowing that you spent the extra time naming things thoughtfully.

In the next part, we’ll go hands-on and look at how to configure the loop assets in Wwise. In the meantime, if you have any thoughts on the topic, please let me know in the comments section. 

See you soon! :)

Resources

Vehicle recording sessions; Scheduling, what to prep for, etc.: Vehicle audio in Mafia 3, by Matt Bauer
Vehicle recording tips (mic placement etc.): Capturing sounds for Dirt 4, by Chris Jojo
Engine recording editing tips (visualization with Izotope RX): An FMOD tutorial, by Rory Walker
Sound design tips for racing games: A lengthy Q&A style presentation, by Nick Wiswell
Professional vehicle recordings freebies: GDC Soundpack archive at Sonniss.com