kitware / cinema Goto Github PK

Since this involves a lot of webGL, we will probably need to use selenium. We should see what we can reuse or learn from Roni's work to this end in tangelo:

https://github.com/Kitware/tangelo/blob/3bb9225359c0ff08256f26c6770130dbc237f87d/testing/vtkweb/vtkwebtest.py
https://github.com/Kitware/tangelo/blob/3bb9225359c0ff08256f26c6770130dbc237f87d/testing/vtkweb/tangelo-vtkweb-test.py

We should also get this working headlessly in travis.

My guess is this is the result of a circular event binding somewhere, haven't tracked it down yet though.

Some of the recent refactoring broke our routing behavior when the page gets loaded.

Try using the LIC algorithm to visualize vector data on the client side from vector value fields.

We can get vectors (for example normals that we use for lighting) across. To color them, we should compute the magnitude and use that by default, but also let the user choose to color by a particular component.

Now that we get search results to show up in webgl-based views, I noticed that when I double-click one of those results, the search results go away, and main view comes back empty. Once I interact in some way (like rotating or changing visible layers), the view shows up properly.

The RenderingWidget has a reference to the visualization canvas widget which is using it, and the RenderingWidget is currently using this reference to make calls (e.g. forceRedraw()) on the implicated visualization canvas widgets. Instead, we need to trigger events that those widgets can then listen to. However, when I tried to do this in one case (forceRedraw), I started seeing missing dom elements in the visualization canvas widgets when they tried to re-composite.

When we resize the browser window, most of the views fail to redraw the image. This is the case for all the webgl-based canvas widgets, as well as for the javascript canvas widget. While debugging this for the webgl widgets, I ran into weird things I couldn't explain, like the html canvas element (my viewport) having null width and height. I'll probably need @zachmullen and/or @patrickoleary to help with this issue.

save off two images per layer x viewpoint and blend in with red or green on client

Add rendering option where we draw glyphs by pseudorandomly choosing pixels, then finding vectors and scalars underneath, and using that to draw oriented, scaled and even color mapped glyph icons.

VisualizationCanvasWidget (and especially VisualizationCanvadWidgetLight) have a backgroundColor
ivar. We should expose a control for that on the UI. Better yet, add two colors and do gradient backgrounds.

Like glyphing, we can choose well spaces pixels, find the values underneath, and then draw values as text on top of them.

When looking at the composite view, it seems the scrollbars change in a way that causes the pipeline widget to shift left and right. This only seems to happen as new "keys" are loaded and cached, and once all the phi (for a fixed theta) or theta (for a fixed phi) images have been loaded, this behavior stops.

Like text labels, but instead of putting them in many places we just query at the mouse point and then pop up a text box that lists all of the data values underneath.

The bounding box layer is an example. The pipeline widget gives you one field to color by, which is a SOLID_COLOR type field, and shows you the R,G, and B values that the data
was rendered with. It seems natural that users would expect to be able to change those and the code path to do so is pretty simple.

• Make our view hierarchy consistent and make sure all references are tree-form
• Propagate destructor calls downward allowing child views to unbind any necessary references such as events or model refs
• Don't initialize subviews inside of render

do approximate opacity by:
rendering near side as we do now
do front face culling to render far side
record depth of both
alpha blend both sides of every enabled layer on each pixel

This is another bug related to searching in the webgl-based views. After you double-click a search result, get the blank image, then interact to cause something to be displayed, there seems to be a single camera angle which gets rendered incorrectly, different from all the other camera angles and timesteps. It appears that the camera angle associated with the last search result on the first page of results is the only one to have this issue. The problem is that this camera angle shows up the size of a search result instead of the size of the main view image, and it also gets rendered at the bottom left of the screen instead of centered.