Hi! I’m implementing audio via fmod into a unity game of a spaceship that is always on the center of the screen, except for when de player gets out of it. The problem is that while traveling and turning from going right to left, ther’es an extreme panning of the sound. The developer explained to me that as the emiter is on the side of the spaceship, facing the camera (listener) so the spaceship itself blocks the sound when rotates and creates that behaviour (or so we think). He asked me if there’s a way to make spacialization of 3D sounds without rigid bodies, so that the sound comes from an object but doesn’t get blocked by the object itself. We already thought about ofsseting in Z axis the emiter, but the ship rotates in all axis, so eventually it would happen again when going up or down.
So, What I’m asking if is there’s a way to make spacialization without making the sound collide with rigid bodies. Or even if there’s something like a collision matrix like you have in unity to achieve the solution.
The kind of geometry-based occlusion you describe is not enabled by default in FMOD - nor in Unity, for that matter. It’s possible that you’re using a third-party plug-in that provides this kind of occlusion, or that your developer has for some reason used the FMOD Core API to set up geometry-based occlusion for your game, but it’s extraordinarily unlikely that either of you have enabled geometry-based occlusion accidentally. There are a number of other possibilities that might explain the behavior you’re hearing, however.
Does the spaceship event feature a parameter of the event cone angle, event orientation, or direction types? If so, it is likely that the rotation of your spaceship is causing this parameter value to change from one extreme of the parameter to the other in some circumstances. Try using live update to record a profiler session, then select the spaceship event instance in the profiler window and observe how its parameter values change as your ship rotates relative to the listener. If it is the case that rotation is causing the value of a built-in parameter to flip from one extreme of its range to the other, I recommend tweaking any automation on that parameter to have the same values at both extremes so that switching from one extreme to the other does not result in a sudden change.
It’s also possible, though unlikely, that you have run into a rare bug known to exist in certain versions of FMOD Studio: When the listener is rotated such that an event emitter is almost directly “above” or “below” it (e.g.: passing overhead or underneath while the listener looks forward, or directly forward when the listener is looking at the ground or at the sky), the panning of a spatialized event may audibly “flip” from left to right.