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

Clarification on azimuthal and polar angle bounds #207

Open
matthewturk opened this issue Aug 4, 2020 · 6 comments
Open

Clarification on azimuthal and polar angle bounds #207

matthewturk opened this issue Aug 4, 2020 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@matthewturk
Copy link
Contributor

Hi! I was working on some of the previous work when I ran into something that I was unsure of. In the test_svr.cpp file, I see lots of areas where the sphere bounds are set to 0 .. 2*pi for both azimuthal and polar angles. My understanding is that we should usually be setting them to 0..pi for polar and 0..2pi for azimuth.

Is the code set up to address this somewhere internally? Or does it need to be modified somehow to take this into account?

@matthewturk matthewturk added the bug Something isn't working label Aug 4, 2020
@cgyurgyik
Copy link
Contributor

I believe I just set it up in a way such that we treat the azimuthal bound as a circle on the Z-axis, so that [0, 2pi] encompasses the entire sphere while [0, pi] might only encompass a portion of it. This could probably be refactored to use [0, pi]. I can't think of a reason why not.

I don't believe we ever modify ourselves; we simply treat it as [0, 2pi].

Like I said earlier, the bounds issue was a bit rushed and definitely far from perfect. This was probably my fault, and I should've taken a step back. But then school deadlines happened.

@matthewturk
Copy link
Contributor Author

matthewturk commented Aug 5, 2020 via email

@cgyurgyik
Copy link
Contributor

Yep, I'll probably tag along and read what you post here every once in awhile. Hopefully since next week is my last, its a bit calmer.

@ak-2485
Copy link
Contributor

ak-2485 commented Aug 7, 2020

Yes, so this is kind of weird, and perhaps it is worse and than weird and just wrong: we aren't thinking about a coordinate system - we wanted to avoid a coordinate system as much as possible - and just figure out a simple way to count voxels. The way we did this was to break up the interval [0,2pi] by the number of desired sections for each angular region. I imagine that we will want to switch to the standard [0,pi] for the azimuthal angle/angle of inclination; (I think) this would only affect the initialization routine which determines the initial voxel of the ray. However, in the short term, I'm not sure that it matters. If it does, then there might be a bigger problem in the background.

@cgyurgyik
Copy link
Contributor

Will change to [0, pi] once #208 is reviewed and submitted.

@cgyurgyik cgyurgyik self-assigned this Aug 11, 2020
@cgyurgyik
Copy link
Contributor

cgyurgyik commented Aug 21, 2020

Here's some quick thoughts.

We're currently using the following coordinates to represent a sphere:
Radial: [0,r] , Polar: [0, 2pi] , Azimuthal: [0, 2pi].
This was done for simplicity, since we began with a 2-dimensional circle [0,r] [0, 2pi], and then added a 3rd dimension by adding a third coordinate to represent the 3-dimensional case. It was a non-issue initially, since we assumed that we would always represent an entire sphere. However, we've now introduced the notion of sphere splicing. We want to use the spherical coordinates represented:
Radial: [0,r] , Polar: [0, 2pi], Azimuthal: [0, pi]

So my question to myself was, does there exist some 1:1 mapping between these two coordinate systems, such that we can simply just have a function TranslateFromSphericalCoordinates(...) that gives us our appropriate bounds?

For example, to represent a cone in spherical coordinates, we would set Radial->[0, 0], Polar->[0, 0], and Azimuthal to [0, pi/2]. Now, how do we do that in our coordinate system?

Looking for your input here as well, @ak-2485 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants