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
Block-rendering based slicing #13
Conversation
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. |
fb7b1ba
to
8655660
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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...
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:
***@***.***>
|
Ok, I'm still getting an error after moving the |
ok, now it's just up in
|
k, think I figured it out... Here's the diff of the commit I just pushed:
That make sense, @matthewturk ? I'm going to try adding a menu option for the slicing coordinates... |
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.