Native Unreal vs Middleware


I need to gather information and advice regarding Unreal’s native audio capabilities versus the use of middleware (FMod / Wwise). One key factor for my considerations is implementing vehicle sounds. Now, I am reasonably inexperienced in this area, so my own education of how best to implement such sounds will probably be a huge determining factor too. :slight_smile: For example, so far, using native Unreal, I have implemented vehicle sounds using short sample loops of engine sounds and then modifying their pitch using parameters like wheel speed or velocity of the vehicle. This has given reasonable results, but I am unsure if:

a) This is the best way to do it. b) I would get better results with it using middleware instead

Now, I am aware that Unreal’s audio engine has been completely rewritten and will be available for testing in 4.16, so this is another thing I need to factor into my decision. There are features such as:

  • Timestretching samples (might be a better implementation for engine sounds?)
  • Real-time modulation of a cutoff filter (doesn’t seem possible natively in 4.15)
  • Peak meters and some kind of visual mixer (like Unity has)

…which are things I found myself desiring when developing natively in Unreal.
In summary then, I just need some help deciding whether to design vehicle sounds natively in Unreal, or if I should definitely pursue middleware, and which middleware! :slight_smile:

Any advice would be greatly appreciated.


Native UE4 is sufficient for authoring good vehicle audio, especially if you use and learn BP. Implementing it via Sound Cue’s is probably going to be tricky. I’d implement it directly in BP with audio components and use UE4 curves to map game/vehicle parameters to audio parameters (volume/pitch scaling).

Here’s a doc on the UE4 curve editor:

For traditional game vehicle audio, volume/pitch scaling is sufficient. Volume allows you to cross-fade between different loops of different engine behaviors. So a usually a blend between different engine loops along with a pitch-shift of each can produce good results.

Time-stretching (i.e. changing duration without causing a pitch shift) can be a more expensive DSP operation and doesn’t usually yield quality results for the CPU expense since it usually involves a Fourier transform and re-synthesis. Y

UE4’s audio components allow you to parameterize a sound’s volume/pitch scale directly so BP/audio components are sufficient for vehicle audio.

So basically with BP you can author your own curves, define your own BP structs which define and control the data you want to use. Then in the BP itself, you’d map acceleration/velocity/power of the vehicle to audio parameters.

Make sure you write your BP so that it’s generalizeable so you can easily swap out sounds that you want to use, define different curves, etc, without having to totally rewrite your BP script. That way you can potentially have one BP script used for many different vehicle types.

wWise or FMOD will require RTPC parameter communication to their tool and you’ll end up doing roughly the same tasks (mapping game parameters to curves), but it won’t be as direct and flexible as what you can accomplish in BP.

One interesting possibility, if you’re up for experimentation, is to use the new granular synthesizer in the new audio engine for vehicle audio. Granulation is the basis of most of the “advanced” sounding vehicle sounds you might here since it can approximate a “time stretch without pitch shifting” effect (effectively by playing particles of sound) and can produce a better/more realistic engine sound. I believe this is the technique used in games like Need for Speed, etc. To use the granulator (assuming you can wrap your head around using it at all), you’d use similar curve functions to map game parameters to audio parameters, except instead of just volume and pitch, you’d be able to change scrub position, grain density, grain randomization, grain type, etc.

Thanks so much for the detailed reply!

I am so glad you brought up the granular synthesizer, because having watched your recent presentation, I did wonder if I could try using it to essentially timestretch the vehicle engine audio and then scrub through it. :slight_smile:
I am definitely up for experimentation and will give this a try. I suppose my only other question on this point would be when would you expect the new audio engine to be officially ‘switched on’ rather than just available by editing the .ini file?

It’s hard to estimate that at this point – depends on how well QA testing goes. The first step will be for it to be on by default for new projects. Then there will likely be a period where we ween people off the old audio engine. It is backwards compatible so it should be relatively painless to move over.

Hi Jacob / MK

Sorry MK but I cannot agree with you on changing volume / pitch to represent increased rpm engine sounds.
It may be acceptable in general gaming terms, but for any simulation project it will not cut the mustard.

I have spent the last 10 years having to record various loops of locomotives at differing rpm / loading which are then crossfaded together (tricky and never perfect).

However within sound forge I can stretch them in real time and produce a very good representation of the entire rpm range.
( a method I use to create any extra loops)

I agree that TS can sometimes produce poor quaity … usually caused by too bigger step.
So usually I take several small steps to achieve a good shift ( in Sound Forge)

The increase pitch / volume method in does not get any where near the sound of any particular engine over its RPM range ( may or may not be important)

Close mic an exhaust and the pitch of every power stroke is the same throughout its entire RPM range, its duration decreases and volume increases with RPM.

I dare wager that any mention of engine sounds … the first thought is automotive with a typical 1000-5000 range.
In my field a diesel locomotive has an rpm range of 350-850 making every beat audible
Or how about a steam locomotive with a zero - ? range.

Paul G