[vtk-developers] New feature: improved hover support

[Moreland, Kenneth]

In general, the idea of having a second render in the still render (effectively doubling the time) is troubling.  If you have a lot of geometry that takes a while to render (which is not uncommon in a 3D view), the added rendering time is not acceptable.

Is this behavior an option and is it off by default?

-Ken


On 9/9/09 9:37 AM, "Jeff Baumes" <jeff.baumes at kitware.com> wrote:

Basically yes. The exception is the render caused when the actual hover text changes and the scene needs to be re-rendered, in which case the pick render is not performed. The problem is knowing when a render caused any pipeline updates or camera changes, which are the cases where you need to re-generate the pick map. BTW the cached pick map is also used for drag-selections.

Thinking about it, it would probably be better to wait for the first "mouse dwell" or drag-selection to update the pick map, I'll make a note of that.

Jeff

On Wed, Sep 9, 2009 at 11:27 AM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
Does that mean every still render is actually rendered twice with the second one basically a pick render?

-Ken



On 9/9/09 9:04 AM, "Jeff Baumes" <jeff.baumes at kitware.com <http://jeff.baumes@kitware.com> > wrote:

I've just checked in a change that allows improved hover support in vtkRenderView subclasses.

After each render (except during interaction), the view automatically takes a "snapshot" of what is currently rendered in a special render mode that maps pixel locations particular actors and cells. When the user's mouse stops over a cell, the render view looks up the hovered cell in the map and sends it to its representations to possibly produce a hover label. Representations manage the pipleline/mappers/actors for displaying a particular type of data in a view. They implement support for hover queries by overriding GetHoverTextInternal().

This is currently implemented in vtkRenderedGraphRepresentation, where the user may select the vertex and edge hover arrays.

The view also allows the hover labels not to be rendered with OpenGL, but invokes a HoverEvent when the hover label changes. This would allow an application to capture these events and use real native tooltips (e.g. with Qt) to show the hover labels.

Jeff




   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov <http://kmorel@sandia.gov>
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel






   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20090909/1a7140d6/attachment.html>