Correct Y audition

[Nexus]

The listener's up vector is hardcoded to +Y, and the direction is -Z by default.

When comparing with the head of a user, we get the following right-handed coordinate system:

• Y: up
• Z: out of the screen, towards user
• X = Y×Z: right

The 2D graphical coordinate system (the screen's plane in 3D) is however as follows:

• X: right
• Y: down

Normal headphones cannot differentiate heights (only left/right). But to align correctly with graphics coordinates, shouldn't the listener's up vector actually be in -Y direction?

If I emit a sound on the screen, do I have to flip the Y difference between sound and listener in order to have a correct height audition?

[Laurent]

Hmm I don't know, I should take 5 minutes to think about it. It's always confusing to mix 3D and 2D system coordinates

[Nexus]

Yeah, would be cool if you could quickly do that, then I don't write wrong stuff in the book

It seems like nitram_cero is the only guy who ever took a detailed look at SFML's sound spatialization. He also wrote this great article, and the funny game The Duke

He also wrote here:

I came to this conclusion:
If you have a up vector +Y, and at(target) vector -Z... it leaves +X=right and -X=left.
The target vector is actually "depthness", which is played (or should be) as "further inside the monitor" (which we'll probably never use)

Y is Up, so if you wan't something making a falling sound, this is your axis.
And that's the same as a plataformer! You really want things falling (Y screen axis) to be represented like the're coming from "up" (Y sound axis). Actually it's opposite sign.
How it's now it's actually correct!

I'm not sure if I understand him correctly, like me he talks about the opposite sign. But he also mentions that the way it was was actually correct, which I don't understand.. was it different than now?

In a platformer, a falling object's graphical Y coordinate continuously increases. In sound coordinates, Y decreases, since +Y is "up". So if we map the coordinates 1:1, the Y audition will be inverted, the object will seem to go upwards.

[Laurent]

I'm not sure if I understand him correctly, like me he talks about the opposite sign. But he also mentions that the way it was was actually correct, which I don't understand.. was it different than now?

If I remember correctly, his problem was more general, and when he says "it's correct" he probably speaks about the overall system, ignoring details such as opposite Y sign.

Basically, for the book, you should emphasize that graphics and audio coordinates systems are totally unrelated, and that it's up to the user to map one to the other (there are actually several possibilities). So don't speak about "-Y" as an error, rather as an adjustment to get the desired result

[Nexus]

Okay, thanks! The way to go is then:

sound.setPosition(x, -y, 0);
sf::Listener::setPosition(x, -y, depth);

Do you plan a sf::Listener::setUpVector() function or similar? It seems like a very useful feature anyway, as it would allow actual 3D spatialization. You don't have to decide yet, I can also just mention that SFML uses always a hardcoded up vector of (0,1,0).

[Laurent]

This is something that I want to keep hidden for simplicity reasons, but it's not the first time that it is requested. So yes, I might add it in the future.

[Tuffywub]

I think it would be great to be able to set the "up" vector. It is an absolute MUST for a 3D game. As long as it kept a default value, I don't think it would make the sound library much more complicated.

In fact, I think it is less confusing to have a way of expressing which direction is up. This is because you might not be sure if the direction of the listener and the up vector are really just the same thing. This could lead to some very confusing mistakes.

I think leaving out an important feature is worse than cluttering the API a bit more