Mumble: Unnecessary Positional Audio variables

[vimpostor]

What are the fFront and fTop members in the Plugins class for? https://github.com/mumble-voip/mumble/blob/e097ef34da02edfa68e6c4bc03b33124f36acb0e/src/mumble/Plugins.h#L75

Searching the entire project for their usages just returns plugin files setting these variables, but not Mumble using it anywhere. Positional Audio needs fPosition, fCameraPosition, fCameraFront and fCameraTop. These variables are sufficient to produce positional audio.

Since reverse engineering memory addresses is very time consuming, these two redundant variables should be removed from the Plugin API. At the moment every plugin has to reverse engineer two additional unnecessary values.

[Krzmbrzl]

This might be part of the redundant set of variables that positional audio plugins may provide but that aren't used by Mumble (yet). I only know that these variables exist but I forgot which they were. I guess the likelihood of these being them is very high though :)

[Krzmbrzl]

/cc @davidebeatrici

[zsawyer]

These variables make sense for orientation-based sound profiles.
In the context of avatar-based sound in 3rd person games: Players facing each other would perceive louder sounds.
Using only the camera orientation would not work in this scenario.

[Krzmbrzl]

@zsawyer actually I think it's the other way around: if only the character position and direction was used, it wouldn't work :thinking:

Anyways: The point is: The other variables aren't used by Mumble in the current implementation :point_up:

[zsawyer]

The point is that camera orientation and positioning as the source origin doesn't make sense in 3rd person. You then need those.

Yes, currently the orientation-based emissions profile is not implement but in the light of new sophisticated plugins this might be of interest.

[vimpostor]

I don't get what you mean by what you mean with camera orientation not
making sense in 3rd person. In my opinion the camera orientation always
makes more sense as the direction to use than the avatar's orientation.

Could you explain a scenario where the avatar orientation would be more
meaningful than the camera orientation?

On Thu, Jun 11, 2020 at 11:50:54AM -0700, zsawyer wrote:

The point is that camera orientation and positioning as the source origin doesn't make sense in 3rd person. You then need those.

Yes, currently the orientation-based emissions profile is not implement but in the light of new sophisticated plugins this might be of interest.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/mumble-voip/mumble/issues/4173#issuecomment-642866600

[zsawyer]

Ok. Let's get some context.

These data are used for two things as we are talking about a duplex setup

1. specifying where the sound originates from in virtual space
2. specifying where the receiver of the sound is in virtual space

The use case is realism.
If I was to implement a sound filter which bases the loudness on where a player is looking at (naturally when you speak people in front of you can better understand you). I would need to know the orientation of the sound source, which is the player avatar or its head. In a 3rd person game the values for camera orientation and position can differ immensely from those of the avatar.
So with this hypothetical filter active. If a speaker was to look at me, I'd expect sounds from him being loudest when the avatar is facing me directly and most quiet when the speaker is turned away.
If camera orientation was used this would result in what seems as random loudness to the receiver when the speaker moves the camera around while the avatar doesn't move at all.

This filter would be helpful in tactical games where enemies and friendlies are on the same channel and one wants to avoid detection by nearby enemies when talking to friendlies. It essential allows to whisper to a specific person in front of you.

[Krzmbrzl]

Okay I see now, what you mean and that makes sense to me. However the fact remains, that Mumble doesn't use these variables. So in theory they could be used to solve the problem you are describing, but that's not what is happening inside the code. These values are just ignored.

[vimpostor]

OK I understand your usecase now as well. While Mumble doesn't implement this in any sort of way as of now, it could maybe do so in the future so it might make sense to keep these unused variables in the new Plugin API.

The only reason why I was asking for these variables, was because these were two variables that have to be reverse-engineered for every plugin although they are not used. But perhaps in the future one can set them just to 0 in game plugins, and only plugins that want to reverse engineer them to support a non-existing feature can do so.

Tl;dr: It probably makes sense to keep these variables in the new API, but Game plugins should not have to provide real values for these variables (e.g. setting them to 0 should be fine) as long as Mumble doesn't do anything with these variables.

[vimpostor]

Taking a quick glance at the code, it looks like setting these two variables as 0 should be fine for a game plugin while still working fine (again, these variables are not used anywhere, so anything is fine).

I will probably just do that instead of reverse engineering 2 additional addresses in the future. And with that, this issue is fixed for me.

If Mumble at any point implements a feature like described above, it should then check if these variables are 0 and disable the feature accordingly.

[zsawyer]

I agree. The null vector would work as a magic constant for "off".

I'd leave this issue open until this behaviour is properly documented. So that everyone knows these are optional and which value to set it to, if unknow or unfeasible to get.