search

spherical-volume-rendering / svr-algorithm

A spherical volume rendering algorithm that performs ray casting through a spherical voxel grid.
Other
6 stars 7 forks source link

Clarification on azimuthal and polar angle bounds #207

Open matthewturk opened 3 years ago

matthewturk commented 3 years ago

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?

cgyurgyik commented 3 years ago

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 commented 3 years ago

OK -- we could delay talking through this further until you're off your internship, if that works better for you!

On Wed, Aug 5, 2020 at 6:52 AM Chris Gyurgyik notifications@github.com wrote:

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/spherical-volume-rendering/svr-algorithm/issues/207#issuecomment-669149033, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAVXO2ZVFYN673KOHHGN73R7FBYHANCNFSM4PUYVBMA .

cgyurgyik commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

cgyurgyik commented 3 years ago

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 .