Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Term "linear independent" confused with "mutually perpendicular" #1298

Closed
juj opened this issue Aug 31, 2017 · 3 comments
Closed

Term "linear independent" confused with "mutually perpendicular" #1298

juj opened this issue Aug 31, 2017 · 3 comments
Assignees
Milestone

Comments

@juj
Copy link

juj commented Aug 31, 2017

The spec at https://www.w3.org/TR/webaudio/#widl-SpatialListener-forwardX says

These values are expected to be linearly independent (at right angles to each other),
and unpredictable behavior may result if they are not.

The term of linear independence does not mean being at right angles. Two vectors u and v are linearly independent if one is not a scalar multiple of the other, i.e. if there does not exist a scalar k such that v=k*u. This is much weaker than being at a right angle.

Two vectors that are at right angles at each other are also linearly independent, but two vectors that are linearly independent are not necessarily also mutually perpendicular to each other. For example, vectors u=(0,1,0) and v=(0,1,1) are linearly independent, since there does not exist a k such that u=k*v, but the angle between these two vectors is only 45 degrees.

Does the doc want to say that unpredictable behavior may occur if the two vectors are not mutually perpendicular, or that unpredictable behavior may occur if the two vectors are not linearly independent?


Sidelining a bit, whichever the desired answer is to the above question, it is not required for unpredictable behavior to exist in either case, but it would be possible to apply a fixed process to always complete a 3D frame from given two input vectors:

If the two vectors are not mutually perpendicular, it is possible to well define the result by perpendicularizing one over the other using Gram-Schmidt process. That behaves well, and e.g. perpendicularizing the up vector at the reference of the forward vector (forward direction takes precedence over up), would be predictable, as long as it is documented well.

If the two vectors are linearly dependent and as such, the set forward,up,cross(forward,up) is degenerate, it is still possible to well define the result, by documenting steps that would be taken in the degenerate case to "complete" the set to span a 3D frame. For example, if forward=(0,0,0), it could be documented that a fixed direction forward=(0,0,-1) is then assumed (which is the documented default forward direction). If, after that, the direction up is linearly dependent to forward, then a default direction up=(0,1,0) could be used, and if after that the vectors are still linearly dependent (in the case forward=(0,1,0), up=(0,0,0)), it could be stated that a second default direction up=(1,0,0) is used.

@padenot
Copy link
Member

padenot commented Aug 31, 2017

The spec at https://www.w3.org/TR/webaudio/#widl-SpatialListener-forwardX says

Just a detail (does not matter here, the text references has not changed), but the last version of the spec is always at https://webaudio.github.io/web-audio-api/.

@joeberkovitz , can you have a look at this one, since you've done the other 3d maths things recently ?

@rtoy
Copy link
Member

rtoy commented Aug 31, 2017

At the very least, I think we should remove the "right angles" part. I don't think the algorithm requires that and does the appropriate projections (Gram-Schmidt, essentially) to get the right things.

At this point, I don't want to have to define the behavior when the vectors aren't independent. I'm ok with saying the behavior is undefined if they're not independent. Garbage in, garbage out.

@joeberkovitz
Copy link
Contributor

I agree with @rtoy's last comment that we should just remove the reference to right angles because we're already using the equivalent to Gram-Schmidt.

When the vectors aren't independent, the attempt to normalize the cross product of up and forward for the listener will fail because the result has zero magnitude. However, we're already checking for zero magnitude source orientation in the algorithm and returning a well defined result of 0 azimuth and elevation. So I propose another zero check on the listenerRight vector (the cross product), and take the same way out.

There's also a leftover clerical error in the azimuth/elevation algorithm since it refers to the orientation of a listener, but the vector is in fact defined as forward (it was presumably renamed).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants