Talk:Selection: Difference between revisions
No edit summary |
DaveDemarle (talk | contribs) No edit summary |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 10: | Line 10: | ||
In VTK, edges are not separate entities and cannot be easily extracted. In order to support edge selection, proper support for edges would have to be added. As far as I know, this is not in the list of things to do of any VTK project. VTK did not implement edges because it ends up making the data structures very fat. Also, editing a mesh in place (as in CAD) is very difficult in VTK. I think that we should stay away from CAD like functionality until we are ready to tackle another big architectural change in VTK. | In VTK, edges are not separate entities and cannot be easily extracted. In order to support edge selection, proper support for edges would have to be added. As far as I know, this is not in the list of things to do of any VTK project. VTK did not implement edges because it ends up making the data structures very fat. Also, editing a mesh in place (as in CAD) is very difficult in VTK. I think that we should stay away from CAD like functionality until we are ready to tackle another big architectural change in VTK. | ||
[[User:Berk|Berk]] 09:28, 17 Jan 2006 (EST) | [[User:Berk|Berk]] 09:28, 17 Jan 2006 (EST) | ||
:Agreed, edges aren't a requirement. The token-based selection set design allows us to ignore edges in the short-term and add them later if there's ever a need for them, so this should not be an issue. [[User:Tshead|Tshead]] 10:43, 17 Jan 2006 (EST) | |||
=== Selection sets === | === Selection sets === | ||
Line 15: | Line 17: | ||
I am guessing some of these will have to be distributed objects that reside on the server. If the user selects a volume, even a surface, the selection set might be too large to be stored on the client. | I am guessing some of these will have to be distributed objects that reside on the server. If the user selects a volume, even a surface, the selection set might be too large to be stored on the client. | ||
[[User:Berk|Berk]] 09:38, 17 Jan 2006 (EST) | [[User:Berk|Berk]] 09:38, 17 Jan 2006 (EST) | ||
:Agreed - the most likely use-case for a selection set (I think) will be to assign it as an input parameter for a filter, so the API ought to allow for manipulating it all on the server-side. [[User:Tshead|Tshead]] 10:39, 17 Jan 2006 (EST) | |||
=== OpenGL and G Buffer selection limitations === | === OpenGL and G Buffer selection limitations === | ||
Both of these require that geometry for the points/cells to be selected to be generated and rendered. For example, let us say | Both of these require that geometry for the points/cells to be selected to be generated and rendered. For example, let us say the user loads a large unstructured grid. If the size of this dataset is larger that a user specified threshold, paraview will only generate an outline. This is to avoid the lengthy computation of the external surface. Next, the user wants to select a small region and apply a filter to it. This selection will now require the generation of the geometry. At this point, we have two choices. We can either run a special filter that generates only the cells in the selected region or run the regular geometry filter. If we run the regular geometry filter, it will generate all the surface geometry and take a long time to compute. Either way, the geometry filter has to be smart enough to know to generate special arrays that have the ID information. Then, we have to pass this geometry through a special mapper that will pass this ID information to OpenGL. Furthermore, this selection method is limited to surfaces. It cannot select volumes. | ||
[[User:Berk|Berk]] 09:50, 17 Jan 2006 (EST) | [[User:Berk|Berk]] 09:50, 17 Jan 2006 (EST) | ||
---- | |||
More thoughts: | |||
An important goal of ParaQ is to add quantitative analysis to the (until now) qualitative process of scientific visualization. To do quantitative analysis right, we should pay attention to selection fidelity. However we implement selection we should try not to miss any data that might be important to the end user. If we can't ensure that we get everything quickly enough, we should be able to trade off fidelity for responsiveness, perhaps in the same way the LODActor works for rendering. | |||
More info about related classes in VTK and ParaView now: | |||
* Software extraction: vtkCutter/ClipDataSet/ExtractGeometry, and vtkExtractVOI. | |||
* Mouse Picking: vtkAbstractPicker and it's descendents. May use GPU (ex PropPicker) or software (vtkPicker) | |||
* Software probing: run through all points to find closest point to the probe or all the cells to find the containing cell (vtkProbeFilter,vtkPickFilter in XYZ mode) | |||
* Software Pick by ID: run through all points or cells and look for a particular ID (vtkPickFilter in ID mode) | |||
--[[User:DaveDemarle|DaveDemarle]] 12:21, 15 Mar 2006 (EST) | |||
Try the new Rubberband selection filter in ParaView. It's the newest example of selection by pure geometry. | |||
--[[User:DaveDemarle|DaveDemarle]] 10:50, 20 Apr 2006 (EDT) |
Latest revision as of 09:50, 20 April 2006
Wylie: [Regarding OpenGL Selection] These cons seem to be fairly small. Having a good solution for point and rectangle selection seems to be enough. My recollection is that the fixed sized buffer isn't really an issue.... that you can indicate to opengl to give you the first 1 or 5 or N(all) matching selections, and only in the last case is it an issue. The polygon/edge/point issue seems like it might be a factor in all the approaches... you may be able to render those primatives separately if that type of functionality is a high priority.
Just a quick note: Selection in VTK is not limited to picking. See vtkSelectVisiblePoints and VTK/Rendering/Testing/Tcl/labeledMesh.tcl. Not really efficient but it has been in VTK for a long time.
Berk 16:44, 11 Jan 2006 (EST)
Updated the discussion to reflect this, many thanks Tshead 13:36, 12 Jan 2006 (EST)
CAD-like functionality
In VTK, edges are not separate entities and cannot be easily extracted. In order to support edge selection, proper support for edges would have to be added. As far as I know, this is not in the list of things to do of any VTK project. VTK did not implement edges because it ends up making the data structures very fat. Also, editing a mesh in place (as in CAD) is very difficult in VTK. I think that we should stay away from CAD like functionality until we are ready to tackle another big architectural change in VTK. Berk 09:28, 17 Jan 2006 (EST)
- Agreed, edges aren't a requirement. The token-based selection set design allows us to ignore edges in the short-term and add them later if there's ever a need for them, so this should not be an issue. Tshead 10:43, 17 Jan 2006 (EST)
Selection sets
I am guessing some of these will have to be distributed objects that reside on the server. If the user selects a volume, even a surface, the selection set might be too large to be stored on the client. Berk 09:38, 17 Jan 2006 (EST)
- Agreed - the most likely use-case for a selection set (I think) will be to assign it as an input parameter for a filter, so the API ought to allow for manipulating it all on the server-side. Tshead 10:39, 17 Jan 2006 (EST)
OpenGL and G Buffer selection limitations
Both of these require that geometry for the points/cells to be selected to be generated and rendered. For example, let us say the user loads a large unstructured grid. If the size of this dataset is larger that a user specified threshold, paraview will only generate an outline. This is to avoid the lengthy computation of the external surface. Next, the user wants to select a small region and apply a filter to it. This selection will now require the generation of the geometry. At this point, we have two choices. We can either run a special filter that generates only the cells in the selected region or run the regular geometry filter. If we run the regular geometry filter, it will generate all the surface geometry and take a long time to compute. Either way, the geometry filter has to be smart enough to know to generate special arrays that have the ID information. Then, we have to pass this geometry through a special mapper that will pass this ID information to OpenGL. Furthermore, this selection method is limited to surfaces. It cannot select volumes. Berk 09:50, 17 Jan 2006 (EST)
More thoughts:
An important goal of ParaQ is to add quantitative analysis to the (until now) qualitative process of scientific visualization. To do quantitative analysis right, we should pay attention to selection fidelity. However we implement selection we should try not to miss any data that might be important to the end user. If we can't ensure that we get everything quickly enough, we should be able to trade off fidelity for responsiveness, perhaps in the same way the LODActor works for rendering.
More info about related classes in VTK and ParaView now:
- Software extraction: vtkCutter/ClipDataSet/ExtractGeometry, and vtkExtractVOI.
- Mouse Picking: vtkAbstractPicker and it's descendents. May use GPU (ex PropPicker) or software (vtkPicker)
- Software probing: run through all points to find closest point to the probe or all the cells to find the containing cell (vtkProbeFilter,vtkPickFilter in XYZ mode)
- Software Pick by ID: run through all points or cells and look for a particular ID (vtkPickFilter in ID mode)
--DaveDemarle 12:21, 15 Mar 2006 (EST)
Try the new Rubberband selection filter in ParaView. It's the newest example of selection by pure geometry.
--DaveDemarle 10:50, 20 Apr 2006 (EDT)