-
Notifications
You must be signed in to change notification settings - Fork 618
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
WIP: Volume rendering & camera changes #612
Conversation
What is the relationship to the existing WIP volume rendering PR? Does it |
It's another technique. And I believe that @lcampagn had yet another technique in mind. So I guess they can be complimentary. We probably have to make a list of advantages / disadvantages of the different techniques to see whether we need all of them. |
nodes = transforms._node_path(self, transforms.viewbox.scene) | ||
T = [n.transform.inverse for n in nodes] | ||
view_tr = transforms._transform_cache.get(T) | ||
self._program.vert['viewtransform'] = view_tr |
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.
@lcampagn this is the code to get the transform from camera to scene, required to calculate the view direction vector in the vertex shader.
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.
It's not valid because it depends on scenegraph; this kind of behavior is only allowed for VisualNode subclasses.
You could try using the method described in my visual tutorial 5, but perhaps we should wait until that PR is settled..
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.
Sure, this needs to be implemented in a better way. One idea is to let the transformsystem object have a "cameratransform" (or something with a better name). On the event object this transform will be implemented in the way that I did it here.
Changed the data to the MRI data that is in our demo-data directory. Will also upload the stent volume soon. So you guys can check the render if you want. Note that this is still WIP though ... One thing that I want to address is improving our camera models and implement a camera that you can fly around ala flight-sim. The current render technique is set up to allow cameras inside the volume, which would be really awesome if we could make it work correctly... |
fb1ec2a
to
c49d48c
Compare
This is finally ready for review. I invite you to try out the new volume example.
|
cc @izaid |
@@ -10,6 +10,7 @@ | |||
from ..visuals import Visual | |||
|
|||
|
|||
# todo: I though the visuals were mixed, but the base Node was *not* a visual? | |||
class Node(Visual): |
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.
@lcampagn I though the visuals were mixed, but the base Node was not a visual?
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.
This was just easier. We can separate Node / NodeVisual later if necessary.
@@ -15,7 +15,7 @@ | |||
|
|||
fname = load_data_file('orig/triceratops.obj.gz') | |||
|
|||
canvas = vp.mesh(fname=fname, azimuth=-0, elevation=90, distance=2) | |||
canvas = vp.mesh(fname=fname, azimuth=-0, elevation=90) |
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.
Why?
@lcampagn the Turntable camera has changed, and does no longer have distance and mode properties. |
|
||
# todo: user should do this via parenting. we should connect to re-parenting | ||
# event and then call _find_viewbox. | ||
# @viewbox.setter |
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.
This (was) automatically called by ViewBox.. why should this be done with parenting instead?
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.
Because it would be nice if a user can just grab a camera and place it in a new scene: cam.parent = another_viewbox.scene
and it would be able adjust itself.
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.
But why is that better than viewbox.set_camera(...)
or whatever we have already?
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.
Ah, I think what you were trying to do is allow cameras with no parents to be used. But this would allow a camera to be a child of one scene, while it uses in another (to which it is not a child), which is weird. We should probably discuss this further in #647 when we discuss allowing multiple cameras-multiple scenes.
Updated: addressed some comments. Also fixed the artifact: that was related to a bug in gloo causing the texture wrapping in z-direction not to be set. I think the most "controversial" changes are related to the cameras. I propose we discuss what to do with that in #647. I can implement a new kind of turntable camera that is closer to the original version, if you want. |
* aspect_ratio -> scale_ratio * aspect_fixed -> fixed_ratio * set_range() can be called before association with a viewbox * set_range queries scene bounds more efficiently * Line visual handles bounds better * And some small details ...
@campagnola Thanks for the review. Addressed comments. Travis is green (except that I managed to misspell "size skip"). |
1 similar comment
1 similar comment
WIP: Volume rendering & camera changes
This PR implements volume rendering. It's basically a port of the technique that I use in Visvis.
This is about ready. There are more things to do, but that can be picked up in another PR. (I added todo items for this in volume.py)
I wish to do more with the camera's, but we should probably discuss this first. Will make a new issue for this.
todo:
closes issue #725
Closes #725