Right now, I have a case where it appears that two event instances with the "Just Fail If Quietest" setting and maxplaybacks = 1 steal back and forth when there is geometry occluding them.
simplest case is something like this
A = event A, B = event B, | = wall, L = listener
A | L | B
A takes over then B appears louder because A is occluded, so B takes over, then A appears louder because B is occluded, so A takes over.
If both checks behaved the same way, we would not see this sort of oscillation. Do the events consider occlusion geometry when deciding if they should steal back? We have the 3d position set (via the info only interface) when attempting to get the new event instance, but there does not appear to be an obvious way to compute the occlusion ourselves if it’s not done automatically.
- calvinlin asked 10 years ago
[quote="calvinlin":3odzbx7w]Do the events consider occlusion geometry when deciding if they should steal back?[/quote:3odzbx7w]
Unfortunately they don’t. Geometry occlusion is calculated per-channel by the low-level API. Since the info-only event has no channels, there are no occlusion values to use.
I have added this issue to our tracker. We will look into it.
Just to let you know, this week’s API release will include a fix for this issue. The relevant revision.txt entry is:
– Event API – Fixed "Just fail if quietest" max playbacks behaviour to use the
same audibility calculation for all events. This solves some bad
interactions with geometry, sounddef volume and event fadein that
could cause oscillations.
This means that "Just fail if quietest" now ignores geometry completely, which (as you say) is better than oscillating.
Please login first to submit.