ResonanceAudioSource: Non-ideal update occlusion strategy

[pschraut]

If occlusion is enabled in a ResonanceAudioSource, the method ResonanceAudioSource.Update() tests whether the 'occlusionDetectionInterval' exceeded and calls ResonanceAudio.ComputeOcclusion() in such case.

The problem is that all ResonanceAudioSource's run ComputeOcclusion() at the same time. It's because if ResonanceAudioSource's exist in the scene during design time (not added later during runtime), they're all initialized during the same frame when entering play mode, thus their 'nextOcclusionUpdate' is the same value (zero) and the following code evaluates to true for all of those Components during the same frame as well, cause every 'nextOcclusionUpdate' a performance spike:

if (Time.time >= nextOcclusionUpdate) {
    nextOcclusionUpdate = Time.time + ResonanceAudio.occlusionDetectionInterval;
    currentOcclusion = ResonanceAudio.ComputeOcclusion(transform);
}

It would be more efficient, if only a subset of ResonanceAudio Components call ComputeOcclusion per frame.

I would prefer a time budget value in the ResonanceAudio class, that can be used to specify a maximum value of how many milliseconds of a frame is used to compute occlusion.

For example, if there are 100 ResonanceAudioSource Components that use occlusion, perhaps only 0..20 update their occlusion during frame N, because the "occlusionBudget" value didn't allow for more time to spend on it. During the next frame, ResonanceAudioSource Components 21..40 update their occlusion, and so on.

Another idea could be to use the distance to the listener to decide how often something is updated. ResonanceAudioSource's closer to the listener could then update their occlusion more often than ResonanceAudioSource's far away.

This approach enables to have a constant cost for computing occlusion, no matter how many ResonanceAudioSource Components exists.

The current implementation would cause a performance spike every 'nextOcclusionUpdate'.

[mauskopf]

Thanks for reporting this, Peter!

We'll look into your suggestion. And thanks for the helpful problem definition.