ParaView 3.6 Deliverables: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
== Deliverables to Complete == | |||
{| border=1 | {| border=1 | ||
! Name | ! Name | ||
Line 17: | Line 19: | ||
* Simple conversion from tables to other data (such as collection of points). | * Simple conversion from tables to other data (such as collection of points). | ||
| Utkarsh | | Utkarsh | ||
|- | |- | ||
| More multiblock | | More multiblock | ||
Line 34: | Line 28: | ||
| Right now getting any scripting in ParaView has a high learning curve. State files are unreadable and almost completely uneditable. To do any scripting at all, you need to learn a significant chunk of Python bindings. To make this easier, ParaView should output a much more friendly way of scripting things. Either the state written out should be much simpler (show only the things that pertain to the current view) or be able to write out a very simplified Python script to get back to the state, or both. | | Right now getting any scripting in ParaView has a high learning curve. State files are unreadable and almost completely uneditable. To do any scripting at all, you need to learn a significant chunk of Python bindings. To make this easier, ParaView should output a much more friendly way of scripting things. Either the state written out should be much simpler (show only the things that pertain to the current view) or be able to write out a very simplified Python script to get back to the state, or both. | ||
| Berk/Utkarsh | | Berk/Utkarsh | ||
|- | |- | ||
| Particle Support | | Particle Support | ||
Line 45: | Line 35: | ||
** Optional sizing based on a scalar | ** Optional sizing based on a scalar | ||
** Appropriate alpha blending (at least when particles are small) | ** Appropriate alpha blending (at least when particles are small) | ||
** Splatting? | |||
* Filters for meshless data? (Need to get customer requirements.) | * Filters for meshless data? (Need to get customer requirements.) | ||
** Sampling point cloud? | ** Sampling point cloud? | ||
** Surface extraction? | ** Surface extraction? | ||
: '''Note:''' Not all will be finished. We will probably provide resizable sphere rendering for the particles and perhaps the better transfer function. We need to talk with John Biddiscombe to learn the current state and assign responsibility. | |||
| Zhanping/John Biddiscombe | | Zhanping/John Biddiscombe | ||
|- | |- | ||
| Temporal cleanup | | Temporal cleanup | ||
Line 65: | Line 53: | ||
* Intersection of surface with plane. | * Intersection of surface with plane. | ||
* Path between two points on a plane. | * Path between two points on a plane. | ||
: '''Note:''' This is not a high priority, but it should be easy. Delay until later if it requires more than 3 days of work. | |||
| Berk/Utkarsh | | Berk/Utkarsh | ||
|- | |||
| VisIt AVT Integration | |||
| We would like to pull VisIt components into ParaView (such as readers and filters). To this end, we would like to have an interface that would convert AVT to the VTK executives (or vice versa) so that we could leverage these without changing any code. | |||
: '''Partial:''' For 3.6, let's just do the readers. | |||
| Burlen | |||
|- | |||
| Statistics | |||
| Integrate Phillipe Pebay's statistics filtering and then some. | |||
| Zhanping | |||
|} | |||
== Deliverables to Start == | |||
{| border=1 | |||
! Name | |||
! Description | |||
! Owner | |||
! Level of Involvement | |||
|- | |||
| Multicore | |||
| Multi-core desktops are becoming commonplace. It is now reasonable for a user to invest in an 8 core desktop with several GB of memory in lieu of a visualization cluster. Unfortunately, ParaView has no good way of taking advantage of the multiple cores. | |||
| Berk | |||
| Research | |||
|- | |||
| D4 | |||
| Time to get rolling on the next generation distributed data decomposition filter. [[D4 Design]] | |||
| Andy Bauer | |||
| Start | |||
|- | |||
| Foreground color | |||
| Add ability to specify a foreground color for a view (in addition to the background color). The foreground color is the default color for text, lines, and that sort of thing in 2D and 3D widgets. | |||
| Zhanping | |||
| Start. Perhaps provide some implementation for common components. | |||
|- | |||
| vtkIdType size | |||
| Currently the user must select the size of vtkIdType (32 vs 64) at compile time. This is not an ideal way to select the id size. Usually, you want 32 bit ids (for the smaller size), but when dealing with large MPI jobs, there is a chance you might need to represent global ids with 64 bits. We should look into possible ways to support selecting an Id size at run time without breaking backwards compatibility. | |||
| Berk | |||
| Research | |||
|- | |||
| Better labeling | |||
| The Infovis group has made a labeler that works well in 3D. We should integrate that into ParaView. | |||
| Zhanping | |||
| Look into Dave Thompson's code (and ask Jeff Baumes about it). If it is really production ready, we can bump this up. | |||
|- | |||
| Scatterplots | |||
| The current line plot can be used to do scatterplots of small amount of data, but it cannot be used to, say, a plot of two field variables for a large parallel vtkDataSet. An efficient implementation will have to use OpenGL and parallel image compositing. | |||
| | |||
| Look into VisIt's 2D scatterplot implementations. We really could use this sooner rather than later, but it is probably too big a project to finish by 3.6. If we could leverage other code, that would be great. | |||
|- | |||
| Parallel coordinates. | |||
| Why doesn't ParaView have parallel coordinate views? There may be more work than just grabbing what is available in VTK. It has to work in parallel servers. Also, it probably won't be very useful without the 2D histogram line accumulation technique. | |||
| | |||
| Take a look at VisIt's. It works in parallel and supports the 2D histogram technique. | |||
|- | |||
|} | |||
== Deliverables Delayed for Later == | |||
{| border=1 | |||
! Name | |||
! Description | |||
! Owner | |||
! Note | |||
|- | |||
| Movie view | |||
| Add movie file readers that behave like an image reader the supports time. When viewed in a 2D image view with the time controls, ParaView becomes a simple movie viewer. | |||
| Zhanping | |||
| Lisa Ice originally requested this. We should talk to her again to get the use case/priority. | |||
|- | |- | ||
| Custom filter cleanup | | Custom filter cleanup | ||
Line 78: | Line 135: | ||
: This may end up being documenting how to add new representations through plugins etc. [[User:Utkarsh|Utkarsh]] 09:32, 27 October 2008 (EDT) | : This may end up being documenting how to add new representations through plugins etc. [[User:Utkarsh|Utkarsh]] 09:32, 27 October 2008 (EDT) | ||
| Utkarsh | | Utkarsh | ||
|- | |- | ||
| Unordered Color maps | | Unordered Color maps | ||
| Some data values do not have any logical order associated with them. For example, block ids and process ids have identifiers that distinguish them, but there is no real meaning between the relationship of each pair. Thus, it makes little sense to use our standard linear color maps. A much better approach would be to map individual colors to values and show these colors as blocks in the color bar. VisIt demonstrates this quite nicely (although the colors they use aren't perfect). | | Some data values do not have any logical order associated with them. For example, block ids and process ids have identifiers that distinguish them, but there is no real meaning between the relationship of each pair. Thus, it makes little sense to use our standard linear color maps. A much better approach would be to map individual colors to values and show these colors as blocks in the color bar. VisIt demonstrates this quite nicely (although the colors they use aren't perfect). | ||
| Zhanping | | Zhanping | ||
|- | |- | ||
Line 103: | Line 144: | ||
: This is a huge can of worms that would destabilize ParaView for a long time. Nothing in server manager is even close to being thread safe. I think we should focus on the actual use case: making the user interface responsive (i.e. progress reporting and abort) while processing occurs. [[User:Berk|Berk]] 08:43, 27 October 2008 (EDT) | : This is a huge can of worms that would destabilize ParaView for a long time. Nothing in server manager is even close to being thread safe. I think we should focus on the actual use case: making the user interface responsive (i.e. progress reporting and abort) while processing occurs. [[User:Berk|Berk]] 08:43, 27 October 2008 (EDT) | ||
| Utkarsh | | Utkarsh | ||
|- | |||
|} | |} |
Revision as of 21:38, 18 November 2008
Deliverables to Complete
Name | Description | Owner |
---|---|---|
ParaView/Titan Chart Merger | If not already complete. | Burlen/Utkarsh |
Tables |
|
Utkarsh |
More multiblock |
|
Zhanping |
Simplified state/scripting | Right now getting any scripting in ParaView has a high learning curve. State files are unreadable and almost completely uneditable. To do any scripting at all, you need to learn a significant chunk of Python bindings. To make this easier, ParaView should output a much more friendly way of scripting things. Either the state written out should be much simpler (show only the things that pertain to the current view) or be able to write out a very simplified Python script to get back to the state, or both. | Berk/Utkarsh |
Particle Support | Leverage the work from CSCS.
|
Zhanping/John Biddiscombe |
Temporal cleanup |
|
Berk |
Plots along curves | Now you can plot along a line segment in space (defined by two endpoints). Users want to plot along other types of curves in space.
|
Berk/Utkarsh |
VisIt AVT Integration | We would like to pull VisIt components into ParaView (such as readers and filters). To this end, we would like to have an interface that would convert AVT to the VTK executives (or vice versa) so that we could leverage these without changing any code.
|
Burlen |
Statistics | Integrate Phillipe Pebay's statistics filtering and then some. | Zhanping |
Deliverables to Start
Name | Description | Owner | Level of Involvement |
---|---|---|---|
Multicore | Multi-core desktops are becoming commonplace. It is now reasonable for a user to invest in an 8 core desktop with several GB of memory in lieu of a visualization cluster. Unfortunately, ParaView has no good way of taking advantage of the multiple cores. | Berk | Research |
D4 | Time to get rolling on the next generation distributed data decomposition filter. D4 Design | Andy Bauer | Start |
Foreground color | Add ability to specify a foreground color for a view (in addition to the background color). The foreground color is the default color for text, lines, and that sort of thing in 2D and 3D widgets. | Zhanping | Start. Perhaps provide some implementation for common components. |
vtkIdType size | Currently the user must select the size of vtkIdType (32 vs 64) at compile time. This is not an ideal way to select the id size. Usually, you want 32 bit ids (for the smaller size), but when dealing with large MPI jobs, there is a chance you might need to represent global ids with 64 bits. We should look into possible ways to support selecting an Id size at run time without breaking backwards compatibility. | Berk | Research |
Better labeling | The Infovis group has made a labeler that works well in 3D. We should integrate that into ParaView. | Zhanping | Look into Dave Thompson's code (and ask Jeff Baumes about it). If it is really production ready, we can bump this up. |
Scatterplots | The current line plot can be used to do scatterplots of small amount of data, but it cannot be used to, say, a plot of two field variables for a large parallel vtkDataSet. An efficient implementation will have to use OpenGL and parallel image compositing. | Look into VisIt's 2D scatterplot implementations. We really could use this sooner rather than later, but it is probably too big a project to finish by 3.6. If we could leverage other code, that would be great. | |
Parallel coordinates. | Why doesn't ParaView have parallel coordinate views? There may be more work than just grabbing what is available in VTK. It has to work in parallel servers. Also, it probably won't be very useful without the 2D histogram line accumulation technique. | Take a look at VisIt's. It works in parallel and supports the 2D histogram technique. |
Deliverables Delayed for Later
Name | Description | Owner | Note |
---|---|---|---|
Movie view | Add movie file readers that behave like an image reader the supports time. When viewed in a 2D image view with the time controls, ParaView becomes a simple movie viewer. | Zhanping | Lisa Ice originally requested this. We should talk to her again to get the use case/priority. |
Custom filter cleanup |
|
Zhanping/Clint | |
Shaders | Implementation in 2.6 is "experimental" and does not seem to be of any practical use to anyone. Utkarsh is working on new GPU pipeline stuff. Next generation should take advantage of that.
|
Utkarsh | |
Unordered Color maps | Some data values do not have any logical order associated with them. For example, block ids and process ids have identifiers that distinguish them, but there is no real meaning between the relationship of each pair. Thus, it makes little sense to use our standard linear color maps. A much better approach would be to map individual colors to values and show these colors as blocks in the color bar. VisIt demonstrates this quite nicely (although the colors they use aren't perfect). | Zhanping | |
Multithreaded UI | Right now, the UI pretty much works under one thread. When a pipeline update occurs, pretty much everything comes to a halt while the update happens. Likewise, a long render could cause everything to wait. We would like the ability to run pipeline updates and rendering on different threads so that the UI remains responsive.
|
Utkarsh |