Community Q&A

Welcome to Audiokinetic’s community-driven Q&A forum. This is the place where Wwise and Strata users help each other out. For direct help from our team, please use the Support Tickets page. To report a bug, use the Bug Report option in the Audiokinetic Launcher. (Note that Bug Reports submitted to the Q&A forum will be rejected. Using our dedicated Bug Report system ensures your report is seen by the right people and has the best chance of being fixed.)

To get the best answers quickly, follow these tips when posting a question:

  • Be Specific: What are you trying to achieve, or what specific issue are you running into?
  • Include Key Details: Include details like your Wwise and game engine versions, operating system, etc.
  • Explain What You've Tried: Let others know what troubleshooting steps you've already taken.
  • Focus on the Facts: Describe the technical facts of your issue. Focusing on the problem helps others find a solution quickly.

+3 votes
Hi, I noticed an issue with the occlusion calculation in UE4, in UAkComponent::CalculateOcclusionValues.

The raycasts are done only ignoring the listener actor (player pawn), the problem is that in 90% of (our) cases the AkComponent is automatically attached to the root of an actor, e.g. if you imagine a radio with the pivot at the center the raycast from inside will always intersect the radio mesh.

As a result pretty much all our sounds are occluded. I changed the code locally to change the behaviour and always ignore the owner actor.

I understand that there are some cases where we want an actor to be self occluding (a big mesh for instance) but not in most cases where a character or object mesh should not occlude its own sounds. It's not an issue when explicitly placing AkComponent or using ambient sounds, but we don't use them much as it's simpler to post events on actors and let the integration code dynamically create the AkComponent.

I am just wondering if there was a reason why you chose to do it that way, and if I'm missing something?

On a side note the occlusion model is a bit expensive, and for our purposes we will reduce to only one raycast in most cases, it would be cool to have the complexity of the occlusion as a tunable option (simple/binary, vs complex).

Marc Audouy
in General Discussion by Marc A. (130 points)

1 Answer

+2 votes
We have been encountering similar issues.  25 traces traces per occlusion call is definitely expensive, and it does seem that most of them are blocked regardless of where the listener is positioned.
by Alex Q. (200 points)
...