Bug in the Audio Module with listeners?

[Tank]

No they shouldn't.

Then Nexus' argument was wrong, not mine. He said that it's the same with other properties, not me.

I can move my view without changing its size, or I can zoom it without changing its position.

Absolutely, in all cases, because there are no constraints, restrictions, pitfalls etc. But:

Same for the listener orientation: in most cases (all 2D and most 3D)

In most cases? Personally I don't like programming with a time bomb that works "in most cases". Seriously, why can't all cases be simply fixed? I don't get it.

It's important to have in mind if a modification has to be scheduled for SFML 3, or can/must be applied immediately. The design considerations are not the same.

No, it's not important. Again: I'm looking for the best solution. That's my intention. It's then up to you and your version policies to decide how, when and if it all the changes are being implemented.

I really don't want to start discussing the benefits of versioning rules, I think you're smart and experienced enough to understand why they are needed, let's focus on the initial issue please.

I am indeed experienced and smart enough (thanks) to know that, that's why I am not talking about whether stuff should be implemented in version X or Y. I'm adjusting my arguments to your versioning scheme and rules, that's why I'm splitting the solution up into a workaround for 2.x and the "normal clean good solution" for 3. Like said, personally I would not care of any version at all, I would simply release the fix to a bug. I don't get why version numbers are so important for some people.

[therocode]

Same for the listener orientation: in most cases (all 2D and most 3D) the up vector will be fixed to +Y and never change after that.

Sorry but this is just plainly wrong.

If you have a static +Y up vector, you are only allowed to set the at-vector to any values where Y is 0. In other words, this is DOOM movement where you can't tilt the camera up or down. In any basic 3D navigation application when you do any form of 3D calculations, you have to keep your at-vector and up-vector orthogonal. There is no way to hack around this and there is no way to hide this from the "noobs" who would use this feature. You have to when you navigate the camera set both the at-vector and the up-vector to keep the orthogonality, or the audio space will be skewed.

Hence it doesn't make sense to set them separately. I would find that way more awkward to have to call two functions whenever I set the orientation. It would also be as tank said a security flaw when someone doesn't understand that they have to set both orthogonally and they would only use one of the setters and ignore the other and things would not work properly.

[Laurent]

Then Nexus' argument was wrong, not mine. He said that it's the same with other properties, not me.

I know. I was quoting you but actually answering to both

In most cases? Personally I don't like programming with a time bomb that works "in most cases". Seriously, why can't all cases be simply fixed? I don't get it.

All cases are fixed, since we give access to the up vector. That was the main point I think.
The design discussion that we have now will only change how easy/intuitive the new API will be. And all I was saying is that there are many cases where we don't need to deal with the up vector; we're not talking about "broken" cases.

If you have a static +Y up vector, you are only allowed to set the at-vector to any values where Y is 0.

This is called 2D, and is the main target of SFML

[therocode]

If you have a static +Y up vector, you are only allowed to set the at-vector to any values where Y is 0.

This is called 2D, and is the main target of SFML

Okay so you're saying that the 3D audio spatialisation API of SFML is designed in a particular way because 2D is the main target of SFML? But you even said  "in most cases (all 2D and most 3D)" which is still plainly wrong because "most 3D cases" are not DOOM controls.

Also I must say that I am personally a bit disappointed since I didn't know that SFML focussed on 2D even in the 3D parts of the API and I would have assumed that it would be fine to use SFML for 3D audio since that is what is says in the documentation/tutorials etc, but I guess if I want to do 3D audio I am better off using something else indeed. Too bad it isn't that apparent though, since people might actually happen to use it for 3D before realising.

[Laurent]

No... I'm just saying that 2D represents most of the use cases of the audio module (this is easy to understand... most people use the audio API that goes with the graphics API that they chose, and SFML is often chosen for 2D because of its graphics module -- have a look at the Projects forum and tell me how many 3D projects you find), so this consideration must be taken in account when designing the modification. In other words, if I can design something simpler for 2D then most of SFML users will benefit from it and be happy. Whereas 3D users will still be able to achieve what they want. What's wrong with this reasoning?

[therocode]

No... I'm just saying that 2D represents most of the use cases of the audio module (this is easy to understand... most people use the audio API that goes with the graphics API that they chose, and SFML is often chosen for 2D because of its graphics module -- have a look at the Projects forum and tell me how many 3D projects you find), so this consideration must be taken in account when designing the modification. In other words, if I can design something simpler for 2D then most of SFML users will benefit from it and be happy. Whereas 3D users will still be able to achieve what they want. What's wrong with this reasoning?

The thing that is wrong with the reasoning imo is that the sound stuff claims to be a full 3D sound API with 3D sound spatialisations. It never says anything about being 2D specialised, which made at least me think that it was meant to work properly with 3D, but i guess I was wrong.

True you don't see many 3D projects being talked about on the forum. Maybe because newbies cannot do 3D and that more advanced users have realised the various limitations that SFML poses for more advanced use (context management, and until recently the GLEW issue, and similar topics) and moved on to libraries which does things in a way a decent programmer would expect.

I am just speculating here of course,  but more to the point I definitely think that a sound module which is advertised as capable of doing 3D sound spatialisation should do 3D sound spatialisation properly, regardless of if the library aims for 2D or not.

[Nexus]

therocode, what exactly is wrong? With the up vector, 3D spatialization will be possible. That was your main point of criticism, wasn't it? Or are you just denying that because you don't like the API design?

Maybe this whole thing is a misunderstanding

[therocode]

therocode, what exactly is wrong? With the up vector, 3D spatialization will be possible. That was your main point of criticism, wasn't it? Or are you just denying that because you don't like the API design?

Maybe this whole thing is a misunderstanding

No I am not talking about you guys' recent talk about the API, I just replied to Laurent's posts where he said that most 3D cases use a static Y+ up vector and that the 3D sound API is affected by the 2D focus of SFML which are two things I simply disagree with.

As for the API I have stated my opinions already.

[Nexus]

Laurent's point was that the API with separate methods is simpler for 2D users because they don't need the up vector.

And 3D users can still achieve the whole functionality in a straightforward way. It's not as if the API with a compound would clearly be the better approach even for a 3D sound spatialization library, or that the API with separate methods limits 3D users in any way.

Anyway, I think we can summarize this discussion as follows:

• There is a problem whenever up and direction are linearly dependent, in both past and future. It was already possible to avoid the error in the past.
• SFML will provide an up vector in a future version, but not primarily because of that problem, but because it allows full 3D sound spatialization.
• The reason why it was not implemented until now is that there was no big demand for the functionality and there have been more important tasks, and not because Laurent is evil.
• The new API will introduce a separate setter/getter pair for the up vector, for the reasons stated in previous posts of Laurent and mine.

The only question left is the name of the attribute. "UpVector" would be a possibility, but also "Upward(s)" or something completely different like "Overhead" (but a better word for it). Suggestions?

[therocode]

Laurent's point was that the API with separate methods is simpler for 2D users because they don't need the up vector.

Ah right, well that is a more fair point, even though I personally would not take that approach.

And 3D users can still achieve the whole functionality in a straightforward way. It's not as if the API with a compound would clearly be the better approach even for a 3D sound spatialization library, or that the SFML API limits 3D users in any way.

I would argue that it is for the same reasons as tank mentioned, you wouldn't have a separation of RGB. Object oriented ways teach to make structures of things that are conceptually tied together, and the at-vector and up-vector surely is; the term is "orientation" and that is why you set it as a single property in openAL. There is only SetSourcefv(sourceId, AL_ORIENTATION, eightFloats) and not AL_ATVECTOR and AL_UPVECTOR. That would have cluttered the API.

But true it doesn't limit the 3D users and if SFML would take this approach it would still be usable indeed.

Anyway, I think we can summarize this discussion as follows:

• There is a problem whenever up and direction are linearly dependent, in both past and future. It was already possible to avoid the error in the past.

Correction: It is not only a problem when they are linearly dependent, but also when they are not orthogonal with each other, which is in all other calls to setDirection which does not look like this: setDirection(X, 0, Y).

The only question left is the name of the attribute. "UpVector" would be a possibility, but also "Upward(s)" or something completely different like "Overhead" (but a better word for it). Suggestions?

I still say go with upVector. Everyone knows what the direction of "up" is, you don't need to be into maths to get it. If you can understand what "a vector pointing forwards" is, then you can understand "a vector pointing upwards".

[Foaly]

I'm just saying that 2D represents most of the use cases of the audio module

I now this might be a little off topic, but I have to to say that I don't agree with that. I have used the audio module multiple times, without using any other of SFML's modules. It is quiet hard to find a good open source (c++) library for sound. For me SFML provides the cleanest API (compared to SDL, allegro or pure OpenAL) while still being simple (compared to PortAudio) while still having a permiting license (compared to irrKlang). So for me SFML's audio module is pretty much the top of the line (unless I want to do some really freaky stuff, then I use PortAudio).
That is why I think it should be viewed independently of the other SFML parts. Quiet a few SFML users will use the audioo module to simply playback (2D) sound, but there is probably quiet a lot of people like myself, that use the audio module as a standalone "library". After all SFML is a multimedia library.

[Nexus]

Object oriented ways teach to make structures of things that are conceptually tied together, and the at-vector and up-vector surely is; the term is "orientation" and that is why you set it as a single property in openAL.

Yes, and that's a valid point. What I meant with "not clearly" is that both approaches have their advantages and disadvantages, it's not as if the compound blatantly outperformed separate methods. There are multiple design considerations which can have different weight depending on the library or context where they are used.

It is not only a problem when they are linearly dependent, but also when they are not orthogonal with each other, which is in all other calls to setDirection which does not look like this: setDirection(X, 0, Y).

You mentioned the skewed coordinate system. Out of curiosity, do you know what practical implications this has on sound? Will sounds simply appear in the "wrong" place?

The analogy to the human head sounds straightforward at first, because the front and top of our head point to different directions separated by 90°. But when you only consider the eyes that look at different heights without moving the head, a non-orthogonal system would make sense. I think the eyes are quite a good example: you cannot look straight up or down, so you'll never encounter the linear dependent vectors. Sorry for offtopic

[therocode]

Yes, and that's a valid point. What I meant with "not clearly" is that both approaches have their advantages and disadvantages, it's not as if the compound blatantly outperformed separate methods. There are multiple design considerations which can have different weight depending on the library or context where they are used.

Yep this is true which is why it isn't the crucial part of the discussion for me. I could live with such an API even if i myself would have done it differently. The issue at hand with broken spatialisation is more important and as long as that is fixed, it would be enough for me.

You mentioned the skewed coordinate system. Out of curiosity, do you know what practical implications this has on sound? Will sounds simply appear in the "wrong" place?

The analogy to the human head sounds straightforward at first, because the front and top of our head point to different directions separated by 90°. But when you only consider the eyes that look at different heights without moving the head, a non-orthogonal system would make sense. I think the eyes are quite a good example: you cannot look straight up or down, so you'll never encounter the linear dependent vectors. Sorry for offtopic

Yeah, I am not sure how it works on the most detailed level, but as far as I've understood, the "listener" is mererely a coordinate system defined by these three vectors (at, up, right) where "right" is calculated to be orthogonal to the other two using a simple cross product. These vectors are analogous to how a normal coordinate system is defined by the vectors: (1,0,0) (0,1,0) (0,0,1). If you have done 3D rendering, these concepts will be familiar to you, it is how cameras work pretty much. Anyway, sound sources are calculated along this listener-space, which will make them be "oriented" after it. So if the space is skewed, the sounds' positions would end up skewed as well.

I am not sure if I managed to explain it well, but depending on how much the skew is (the skew is greater, the closer in angle these two vectors get) the sounds would be positioned a bit wrong. It would probably not be noticed in most cases since sound locations are hard to verify with 2 speakers, but they would be off none-theless. The equivalent in 3D graphics would be if you tried to render a straight square on a skewed 2D space, it would look something like this on the screen:

[Nexus]

So what do you think, aren't there cases where such a skewed coordinate system is meaningful (see the eyes example in my last post)?

Even if an orthogonal system is mostly the default and will be encouraged in the SFML documentation, I don't think we should take any measures to prevent or detect non-orthogonal systems, as its utility depends on the application.

[therocode]

Well the eye analogy doesn't really work since when you as a human "skew the coordinate system" by looking up with your eyes but not with your head, you don't hear sounds any different than if you would just look straight ahead do you? But in this case if you only tilt the at-vector upwards and keep the up-vector straight up, the sounds will change.

This is an undesired thing in most cases since you want the sound positioning to make sense, but it is true that there should be no measures to prevent it. It is fully legal as far as OpenAL Soft is concerned. The OpenAL specification however says that it "expects the vectors to be orthogonal" whatever that means.

But just to clarify (although you might already have gotten it) the issue right now makes it impossible to not have skewed audio positioning unless you look completely straight ahead like in Doom and such games.