Block-rendering based slicing

[matthewturk]

This is a slightly different implementation than #12 -- and it brings with it downsides and upsides.

As of issuing the pull request, the sampling isn't precisely working, but I think that's probably not too bad to fix. This uses the full "block rendering" machinery to work. The downside to this is that it takes a lot longer to get the data up -- since we're putting the whole dataset (or whatever subset we're sending) on the GPU before rendering. #12 does this with a much more memory-conservative approach -- and one that can be used to supply arbitrary image data.

There're things to improve in this, but it seems like it might be a worthwhile, additional approach.

import yt
from yt_idv.scene_annotations.grid_outlines import GridOutlines  # NOQA
from yt_idv.scene_data.grid_positions import GridPositions  # NOQA
import yt_idv

ds = yt.load_sample("IsolatedGalaxy")

rc = yt_idv.render_context(height=800, width=800, gui=True)
sg = rc.add_scene(ds, "density", no_ghost=False)
br = sg.components[0]
br.render_method = "slice"
br.slice_normal = (1.0, 0.0, 0.0)
br.slice_position = (0.5, 0.5, 0.5)


grids = ds.index.grids.tolist()

gp = GridPositions(grid_list=grids)
rc.scene.data_objects.append(gp)
go = GridOutlines(data=gp)
rc.scene.components.append(go)

rc.run()

[matthewturk]

OK, I fixed it by correcting the order of uniform application! Whoops.

[chrishavlin]

Note: added both this and #12 to the 0.3.0 milestone because I think both approaches are good and I'm pretty sure there's nothing conflicting in the changes in both PRs. I think #12 is good primarily if you already know what/where you want to slice... while I think the approach in this PR allows a better way to slice interactively.

[chrishavlin]

Hey @matthewturk I was running your example locally now that tests are back to passing.... and I think I broke it while merging/rebasing with main...

[matthewturk]

Yup I think so.

…

On Tue, Oct 25, 2022, 1:35 PM Chris Havlin ***@***.***> wrote: ***@***.**** commented on this pull request. Hey @matthewturk <https://github.com/matthewturk> I was running your example locally now that tests are back to passing.... and I think I broke it while merging/rebasing with main... ------------------------------ In yt_idv/shaders/shaderlist.yaml <#13 (comment)>: > + slice: + description: Slice + first_vertex: grid_position + first_geometry: grid_expand + first_fragment: slice_sample + second_vertex: passthrough + second_fragment: apply_colormap This is likely my fault from all the merging/rebasing.... but I *think* this should be up in the normal block_rendering and not the octree_block_rendering? Is that right? — Reply to this email directly, view it on GitHub <#13 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVXO3HWMVYUO2CB5J6SSDWFAR6TANCNFSM42WZ2JIA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chrishavlin]

Ok, I'm still getting an error after moving the slice, but let me push that change and then copy the new error

[chrishavlin]

ok, now it's just up in block_rendering. Here's the error I get when I run your example locally:

Traceback (most recent call last):
  File "/home/chavlin/src/yt_general/yt_idv/examples/amr_volume_rendering.py", line 9, in <module>
    rc.run()
  File "/home/chavlin/src/yt_general/yt_idv/yt_idv/rendering_contexts/pyglet_context.py", line 158, in run
    pyglet.app.run()
  File "/home/chavlin/.pyenv/versions/yt_idv/lib/python3.9/site-packages/pyglet/app/__init__.py", line 107, in run
    event_loop.run(interval)
  File "/home/chavlin/.pyenv/versions/yt_idv/lib/python3.9/site-packages/pyglet/app/base.py", line 184, in run
    timeout = self.idle()
  File "/home/chavlin/.pyenv/versions/yt_idv/lib/python3.9/site-packages/pyglet/app/base.py", line 245, in idle
    self.clock.call_scheduled_functions(dt)
  File "/home/chavlin/.pyenv/versions/yt_idv/lib/python3.9/site-packages/pyglet/clock.py", line 277, in call_scheduled_functions
    item.func(now - item.last_ts, *item.args, **item.kwargs)
  File "/home/chavlin/.pyenv/versions/yt_idv/lib/python3.9/site-packages/pyglet/app/base.py", line 154, in _redraw_windows
    window.dispatch_event('on_draw')
  File "/home/chavlin/.pyenv/versions/yt_idv/lib/python3.9/site-packages/pyglet/window/__init__.py", line 1363, in dispatch_event
    super().dispatch_event(*args)
  File "/home/chavlin/.pyenv/versions/yt_idv/lib/python3.9/site-packages/pyglet/event.py", line 422, in dispatch_event
    if getattr(self, event_type)(*args):
  File "/home/chavlin/src/yt_general/yt_idv/yt_idv/rendering_contexts/pyglet_context.py", line 73, in on_draw
    self.scene.render()
  File "/home/chavlin/src/yt_general/yt_idv/yt_idv/scene_graph.py", line 156, in render
    element.run_program(self)
  File "/home/chavlin/src/yt_general/yt_idv/yt_idv/scene_components/base_component.py", line 247, in run_program
    with self.program1.enable() as p:
  File "/home/chavlin/src/yt_general/yt_idv/yt_idv/scene_components/base_component.py", line 221, in program1
    self._program1 = ShaderProgram(
  File "/home/chavlin/src/yt_general/yt_idv/yt_idv/shader_objects.py", line 90, in __init__
    self.link(vertex_shader, fragment_shader, geometry_shader)
  File "/home/chavlin/src/yt_general/yt_idv/yt_idv/shader_objects.py", line 114, in link
    raise RuntimeError(GL.glGetProgramInfoLog(self.program))
RuntimeError: b"error: geometry shader output `v_model' specifies no interpolation qualifier, but fragment shader input specifies flat interpolation qualifier\nerror: fragment shader input `v_camera_pos' has no matching output in the previous stage\n"

[chrishavlin]

k, think I figured it out...

Here's the diff of the commit I just pushed:

--- a/yt_idv/shaders/slice_sample.frag.glsl
+++ b/yt_idv/shaders/slice_sample.frag.glsl
@@ -1,5 +1,4 @@
-flat in vec4 v_model;
-flat in vec3 v_camera_pos;
+in vec4 v_model;
 flat in vec3 dx;
 flat in vec3 left_edge;
 flat in vec3 right_edge;
@@ -40,7 +39,7 @@ void main()
     vec3 ray_position = (inverse_pmvm * clipPos).xyz;
 
     // Five samples
-    vec3 dir = normalize(v_camera_pos.xyz - ray_position);
+    vec3 dir = normalize(camera_pos.xyz - ray_position);
     dir = max(abs(dir), 0.0001) * sign(dir);
     vec4 curr_color = vec4(0.0);

That make sense, @matthewturk ?

I'm going to try adding a menu option for the slicing coordinates...

[chrishavlin]

simple float input controls in