ParaView 3 Telecon 04-23-2009: Difference between revisions
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 27: | Line 27: | ||
It would be nice to compare what EnSight produces versus what we produce. We should have Alan run isovolume in EnSight and save out the result. | It would be nice to compare what EnSight produces versus what we produce. We should have Alan run isovolume in EnSight and save out the result. | ||
== Ranges for temporal data == | |||
For an initial pass, we can implement basing the scalar range in the reader on the current time step and last time step. This is not perfect, but it is the 80% solution. It will fail, for example, if you slice the data and then glyph the slice. Will things of this nature be an issue? We don't know. Let us implement the simple thing and find out what the next set of problems is. | |||
This is not trivial to implement. We will start this right after the 3.6 release. If the changes are not too involved, we can make this part of a 3.6.2 release. | |||
Latest revision as of 12:39, 23 April 2009
| Item | People | Description |
|---|---|---|
| 1 | Moreland | Bi-weekly meetings? |
| 2 | Ice | MARS/V&V Milestone issues |
| 3 | Scott | Better clip-by-scalar/isovolume (Bug 8694) |
| 4 | Scott | Ranges for temporal data (Bug 8596) |
| 5 | Scott | Prism plugin |
| 6 | Thompson | Statistics Update |
Bi-weekly meetings
For the moment, the meeting agendas have been pretty empty. To save time, we will start meeting every other week.
Clip-by-scalar
Will will talk to Charles and come up with an estimate of how much it will cost to support.
It would be nice to compare what EnSight produces versus what we produce. We should have Alan run isovolume in EnSight and save out the result.
Ranges for temporal data
For an initial pass, we can implement basing the scalar range in the reader on the current time step and last time step. This is not perfect, but it is the 80% solution. It will fail, for example, if you slice the data and then glyph the slice. Will things of this nature be an issue? We don't know. Let us implement the simple thing and find out what the next set of problems is.
This is not trivial to implement. We will start this right after the 3.6 release. If the changes are not too involved, we can make this part of a 3.6.2 release.
