Traversal over a segment of the sphere.

[cgyurgyik]

One thing we talked about in our meeting this week was only traversing through a "slice" of the sphere. We need to discuss how this can be implemented, and what needs to change in our current algorithm.

[ak-2485]

[ak-2485]

@cgyurgyik @nukenukenukelol We had the question of how t_end would be determined @nukenukenukelol was correct in that we already have prescribed bounds for theta, so traversal would exit after that bound is hit; t_end can be some dummy variable.

[ak-2485]

@matthewturk how/where are AMR calls handled for walk_volume in yt? Just curious.

[matthewturk]

@ak-2485 So walk_volume only ever gets uniform grids -- we do a decomposition at an earlier phase that breaks AMR up into non-overlapping grids we call "blocks" or "bricks." So from the walk_volume perspective, AMR doesn't enter into it.

[ak-2485]

The blocks are non-uniform?

[matthewturk]

Sorry, let me rephrase. When walk_volume is called, it is given a single block that is uniform in dx, dy, dz. But, we call walk_volume multiple times, and when we call it the first time, that block may be different than the next time we call it.

[cgyurgyik]

From my understanding, this approach will replace min_bound, max_bound, which are currently unused. We will define a new type of bound, maybe like this:

    // Represents a bound for the sphere using voxel identifications.
    struct VoxelBound {
        std::size_t radial_voxel;
        std::size_t angular_voxel;
        std::size_t azimuthal_voxel;
    };

The algorithm will pass in VoxelBound min_bound, VoxelBound max_bound, and use those to determine how far we want the ray to intersect.

Case 1: If the ray were to intersect the entire sphere,

VoxelBound min_bound = {1, 0, 0};
VoxelBound max_bound = {num_radial_sections, num_angular_sections - 1, num_azimuthal_sections - 1};

We could provide these as default values to our algorithm, but I'm personally not a fan of defaulted values.

I don't suspect that users will ever want ray intersections for a shape like this:

Case 2: If the ray wants to intersect say a sector of the sphere, Let num_radial_sections = num_angular_sections = num_azimuthal_sections = 4. Then,

VoxelBound min_bound = {1, 0, 0};
VoxelBound max_bound = {3, 1, 1};

Rays will intersect the sphere in the first quadrant, as pictured below:

Our algorithm will then end early in two areas:

1. During initialization phase,

   for each voxel_ID:
     if voxel_ID < min_bound, return.
    // for angular, azimuthal, need to check that min_bound < voxel_ID < max_bound

2. During the traversal phase,

   while (current_voxel_ID_r <= max_bound.radial_voxel &&
           current_voxel_ID_theta <= max_bound.angular_voxel &&
           current_voxel_ID_phi <= max_bound.azimuthal_voxel) { ... continue traversal ... }

[matthewturk]

This makes sense to me. I would note that we can convert pretty easily from one to the other, from an r_min to a voxel bound, and that's something we could do in the higher-level code.

On Thu, May 7, 2020 at 10:52 AM Chris Gyurgyik notifications@github.com wrote:

From my understanding, this approach will replace min_bound, max_bound, which are currently unused. We will define a new type of bound, maybe like this:

// Represents a bound for the sphere using voxel identifications.
struct VoxelBound {
    std::size_t radial_voxel;
    std::size_t angular_voxel;
    std::size_t azimuthal_voxel;
};

The algorithm will pass in VoxelBound min_bound, VoxelBound max_bound, and use those to determine how far we want the ray to intersect.

If the ray were to intersect the entire sphere,

VoxelBound min_bound = {1, 0, 0}; VoxelBound max_bound = {1, num_angular_sections - 1, num_azimuthal_sections - 1};

We could provide these as default values to our algorithm, but I'm personally not a fan of defaulted values.

If the ray wants to intersect say a sector of the sphere, Let num_radial_sections = num_angular_sections = num_azimuthal_sections =

4. Then,

VoxelBound min_bound = {1, 0, 0}; VoxelBound max_bound = {4, 1, 1};

Rays will intersect the sphere in the first quadrant, as pictured below: [image: image] https://user-images.githubusercontent.com/37983775/81315439-4ce7c180-9058-11ea-8b6a-2d64f32b78d5.png

Our algorithm will then end early in two areas:

1. During initialization phase,

for each voxel_ID: if voxel_ID < min_bound, return.

1. During the traversal phase,

for each voxel_ID: if voxel_ID >= max_bound, return.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spherical-volume-rendering/svr-algorithm/issues/102#issuecomment-625339441, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAVXO6AZR2OSXAW22YXIPLRQLKL5ANCNFSM4MKDZ3SQ .

[cgyurgyik]

This makes sense to me. I would note that we can convert pretty easily from one to the other, from an r_min to a voxel bound, and that's something we could do in the higher-level code.

Yeah that's a good point. If a user provides numbers, say, [0, 2pi], we can convert that to the corresponding voxels as well in an intermediary function.

[cgyurgyik]

I had a question about assumptions we can make @matthewturk .

1. Will the client use directions from say, (pi/4, -pi/4) -> (pi/4, pi/4) ? In other words, do we need to cover the case where the boundaries include the transition from voxel N-1 to voxel 0?

[matthewturk]

We can ensure that those transitions don't occur.

On Thu, May 7, 2020 at 2:16 PM Chris Gyurgyik notifications@github.com wrote:

I had a question about assumptions we can make @matthewturk .

Will the client use directions from say, (pi/4, -pi/4) -> (pi/4, pi/4) ? In other words, do we need to cover the case where the boundaries include the transition from voxel N-1 to voxel 0?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.