Spherical volume rendering

[chrishavlin]

This is a follow up based on https://github.com/yt-project/yt_idv/pull/42 from @sochowski

Fairly confident the geometry shaders and texture sampling are working as they should at this point, next step is to add some intersection checks in the fragment shader and then sample along the ray within each fragment.

Image from the current version of examples/amr_spherical_volume_rendering.py showing the radial component of a spherical dataset in the range of 0.5 to 1 in r, 0 to pi/4 in phi, pi/4 to pi/2 in theta.

[chrishavlin]

Looks like the commit history was preserved, so I won't worry about figuring out how the previous PR got closed...

[chrishavlin]

note to self: moving the spherical uniforms down to the BlockRendering._set_uniforms will probably fix the failing test.

[chrishavlin]

more things to do:

• [ ] add tests : integrating the "ones" field will be a good test!
• [ ] add intersection-tests and sampling to ray_tracing.frag.glsl
• [ ] figure out the camera issue? I think something is off about how the scene center is being set... rotating the rendering is odd.
• [ ] consider the other fragment shaders as well: slice_sample.frag.glsl and isocontour.frag.glsl don't use ray_tracing and could be adjusted to work with spherical coords as well pretty easily (probably as a follow up to this PR).
• [ ] front/back culling issue -- when you render (index, r) with a hemisphere there can be front/back face culling issues.

[chrishavlin]

latest push is a proof of concept for calculating the intersection points of a spherical block with a ray. All intersections with the 6 basic geometries defining the faces of a spherical subvolume are calculated: inner and outer spheres at fixed r, inner and outer cones at fixed theta, the two planes at fixed phi. The definition of the fixed-phi planes are calculated globally in the initial python loop over the blocks and passed down as vertex attributes which are passed along without modification to the fragment shader where all of the intersection points are calculated.

To do:

• move some of the calculations in the fragment shader to the vertex shader
• don't break cartesian rendering: this initial work hard coded some variables. Need to fix that.
• actually use the intersections: no ray tracing is happening. the intersection points are being calculated but not yet being used.
• optimize optimize optimize. there's a lot of if statements, there's non-intersections saved as infinity. these things need to be improved....

[chrishavlin]

so after merging with main, the scaling is off. I suspect I'm now scaling the coordinates twice somewhere...

[chrishavlin]

also, can now make use of the preprocessor directives from #70 to better separate the spherical-only parts of the shaders.

[matthewturk]

Check into the YTPositionTrait settings, which now convert to unitary instead of leaving in code units.

On Tue, Jun 6, 2023 at 3:20 PM Chris Havlin @.***> wrote:

so after merging with main, there scaling is off. I suspect I'm now scaling the coordinates twice somewhere...

— Reply to this email directly, view it on GitHub https://github.com/yt-project/yt_idv/pull/64#issuecomment-1579390898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAVXO4ZIEOETMK4MTETAG3XJ6GJLANCNFSM6AAAAAASSFCE6A . You are receiving this because you commented.Message ID: @.***>

[chrishavlin]

note to self: since the current shader iteration is returning single values for blocks and not actually doing any ray traversal, images will be progressively chunkier to nonsensical when using load_uniform_grid with decreasing nprocs. I think this should be fixed by actually evaluating along rays... but wanted to make a note here so I remember to double check. Following images generated with https://gist.github.com/chrishavlin/e5a4ee4c9032cf143cad01c24ffdf1af with decreasing nprocs

nprocs 2048

nprocs 1024

nprocs 256

[matthewturk]

@chrishavlin Can you resolve the conflicts?