ParaQ v1.0 Features: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
List of features we'll need in future versions (no matter how outlandish they seem ... we can prioritize anything :) ) - things that occur to you as you're testing, coding, or using ParaQ. | List of features we'll need in future versions (no matter how outlandish they seem ... we can prioritize anything :) ) - things that occur to you as you're testing, coding, or using ParaQ. | ||
= | =Goals= | ||
We have the following goals for the ParaQ v1.0 release, scheduled for the end of Q3 FY06 | |||
* It will be a useful replacement for ParaView. | |||
** It may not include every feature of ParaView. | |||
** It will include ParaView features that the Product Board has agreed are highest priority. | |||
* ParaQ v1.0 release will run in serial and parallel modes on: | |||
** Required SRN machines | |||
** Linux | |||
** Windows XP | |||
==Big Issues== | |||
Discussion from first [[Product Board Mtg. 02/16/2006 1PM EST | meeting with Product Managers]] | |||
* 3D WIdgets | |||
* Volume Rendering Widgets | |||
* Disconnect/Re-connect (not an SNL high priority item for v1.0) | |||
* Selection | |||
* Time | |||
* Undo/Redo | |||
Additional items, not expected for this release: | |||
* Connect/reconnect | |||
* Multiple Clients. | |||
* Multiple Servers. | |||
==Prioritized Feature List== | |||
* Filters | |||
** Are there any that needn't be in a v1.0 release? | |||
** Will we be able to fix overall filter issues like the 'point to cell' and 'cell to point' problems? | |||
* Multiple views | |||
** Linking of cameras, timesteps | |||
* Upgrade path | |||
** ParaQ v1.0 will support reading of ParaView 2.6 state files. (is this correct and sufficient?) | |||
* Scripting (requirements unknown) | |||
* Compound filters | |||
** Manage and create from UI (create new, save changes to existing, load/unload, set 'autoload' flag) | |||
* Hierarchical User Settings | |||
* Animation/movie making | |||
** What subset of current functionality must be present in v1.0? Perhaps not the full-on Animation UI we currently have in ParaView? Can this be a follow-on? | |||
* Selection | |||
** Rubber band selection, single Node/Cell picking (supported within a | |||
* Global ID | |||
* Time Support | |||
* Parallel graphing support | |||
* Undo/Redo | |||
=Requested Feature List= | |||
This is a preliminary place to record these - we will formalize this process before our March start date. | |||
{| cellpadding="2" cellspacing="4" style="backround:#efefef" | {| cellpadding="2" cellspacing="4" style="backround:#efefef" | ||
|- | |- | ||
| Line 22: | Line 69: | ||
| 1 | | 1 | ||
| Grouping of pipeline elements. I would like to be able to 'group' filters together, and treat them as a single entity. A known use of this would be in creating 'parts', which would be groups of cells from the input data set. A user might want to create other logical gropus that are not represented in the data, and controls these things together. Also, other operations make sense on grouped items. If I want to look at a dataset and see the cell edges at the same time I see the cells, I'll connect dataset->ExtractEdges. Now, if I want to clip both of those things, I want to create a 'group' for both filters, then operate on that group. I should be able to do this with a single cut plane widget. Certainly, the user could clip the dataset, and then the ExtrctEdges would naturally be clipped as well, but the 'logical' step is to slice through 'all the stuff at once', and I believe that the group might make more sense than the 'slice the input and the rest will follow' approach. | | Grouping of pipeline elements. I would like to be able to 'group' filters together, and treat them as a single entity. A known use of this would be in creating 'parts', which would be groups of cells from the input data set. A user might want to create other logical gropus that are not represented in the data, and controls these things together. Also, other operations make sense on grouped items. If I want to look at a dataset and see the cell edges at the same time I see the cells, I'll connect dataset->ExtractEdges. Now, if I want to clip both of those things, I want to create a 'group' for both filters, then operate on that group. I should be able to do this with a single cut plane widget. Certainly, the user could clip the dataset, and then the ExtrctEdges would naturally be clipped as well, but the 'logical' step is to slice through 'all the stuff at once', and I believe that the group might make more sense than the 'slice the input and the rest will follow' approach. | ||
|- | |||
|- | |||
| 004 | |||
| 1 | |||
| Filter On/Off switch. As we expand the capabilities of compound filters, we will need the ability to turn filters on and off, while still having them connected in a graph. A filter that is 'on' performs its normal function. A filter that is 'off' passes its data through (the filter may have to perform some default transformation) The reason for this is that PQ must support a compound filter that encapsulates these filters: InputData->Clip->Threshold->Glyph. In the object inspector for this compound filter, the designer (of the compound filter) may want to give the user the ability to (Clip AND Threshold), Clip, or Threshold. PQ should not be responsible for unhooking and re-hooking the pipelines - the simple solution is to turn off the appropriate filters without re-arranging the pipeline. | |||
|- | |- | ||
|} | |} | ||
Latest revision as of 12:55, 21 February 2006
List of features we'll need in future versions (no matter how outlandish they seem ... we can prioritize anything :) ) - things that occur to you as you're testing, coding, or using ParaQ.
Goals
We have the following goals for the ParaQ v1.0 release, scheduled for the end of Q3 FY06
- It will be a useful replacement for ParaView.
- It may not include every feature of ParaView.
- It will include ParaView features that the Product Board has agreed are highest priority.
- ParaQ v1.0 release will run in serial and parallel modes on:
- Required SRN machines
- Linux
- Windows XP
Big Issues
Discussion from first meeting with Product Managers
- 3D WIdgets
- Volume Rendering Widgets
- Disconnect/Re-connect (not an SNL high priority item for v1.0)
- Selection
- Time
- Undo/Redo
Additional items, not expected for this release:
- Connect/reconnect
- Multiple Clients.
- Multiple Servers.
Prioritized Feature List
- Filters
- Are there any that needn't be in a v1.0 release?
- Will we be able to fix overall filter issues like the 'point to cell' and 'cell to point' problems?
- Multiple views
- Linking of cameras, timesteps
- Upgrade path
- ParaQ v1.0 will support reading of ParaView 2.6 state files. (is this correct and sufficient?)
- Scripting (requirements unknown)
- Compound filters
- Manage and create from UI (create new, save changes to existing, load/unload, set 'autoload' flag)
- Hierarchical User Settings
- Animation/movie making
- What subset of current functionality must be present in v1.0? Perhaps not the full-on Animation UI we currently have in ParaView? Can this be a follow-on?
- Selection
- Rubber band selection, single Node/Cell picking (supported within a
- Global ID
- Time Support
- Parallel graphing support
- Undo/Redo
Requested Feature List
This is a preliminary place to record these - we will formalize this process before our March start date.
| ID | Prority | Description |
|---|---|---|
| 001 | 1 | View/Application snapshot. This should include useful tags in image formats that support them. |
| 002 | 1 | Applicatin/User settings hierarchy, including entries for 1) last data file directory, 2) last place images were saved |
| 003 | 1 | Grouping of pipeline elements. I would like to be able to 'group' filters together, and treat them as a single entity. A known use of this would be in creating 'parts', which would be groups of cells from the input data set. A user might want to create other logical gropus that are not represented in the data, and controls these things together. Also, other operations make sense on grouped items. If I want to look at a dataset and see the cell edges at the same time I see the cells, I'll connect dataset->ExtractEdges. Now, if I want to clip both of those things, I want to create a 'group' for both filters, then operate on that group. I should be able to do this with a single cut plane widget. Certainly, the user could clip the dataset, and then the ExtrctEdges would naturally be clipped as well, but the 'logical' step is to slice through 'all the stuff at once', and I believe that the group might make more sense than the 'slice the input and the rest will follow' approach. |
| 004 | 1 | Filter On/Off switch. As we expand the capabilities of compound filters, we will need the ability to turn filters on and off, while still having them connected in a graph. A filter that is 'on' performs its normal function. A filter that is 'off' passes its data through (the filter may have to perform some default transformation) The reason for this is that PQ must support a compound filter that encapsulates these filters: InputData->Clip->Threshold->Glyph. In the object inspector for this compound filter, the designer (of the compound filter) may want to give the user the ability to (Clip AND Threshold), Clip, or Threshold. PQ should not be responsible for unhooking and re-hooking the pipelines - the simple solution is to turn off the appropriate filters without re-arranging the pipeline. |
Requirements
| ID | Prority | Description |
|---|---|---|
| 001 | 1 | ParaQ should be able to automatically generate a complete object inspector UI for each filter. Currently, the inspector generated for the Clip filter is insufficient - there is no UI to control the implicit function object it needs to work. The Glyph filter is another one like this - it needs an input glyph object. |
