社区问答

欢迎来到 Audiokinetic 社区问答论坛。在此,Wwise 和 Strata 用户可互帮互助。如需我们团队直接提供协助,请前往技术支持申请单页面。若要报告问题,请在 Audiokinetic Launcher 中选择“报告错误”选项(注意,问答论坛并不会接收错误报告)。我们内部设有专门的错误报告系统,会有专人查看报告并设法解决问题。

要想尽快得到满意的解答,请在提问时注意以下几点:

  • 描述尽量具体:比如,想达到什么样的目的,或者具体哪里有问题。
  • 包含关键细节:比如,Wwise 和游戏引擎版本以及所用操作系统等等。
  • 阐明所做努力:阐明自己为了排除故障都采取了哪些措施。
  • 聚焦问题本身:聚焦于问题本身的相关技术细节,以便别人可以快速找到解决方案。

+3 投票
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
分类:General Discussion | 用户: Marc A. (130 分)

1个回答

+2 投票
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.
用户: Alex Q. (200 分)
...