July 27, 2016

Adding spatial sound to our Unity model in HoloLens – Part 2

Last time we looked at a rudimentary – although in some senses complicated – spatial sound implementation for our ABB IRB 6620 industrial robot model inside HoloLens. It was simple because we added a single sound at the root of the robot, and complicated because we then had to track the status of each of the robot’s parts and turn the sound off when all were stopped.

In this post we’re going to look at the second of the three design options we saw last time:

A single sound is assigned to our robot

When the robot stops completely, so does the sound

The same sound is assigned to each of the robot’s parts

When each part stops moving, so does the sound for that part

A different sound is assigned to each of the robot’s parts

When each part stops moving, so does the sound for that part

It was simple enough inside Unity to copy & paste the AudioSource values from the root of the robot to each of the parts: Unity has a handy “Paste Component As New” option in the Inspector, which saves a great deal of time and effort:

Then we simply had to make sure the root AudioSource is disabled (or removed) and that the code uses the AudioSource attached to the part itself rather than relying on our root-attached Buzz.cs component. Here’s the updated Rotate.cs file:

using UnityEngine;

publicclassRotate : MonoBehaviour

{

// Parameters provided by Unity that will vary per object

publicint partNumber = 0; // Part number to help identify when all are stopped

I was pleasantly surprised with how well it worked. While I’d expected having 6 simultaneous audio sources playing to be an issue, it actually just led to the sound being louder when combined, and somehow more realistic: as you stop individual parts, they stop making noise. The last part being stopped causes the robot to fall silent.

Here it is in action. I’ve tried to give a sense of the spatial nature of the sound, which may or may not come through. At least you should be able to see how the various parts’ sounds get combined.

So technically HoloLens can clearly manage the load associated with having multiple, spatial AudioSources attached to a model in this way – at least with this particular usage scenario. Which means technical feasibility (for my purposes) is proven, and the question of whether to attach a single sound or multiple ones becomes a design decision. Which is great.

Now that I’ve tried it, I’m leaning towards the current approach being the preferred option… if we need further differentiation of the individual parts, we might also tweak the values for each AudioSource while keeping the same base audio file, of course.

But I’m still going to see how things work with separate audio files for each part, to see how that behaves. I’m now fairly sure this will also prove feasible – and potentially very interesting – but will clearly take more design-related effort, or the experience may prove to be overwhelming or confusing. We’ll see!