Unity - Can we bake separated *ace.bytes files for async streaming level

[laurelhach]

Hi,

First off, amazing work! a really wonderful tool to use in our project :)

I am using Acoustics with Unity 2020 and I was wondering if it was possible to have separated *.bytes files attached to separated levels (async load). I am able to run the manager (prefab) with 1 asset (my first level as a test), but I couldn't find any documentation to have multiple files (and the manager doesn't offer multiple *. bytes files).

I have the feeling that all maps needs to be baked at once (a bit like the mesh occlusion system in Unity). Am I right?

Thanks for your help!

[MikeChemi]

Thanks for the kind words! :)

It is possible to support what you want, but it'll take a small amount of work. As-shipped, the AcousticsManager supports only a single ACE at a time, with only a single instance of the manager at a time. You have a couple options here.

• The easiest option is to swap out the loaded ACE file on the manager when you cross over into a new level. This may or may not work, depending on how large your levels are. The ACE loading is fairly quick, but queries may fail for a few frames while the files are swapped out.
• The next option requires a bit of code change to the AcousticsManager. You can remove the DisallowMultipleComponent tag to let you have multiple copies loaded up at once. Each copy could have its own unique ACE file. The tricky bit here is managing the calls to AcousticsPAL.Spatializer_SetTritonHandle. You'll want to swap out the Triton handle only when the player has moved into a new level(similar to option 1). The benefit here is you can load the ACE file well in advance of the player getting to a level boundary, and then swapping out the handle is a very quick operation.

As a last option, your suggestion of baking all the levels at once would work. We manage streaming in probes, so you're not going to blow up your memory footprint just because you baked the whole scene at once. This option is the least amount of code and should work fine, assuming it doesn't produce a gigantic ACE file. We have an internal limitation of 2GB. If the file grows larger than that, this option won't work.

[laurelhach]

@MikeChemi,

Thanks for your detailled answer, I will try the first option first, as it is the easiest and see how it goes :) Also, I assume that there are no needs to overlap the probs (for the ACE generation) when the player crosses a level or stands in between two levels?

Thanks again!

[MikeChemi]

You don't strictly need to overlap probes, no. It's possible that parameter interpolation may not be as nice on the level boundaries because of the "missing" probes on one side, but that's largely level-dependent. It's equally possible that your levels will not have any problems with this method.

If the player can "hover" around a level boundary, it may be worth to have some probe overlap to avoid lots of ACE swapping when the player bounces back and forth between the two levels on the boundary. If it's more of a one-way-ticket, that's a good sign you can get away without overlap.