Here’s my issue. All events are on the {x,z} plan. When I unzoom the camera it moves the listener’s elevation on the y axis. One tile is 1 distance unit. I moved my character back and forth to an adjacent tile and recorded the footsteps in the profiler. In did it twice, only changing the zoom. Here’s the first one, the char is the one with the blue circle on the left of the screen, listener’s y value is 5.31, the sound is heard on the left:
Now that the listener/event offset on the x axis is small (a few units) compared to the listener’s elevation (47 on the y axis), we would expect to hear the sound mostly centered (as we see it). However this is not the case!
Here’s the wave form, first two footsteps at max zoom (from near), then two footsteps at min zoom (from afar). The panning of both is the same: hard left! (up is left channel, down is right channel)
By the way, is there a way to change the events or listener elevation (y axis) in the sandbox? I found nothing in the doc, neither in the forum, and smashing alt, ctrl or shift in every combination doesn’t seem to do anything…
Unfortunately, without knowing your listener’s and events’ 3D attributes, it’s hard for us to diagnose why you’re hearing this behavior. Are you sure the listener is attached to your camera, and facing exactly the same direction? How and when are your events’ and listener’s 3D attributes being updated?
As of the time of writing (January of 2021), there is no way to change the elevation of the listener in the sandbox. I can see how this would be a useful feature, though, so I’ll add it to our feature/improvement tracker.
In the mean time, you can audition the y axis in the event editor by toggling the “Front” view button in the the 3D preview.
Event’s are emitting from the {x,z} plan (y=0) and the camera unzoom increments y position of the listener (with default left-handed system). 3D attributes are updated at each frame.
I have found in the meantime that changing listener 3D orientation resolves the problem. Now the listener is facing towards the screen : forward={0,-1,0}, up={0,0,1}.
Previously, listener was facing towards the “top”: forward={0,0,1}, up={0,1,0}. However, it remains strange: why do sounds coming from bellow the listener would behave like this and keep a hard panning despite a huge elevation? One would expect also in that case to hear the sounds coming closer to the center as the listener rises.
Ah, I think I might know the cause of the behavior. Are you using a version of FMOD Studio older than 2.01.03?
There was a bug in earlier versions that caused FMOD Studio’s normal panning/envelopment to work incorrectly for events directly “above” or “below” the listener (from the listener’s perspective, so if the listener was tilted up or down, the “bad spots” would tilt with it.). It was rare for this to actually occur, as most games either position the listener some distance from the action but facing it, or surrounded by the action where the action is mostly on the horizontal plane. In any case, this bug was fixed in version 2.01.03, and so does not affect more recent versions.
In our case, we could argue to use the listener facing towards the up of the screen, as we did before, in the case we intend to use 5.1 (which probably will not be the case), as if the listener where a character on the field that as the power to levitate. When orienting the listener towards the screen, there is no more sounds behind the listener, thus not anymore interest in using surround rather than stereo.
It’s both common and normal for the listener to match the camera’s perspective when playing diagetic sound, to the point where players may find it jarring or think it’s a bug if they hear a sound coming from the “wrong” direction. There are exceptions, of course - every game is unique - but if you want players to be able to hear a sound and intuit where around their character it’s coming from, matching your listener’s orientation to that of your camera will most likely make it easier. (Non-diagetic sounds can, of course, come from any direction without appearing incongruous.)
Thanks for letting us know you’re using version 2.01.07. The issue you experienced must have some other cause. I’ll continue to investigate.
Hey FMOD staff, @joseph, @richard_simms, sorry for the bump and the tag, but why don’t you answer to this issue? To be more clear about it, here’s a video. When I move the event along the z axis with a fixed x, the left-right stereo balance changes accordingly, which is what’s to be expected. But if I do the exact same thing on the y axis it doesn’t change anything to the stereo (nor 5.1, nor 7.1) panning, despite the fact the orthogonal projection on the stereo axis (x) is exactly the same in both cases. Though, we would expect in both cases that the farther the event is, the more centered it should sound. It seems the spatialization panning is calculated only on the {x,z} plan and don’t take into account the third dimension. I tried with the object spatializer but it’s exactly the same. Don’t you think there’s a big conception flaw here, or am I missing something?
To follow with an even more clear exemple of this, here’s a basic implementation, done in a UE4 template. It highlights the same issue as above, but in a different manner. To be listened with headphones.
A speaker, placed bellow the player, and offset on the left-right axis, diffuses some music. As the player rotates around the left-right axis, you can hear the panning is changing, though it shouldn’t. Most of the time, the panning is normal, mostly centered, but when facing forward, the sound is abruptly hard panned right.
We’re still discussing this internally, and have yet to reach a decision about which approach to solving this issue would work best. Which is to say, we do plan to implement a solution, but cautiously.
Whichever solution we choose, it’s going to involve some very complex changes, and will significantly alter the behavior of one of our most-used features. As such, it’ll take us some time to develop a fix. Even when a fix is available, it will likely have to wait for a new major version.
Fortunately, this issue is only rarely noticeable. Very few games regularly require accurate panning of events directly above and below the listener, and most events make use of sound size and distance attenuation, both of which help mask the problem in a wide variety of circumstances. For the few games that are noticeably affected by this issue, there are effective ways of working around the issue by controlling listener position and angle.
Yes, but a note should be made on the doc, for the case where the problem is the more prominent, and permanent (it’s the way I discovered it): in 2D stereo games, the listener should be facing the plan where the events are. Since it’s 2D and not surround, we could think the listener “forward” vector has no importance, but in fact it does.
You are correct. Fortunately, we’re currently working on improved documentation for effects, so it’s the perfect opportunity for us to add information about how the spatializer interacts with height.
