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

Loudspeaker/Source Spherical Coordinate System #14

Open
jcbreton opened this issue Jan 26, 2021 · 2 comments
Open

Loudspeaker/Source Spherical Coordinate System #14

jcbreton opened this issue Jan 26, 2021 · 2 comments
Labels
solver related to a solver of some sort
Projects

Comments

@jcbreton
Copy link
Collaborator

We should decide on a PHI/THETA convention to use for spherical loudspeaker coordinate systems. There's no particular standard that is currently used. See below for what the CLF format uses (hopefully it makes sense, it's tough to draw this):

Screen Shot 2021-01-26 at 9 50 17 AM

The positive X, Y, and Z axes come out of the front, right(when viewed from front), and top of the loudspeaker, respectively. The azimuthal angle phi is defined 0 degrees at the top of the loudspeaker (the +z axis), and rotates clockwise in the yz plane when viewed from the front of the loudspeaker. The polar angle theta is defined from 0 degrees on-axis to 180 degrees in the back of the loudspeaker. The polar angle half-circle always rotates so that it goes through the selected phi.

I'm open to using another convention, but as for the CLF parser, I will probably stick to this so we don't get lost in coordinate system conversions just yet.

@jcbreton jcbreton added the solver related to a solver of some sort label Jan 26, 2021
@jcbreton jcbreton added this to To Do in cram via automation Jan 26, 2021
@jcbreton jcbreton changed the title Loudspeaker Spherical Coordinate System Loudspeaker/Source Spherical Coordinate System Jan 26, 2021
@gregzanch
Copy link
Owner

@jcbreton I'm into it 👍 it's good to be consistent for sure.

@jcbreton
Copy link
Collaborator Author

jcbreton commented Feb 4, 2021

In the RayTracer index file, I changed the random angle generation algorithm so it will generate a random phi between 0-360 and a random theta between 0-180 like shown above. Then, I wrote a function to convert between the "CLF" spherical coordinate system angle convention above and the spherical coordinate system that THREE.js uses (accounting for degree->radian conversion and a coordinate system shift).

Right now, there's absolutely no difference in performance. The RayTracer still generates random initial ray directions like it did before. The only benefit of the changes I made is that now the RayTracer is generating the random angles in the CLF convention, which will make applying directivity easier once we write a reliable interpolation function. Conversion to the THREE.js convention is done immediately before the initial ray direction is assigned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
solver related to a solver of some sort
Projects
cram
  
To Do
Development

No branches or pull requests

2 participants