Item | Description | Screen shot | Versions | Reported? | Fixed? |
---|---|---|---|---|---|
1 | Plane source has no graphical manipulator, it's extremely tedious to have to manipulate the plane source by hand through text entry boxes. The plane source is defined by an origin and two axis points, the current defaults are to fixed values that have no relation to the current visualisation. At the very least this source should have a manipulator similar too the "slice" filter, in addition to the the text entries. The manipulator could then be used for rough placement and visual feed back, and the text entries could be used for fine tuning. Solution develop a manipulator that allows for graphical positioning of the plane. Use upstream bounds to create reasonable default values. Note: The existing slice manipulator will not be suitable since it uses a center + normal for positioning while the plane source uses 3 points. Using 3 points differs in that a parallelogram is defined and bounds are implicit. I looked into using the existing slice manipulator and found that it's not clear which points to use when configuring the plane source for example see: . The plane source manipulator should consist of 3 points, and origin and two axis points, and some sort of handle for rotation. | 3.4,3.7 | No | No | |
2 | Multiple input dialog is confusing and difficult to use. In 3.4 only the first input (called input) can select multiple items, while the second input (called source) cannot select multiple items. Attempting to to select multiple items on the second input , which is a common use case for the stream traces, results in a crash (3.4 only). Changing selection on the second input results in error messages and a crash. The pipeline preview is confusing, there should be a much simpler and clearer way to graphically represent the pipeline for filters with multiple inputs. The following error is reported frequently and preceeds the crashes: QAbstractItemModel::endRemoveRows: Invalid index ( 3 , 0 ) in model pqPipelineModel(0x2f93de0) | 3.4,3.7 | No | No | |
3 | No way to duplicate a source. Say you have configures a plane source, it would be useful to be able to right click its icon in the pipeline browser and then have a context menu option to duplicate. | 3.4,3.7 | No | No | |
4 | No way to save and restore a source. It would useful to be able to save and restore individual sources, independent of the application state. Often we need the same sources over and over, it would be a time-saver to define once save then reuse across sessions. Eg. Need to create a sphere source represnting an inner ionosperic boundary in a simulation, the sphere source will have the same configuration across many runs. | 3.4,3.7 | No | No | |
5 | No way to cancel from save animation. For long time series where individual time steps are large, saving animation of time series take an extended potentially hours of time, this will leave the U.I. in a useless state, with no option to cancel, except to kill the severs. Feedback is provided via the progress bar, but could be better. | 3.4,3.7 | No | No | |
6 | Saving state for DistributedStreamTracer
Warning: In /home/burlen/ext/ParaView/ParaView3/Servers/ServerManager/vtkSMStateVersionController.cxx, line 826 vtkSMStateVersionController (0x3c53570): Your state file uses (vtk)StreamTracer. vtkStreamTracer has undergone considerable changes in 3.8 and it's possible that the state may not be loaded correctly or some of the settings may be converted to values other than specified. |
3.7 | No | No | |
7 | Poor implementation of parallel field/stream line generation. It is really 100% serial implementation and very inefficient. Each seed point is processed serially, across each process one by one. The is plenty of room to realise speed up by parallelizing the algorithm. Each process can concurrently generate lines for seeds it owns (seeds are one to one). The seeds that do not terminate can be "gather all" and again processed concurrently. Continuing until all seeds terminate. The comment in the current implementation sums it up well: // .NAME vtkDistributedFiledTracer - Distributed streamline generator // .SECTION Description // This filter integrates streamlines on a distributed dataset. It is // essentially a serial algorithm: only one process is active at one // time and it is not more efficient than a single process integration. // It is useful when the data is too large to be on one process and // has to be kept distributed. // .SECTION See Also // vtkStreamTracer vtkPStreamTracer |
3.4,3.7 | No | No | |
8 | Stream tracer traces outside of dataset. Why not stop at the edge of the dataset? It's not simnple overshoot but rather two steps are taken outside the dataset. | 3.7 | No | No |
BUGS[]
Bug: vtkSquirtCompressor.cxx reads off the end of the input array because while loop condition doesn't account for the mutiple advances of index. // Go through color buffer and put RLE format into compressed buffer while((index < 3*numPixels) && (comp_index < end_index)) { int next_color = 0; // Record color unsigned char* p = (unsigned char*)¤t_color; *p++ = _rawColorBuffer[index]; *p++ = _rawColorBuffer[index+1]; *p++ = _rawColorBuffer[index+2]; *p = 0x0; _rawCompressedBuffer[comp_index] = current_color; index+=3; p = (unsigned char*)&next_color; *p++ = _rawColorBuffer[index]; *p++ = _rawColorBuffer[index+1]; *p++ = _rawColorBuffer[index+2]; *p = 0x0; // Compute Run while(((current_color&compress_mask) == (next_color&compress_mask)) && (index < 3*numPixels) && (count<255)) { index+=3; count++; if (index < 3*numPixels) { p = (unsigned char*)&next_color; *p++ = _rawColorBuffer[index]; *p++ = _rawColorBuffer[index+1]; *p++ = _rawColorBuffer[index+2]; *p = 0x0; } }