[Paraview] qvtk problems with the pipeline

[Dominik Szczerba]

So that other poor souls save some time... the problem was this single 
line of code executed at the beginning of the apply function:

image->GetPointData()->SetActiveScalars(comboBoxFieldName->currentText().toStdString());

I would not expect setting the active scalars to modify the object, but 
doing my own bookkeeping for the scalar name (and calling this line only 
when the value really changes) fixes it.

Interestingly, this also solved the problem with the update extents. 
While I am glad I had solved it - and am grateful for the very useful 
hints I received - I would still allow myself to complain at the ease 
with which it is possible to make errors and at the difficulties to find 
them quickly... (this is in the context of our recent (very hot :) 
discussions over here to eventually switch the whole visualization group 
to work with VTK and not raw OpenGL - and those points are always the 
counter arguments of my opponents...)

with regards,
Dominik
regards,
Dominik

Dominik Szczerba wrote:
> ... having now come back to the original implementation (Update gathers 
> parameters, pipeline re-executes always waisting time) I recalled one 
> more problem I was having with it before:
> 
> vtkStreamingDemandDrivenPipeline (0xa14ee18): The update extent 
> specified in the information for output port 0 on algorithm 
> vtkExtractVOI(0xa14e760) is 62 325 104 272 88 167, which is outside the 
> whole extent 63 324 105 271 89 166.
> 
> which is really driving me mad as I can google out absolutely no 
> conclusions on this frequently raised issue. Migrating to signal/slots 
> resolved this issue (while creating new ones...)
> 
> with regards,
> Dominik
> 
> Dominik Szczerba wrote:
>> Clinton Stimpson wrote:
>>> On 08/01/2009 05:01 AM, Dominik Szczerba wrote:
>>>> Many thanks for the feedback. Pls see below:
>>>>
>>>> Clinton Stimpson wrote:
>>>>> Dominik Szczerba wrote:
>>>>>> My pipeline works all right and gets updated on demand properly. I 
>>>>>> achieve it by connecting spinboxes/lineedits etc. to functions that 
>>>>>> set parameters of my filters before I explicitly hit the final 
>>>>>> 'apply' button. The annoying problem is that the pipeline gets 
>>>>>> executed also when I interact with the render window (click to 
>>>>>> rotate etc.). I did not (intend to) set up such functionality, I 
>>>>>> want the pipeline to execute only after an explicit button click 
>>>>>> (like in paraview). How do I find out who is triggering the pipeline 
>>>>>> behind my back?
>>>>>>
>>>>>> - Dominik
>>>>>>
>>>>> ParaView queues up the changes, and only applies them to the filters 
>>>>> when the apply button is pressed.
>>>>> If you're applying them on the filters when spinboxes/lineedits 
>>>>> change, and a menu comes and goes over the graphics view, that could 
>>>>> trigger an update you might not want.
>>>>>
>>>>> How about your apply button gathering the parameters from the widgets 
>>>>> on the form and applying them?
>>>> That was my original idea and implementation: However, this way the 
>>>> WHOLE pipeline ALWAYS gets re-executed. Concrete example pipeline: 
>>>> extractVOI->GaussianSmooth. If Apply button gathers the parameters and 
>>>> sets them to the filters every time, changing e.g. only smoothing 
>>>> params (while keeping the same VOI) still causes both filters to 
>>>> re-execute. This should not happen, as VOI should be up to date. The 
>>>> same is true for more filters, e.g. Threshold: re-feeding the same 
>>>> parameters and/or arrays to process somehow fools the up-to-date'ness 
>>>> of the filter. Am I expected to walk around the problem by bookkeeping 
>>>> the changing params and the up-to-date'ness myself?
>>>>
>>>> Note that this is different to paraview, where you have only one 
>>>> filter per menu entry and can explicitly request changes. Here I have 
>>>> one meta-filter, consisting of several atomic ones.
>>>>
>>>> After your remark I feel the original approach was the right one. But 
>>>> then how do I only request the update if a REAL CHANGE and not only a 
>>>> FORMAL SET of parameters is the case?
>>>>
>>> vtkSetMacro checks for changes before calling this->Modified();  But are 
>>> you saying its a problem because not all Set functions check for changes?
>> I am saying that (e.g.) setting VOI in vtkExtractVOI or 
>> InputArrayToProcess in vtkThreshold to the already previously set values 
>> (no factual change, just re-feed of the old ones) triggers the pipeline 
>> to re-execute. I do not understand this behavior as I was - as you point 
>> out - hoping for the set macros to take care of that.
>>
>>> To do your own bookkeeping, one idea is to connect to the QWidget's user 
>>> property's notify signal (see QMetaObject::userPropery), and anytime one 
>>> of those fires, you add to a list of widgets that have changed.  Then at 
>>> apply time, just push those values down.
>>>
>> A little above my knowledge level but many thanks for the pointers to 
>> start with!
>>
>> Overall, many thanks for valuable insights.
>>
>> -- Dominik
>>
>>> Clint
>>>
>>>
>>
> 
> 


-- 
d o m i n i k   s z c z e r b a ,   p h d . . . . . . . . . . .
c o m p u t a t i o n a l   l i f e   s c i e n c e   g r o u p
. . . . . . . i t ' i s   r e s e a r c h   f o u n d a t i o n
. . . . . . . . . . . . . . . . . . . . http://www.itis.ethz.ch