Skip to content
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

Merged
merged 27 commits into from
Mar 25, 2015
Merged

Conversation

almarklein
Copy link
Member

This PR implements volume rendering. It's basically a port of the technique that I use in Visvis.

  • New Volume visual with two rendering styles (iso and mip).
  • Volume example in examples/scene/volume.py Try it, and use the keys to switch cameras etc.
  • Refactored cameras a bit in general
  • Refactored TurnTableCamera: no more mode and distance. You can just change the fov while getting the same zoom level. Setting fov to 0 means orthographic. Zooming is done by moving camera backward.
  • New FlyCamera to fly around your data.

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:

  • avoid warning when swithching render styles
  • camera's

closes issue #725

volume

Closes #725

@larsoner
Copy link
Member

larsoner commented Nov 8, 2014

What is the relationship to the existing WIP volume rendering PR? Does it
supersede it, or is it complementary?

@almarklein
Copy link
Member Author

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.

@almarklein almarklein mentioned this pull request Nov 8, 2014
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
Copy link
Member Author

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.

Copy link
Member

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..

Copy link
Member Author

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.

@almarklein
Copy link
Member Author

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...

@almarklein
Copy link
Member Author

This is finally ready for review. I invite you to try out the new volume example.

  • Be sure to press "1" to select the fly-camera, and then WASD + mouse to fly through the volume.
  • Press "i" and "m" to toggle between isosurface and mip render styles.
  • With the turntable camera, use CTRL+RMB to smoothly change the fov from orthographic to perspective.

@almarklein
Copy link
Member Author

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):
Copy link
Member Author

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?

Copy link
Member

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.

@campagnola
Copy link
Member

Looks great!

Artifact--looks like the texture is wrapping around?
anticipation1

@@ -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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

@almarklein almarklein mentioned this pull request Nov 26, 2014
7 tasks
@almarklein
Copy link
Member Author

@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
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

@almarklein
Copy link
Member Author

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 ...
@almarklein
Copy link
Member Author

@campagnola Thanks for the review. Addressed comments. Travis is green (except that I managed to misspell "size skip").

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.83%) to 77.02% when pulling fde101f on almarklein:volume into 0444b69 on vispy:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.83%) to 77.02% when pulling 196129c on almarklein:volume into 0444b69 on vispy:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-1.83%) to 77.02% when pulling 196129c on almarklein:volume into 0444b69 on vispy:master.

@almarklein almarklein changed the title WIP: Volume rendering WIP: Volume rendering & camera changes Mar 24, 2015
@coveralls
Copy link

Coverage Status

Coverage decreased (-1.65%) to 77.14% when pulling 45b8335 on almarklein:volume into cce5011 on vispy:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-1.65%) to 77.14% when pulling 45b8335 on almarklein:volume into cce5011 on vispy:master.

almarklein added a commit that referenced this pull request Mar 25, 2015
WIP: Volume rendering & camera changes
@almarklein almarklein merged commit 3b19080 into vispy:master Mar 25, 2015
@almarklein almarklein deleted the volume branch March 25, 2015 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Image visual crashes when turntable camera is used.
8 participants