[vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT

Berk Geveci berk.geveci at kitware.com
Mon Jan 4 15:11:44 EST 2016


OK this sounds like a bug. Is your pipeline only source ->
vtkGeometryFilter or is there something in between? I'll try to reproduce
this with a Python source once I know what the pipeline is.

Best,
-berk

On Mon, Jan 4, 2016 at 12:25 PM, Bill McGrory <mcgrory at aerosoftinc.com>
wrote:

> I think I am doing what you say should work.
>
> My personal data outside of VTK changes as a result of a user requested
> change from say the fine representation to the coarse. That change triggers
> a someSource->Modified(). that seems to correctly trigger a call to
> RequestInformation on someSource, which is when I modify WHOLE_EXTENT().
>
> What I see is that WHOLE_EXTENT correctly propagates downstream, however,
> there is no change to the UPDATE_EXTENT as a result of the WHOLE_EXTENT
> being reduced. So when  RequestUpdateExtent propagates back upstream, I get
> the error for it being out of range, with the WHOLE_EXTENT value being the
> new correct value. and UPDATE_EXTENT being the old value.
>
> Note my error is triggered at someSource->RequestUpdateExtent()
>
> Note the someFilterDownstream is a vtkGeometryFilter, and if I make a call
> to correct the UPDATE_EXTENT in the geometry filter to be in range
> WHOLE_EXTENT from vtkGeometryFilter::RequestUpdateExtent() then that fixes
> my bug, but this is only for vtkGeometryFilter, not a generic downstream
> filter.
>
>
>
>
>
>
> On 01/04/2016 11:46 AM, Berk Geveci wrote:
>
> So when the WHOLE_EXTENT() changes, you tell the source/reader by
> modifying it somehow? What I am trying to get to is whether or not this
> works:
>
> someSource->SetNewData();
> someSource->Modified()
> someFilterDownstream->Update();
>
> someSource->SetNewData();
> someSource->Modified()
> someFilterDownstream->Update();
>
> I believe that as long as the source is modified after the WHOLE_EXTENT()
> changes, update should work fine. Because this would lead to
> RequestInformation() being called again, which is what propagates the new
> WHOLE_EXTENT() downstream.
>
> Best,
> -berk
>
> On Mon, Jan 4, 2016 at 11:39 AM, Bill McGrory <mcgrory at aerosoftinc.com>
> wrote:
>
>> I  have a pipeline for displaying structured zones within a GUI. These
>> zone's have multiple grid refinement levels or sequences. The beginning of
>> the pipeline is a source which creates a vtkStructuredGrid.
>>
>> When I interactively change the sequence level the source gets a call to
>> update the pipeline where I need to change the vtkStructuredGrid to
>> represent a different sequence level (so my grid grid dimensions will
>> double or halve, for example)
>>
>> This process worked (by accident perhaps) in versions of VTK prior to 6.
>>
>> Thanks
>> Bill
>>
>>
>>
>> On 01/04/2016 11:08 AM, Berk Geveci wrote:
>>
>> Hey Bill,
>>
>> The very short (and annoying) answer is that VTK does not currently
>> support varying WHOLE_EXTENT().
>>
>> However, there are ways of getting around this. But before I get into
>> those, can you describe how/where you change the whole extent? As part of a
>> time update? By setting some data member on the reader?
>>
>> Best,
>> -berk
>>
>> On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory < <mcgrory at aerosoftinc.com>
>> mcgrory at aerosoftinc.com> wrote:
>>
>>>  I am having difficulty porting some code from VTK 5 to 6.
>>>
>>> I have a custom algorithm for creating  a vtkStructuredGrid as the
>>> source for my pipeline, so my class inherits vtkStructuredGridAlgorithm
>>>
>>> my pipeline simply connects the vtkStructuredGridAlgorithm to a
>>> vtkGeometryFilter which is mapped with a vtkPolyDataMapper
>>>
>>> I want my source to correctly render a structured grid which changes
>>> dimensions dynamically within my application.
>>>
>>> My problem is that  if I originally set up the grid with say extents of
>>> 0 --99, 0-->99,  0-->99, and then change the extents to 0--49, 0-49,0-49
>>> through a call to Update, then I get a VTK error message from
>>>
>>>
>>> ERROR: In
>>> VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line
>>> 860
>>> vtkCompositeDataPipeline (0xb4561f0): The update extent specified in the
>>> information for output port 0 on algorithm SurfaceSNodeSource(0xb455750) is
>>> 0 80 0 32 0 0, which is outside the whole extent 0 40 0 16 0 0.
>>> (This is in VerifyOutputInformation) called before the
>>> RequestUpdateExtent for my algorithm.
>>>
>>> I don't quite understand the propagation of the UPDATE_EXTENT
>>> information up the pipeline, but if I set the UPDATE_EXTENT to WHOLE_EXTENT
>>>
>>> in vtkGeometryFilter::RequestUpdateExtent
>>>
>>> then the error goes away.
>>> Also, at the time of calling vtkGeometryFilter::RequestUpdateExtent, the
>>> UPDATE_EXTENT is still set at the old value, while the WHOLE_EXTENT has
>>> been correctly updated/propagated from upstream.
>>>
>>> Is this a bug, or do I need to change something in my
>>> vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to be reset at the
>>> origin downstream?
>>>
>>> Thanks
>>>
>>> Bill
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> <http://www.kitware.com/opensource/opensource.html>
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at:
>>> <http://markmail.org/search/?q=vtk-developers>
>>> http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>
>> --
>> Dr. William D. McGrory    AeroSoft, Inc.mcgrory at aerosoftinc.com   Suite 1400(540) 557-1904            2000 Kraft Drive(540) 557-1919 (FAX)      Blacksburg, VA 24060
>>
>>
>
> --
> Dr. William D. McGrory    AeroSoft, Inc.mcgrory at aerosoftinc.com   Suite 1400(540) 557-1904            2000 Kraft Drive(540) 557-1919 (FAX)      Blacksburg, VA 24060
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160104/07831f84/attachment-0001.html>


More information about the vtk-developers mailing list