I’ve found that for PV pipeline sources other than vtkPolyDatas, I cannot access the vtkDataObject::DATA_TIME_STEP() information in the corresponding vtkPolyData representation in the vtkRenderer. Therefore, I currently don’t see a way to access timestep information for an actor’s geometry in a custom vtkRenderer, in case the geometry doesn’t originate from a vtkPolyData source in the PV pipeline.
The problem here is the vtkPVGeometryFilter, which produces a vtkPolyData and hands it off to the vtkGeometryRepresentationMultiBlockMaker, which then copies this data as input to a vtkPolyDataMapper (accessible from the vtkRenderer). During creation of a vtkPolyData output from an input of any type other than vtkPolyData, such as an unstructured grid, the geometry filter fails to also copy over the information key, including the data_time_step. Such a copy only occurs when the source is a vtkPolyData, during the shallow copy in ::ExecutePolyData(). But for example ExecuteUnstructuredGrid() does not copy the information.
The fix would be to just add one line at the beginning of vtkPVGeometryFilter::ExecuteBlock(), like so:
output->SetInformation(input->GetInformation());
or only copy over the vtkDataObject::DATA_TIME_STEP(). Is this possible/desirable?
This may be better fix as it will work for other representations that use a different internal filter eg. vtkUnstructuredGridVolumeRepresentation that uses vtkVolumeRepresentationPreprocessor.
However, will need to discuss with @berkgeveci if that’s a reasonable change.
@kvankooten, @berkgeveci and I had chat…so this DATA_TIME_STEP key stored in the data object’s Information is really intended for internal use by the executive and one should not be using it outside that.
Can you elaborate on why and how you’re using this information? Maybe there some other way, in ParaView’s representations perhaps, that we can more reliable provide this info.
This comes up in my attempt to convert the result of pipeline evaluation (actors in a renderview) for all timesteps into an external format. My goal is to store the resultant state, lets say it’s some geometry, of all visible actors for each “timestep” in a PV timeline, and replace those geometries as the user is interacting with PV, or add timesteps as a timeline is played.
Generally, a timestep would be equal to the vtkPVView::ViewTime. However, not all actors in a pipeline change their geometry from one timestep to another. They can be static, or with a filter such as “force time” the result could potentially change between arbitrary subsets of a timeline. The only way in which I can detect this is by looking at the DATA_TIME_STEP, and keep a mapping between the global timestep (ViewTime) and the DATA_TIME_STEP for each actor. This in fact gives me quite a bit of flexibility.
It’s not perfect, because a pipeline with geometry that changes only at discrete timesteps can still alter the value of DATA_TIME_STEP at the output between fractional steps, even though geometry is not fundamentally changed, but this is something I can work around. This is also related to another issue where the normal PV cache often contains double entries for fractional timeline values that have been rounded off slightly differently (I’m not sure if the new caching system changes all this).
I agree that it doesn’t quite seem like the correct way to go about it, but from a higher perspective I somehow need to have an indication of the “maximum” of the source/input’s timesteps for one single output geometry that results from pipeline evaluation (ie. the lower bound of the time-range for that geometry on the timeline). This I can use in case the geometry changes, so that I know whether to replace the original geometry at that maximum input timestep due to user changes, or instead leave the earlier geometry unchanged and add a new geometry at a later timestep because it’s just the result of a new timestep evaluation.
With ParaView master, following merge of the changes here, the MTime for the input data object to the mapper will not change unless the data indeed changed as view time changed. This may help you make this distinction between time varying and non-varying datasets.
That will definitely be an improvement upon what I currently have. However, the way I currently understand it, I would still need the DATA_TIME_STEP information to know whether this MTime change is a result of the timestep change, or related to a change of parameters somewhere down the line for the original DATA_TIME_STEP.
For example, if there is an actor in the pipeline with geometry that is so far observed to always have the same DATA_TIME_STEP=0 and MTime regardless of the timestep that the pipeline is in, and the pipeline timestep is not 0 at a particular moment; if the MTime changes but DATA_TIME_STEP remains 0 I would know as an observer that I have to replace the original geometry for the whole timeline. If DATA_TIME_STEP didn’t remain at 0, the geometry can be added as a new timestep for that particular actor and the original geometry at 0 remains. I’m not quite sure how I would make that distinction without the DATA_TIME_STEP information.