[Paraview-developers] Change in behavior

Reuter, Michael A. reuterma at ornl.gov
Tue Feb 28 16:27:27 EST 2012


Adding the plane->UpdateVTKObjects() after modifying the properties makes
the issue with the misplaced representation go away. I've added the extra
lines to my 3.10 code to see the difference. I still see that
representation isn't drawn in 3.10 versus 3.12. Not sure I care since the
odd behavior went away.

I also had an idea to make the plane addition automatic by using the
pqProxyTabWidget::getObjectInspector().accept() to which I have a signal
(triggerAccept) that is attached. So I added this->renderAll() and emit
this->triggerAccept() to the end of the makeCut call. This automatically
applies the cut, but the Apply button is still lit. Now, I thought that is
exactly what I just did, but obviously my assumption is incorrect. I do
this when loading data and the Apply button is disabled at the end of the
call, so I don't understand about what looks like an extra update. How can
I fix this? This extra update has implications below.


I also changed the last line in updateCutPosition from
cut->getProxy()->UpdateVTKObjects() to plane->UpdateVTKObjects() and I get
back the behavior of the representation being drawn as plane moves.

We're almost there if I can figure out why the Accept button is being lit
while using the plane moving mechanism. In 3.10, the updateCutPosition
function never triggered the Apply button, but in 3.12 it does. The
biggest issue comes when I finish moving the indicator and release the
mouse button, the Apply button is still lit. I have a selection rectangle
over the indicator which should disappear when the mouse button, but no
longer does. I have an unsupported feeling that the Apply button somehow
interferes with the mouseReleaseEvent for the indicator. Adding the
triggerAccept mechanism doesn't seem to help any. Is there any way to stop
the Apply button from being enabled?


Thanks,
M


On 2/28/12 10:25 AM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:

>I noticed that you're missing a plane->UpdateVTKObjects() call in
>makeCut() method. After changing any property(ies) of a proxy, one has
>to call UpdateVTKObjects() to "push" those property changes to the VTK
>objects.
>
>Utkarsh
>
>On Tue, Feb 28, 2012 at 6:11 AM, Reuter, Michael A. <reuterma at ornl.gov>
>wrote:
>> Hi Utkarsh,
>>
>>        I've tried all combinations of pqRenderView::render(),
>> pqPipelineRepresentation::renderView() and
>> pqPipelineSource::renderAllViews() and I still get the same behavior. I
>> tried adding the accept triggering mechanism to fix the first problem of
>> the misplaced cut representation location. While that stopped the
>> misplaced representation from appearing, I still had to hit the Apply
>> button in spite of doing that automatically. A second update is being
>> requested and I don't understand where it came from.
>>
>> M
>>
>>
>>
>> On 2/27/12 2:42 PM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com>
>>wrote:
>>
>>>Michael,
>>>
>>>I think you're missing calls to view->render() after have updates the
>>>cuts. Earlier, this was forgiven since ParaView would render with the
>>>screen got refresh one way or another. Thus causing updates and
>>>rendering more often than needed. Now ParaView only render when told
>>>to update (for the most part) and hence, if you change the slice/add a
>>>new cut filter, but don't call view->render() or
>>>repr->renderAllViews() (writing from memory, so I might have named the
>>>methods wrong), then the view may not update. I wonder if that's what
>>>you're seeing.
>>>
>>>Utkarsh
>>>
>>>On Mon, Feb 27, 2012 at 7:56 AM, Reuter, Michael A. <reuterma at ornl.gov>
>>>wrote:
>>>> Hi,
>>>>
>>>> While trying to get our application up and running in 3.12, I've run
>>>>into two more issues. We have a display that allows one to add
>>>>plane-aligned cuts to data at a given location by clicking on an axis
>>>>widget. After one cut has been added and applied, I then added a second
>>>>cut on another axis. Before hitting apply, what I see is in the
>>>>attached
>>>>screenshot. The plane outline is in the correct location and
>>>>orientation, but the representation appears (in 3.10 it didn't appear)
>>>>and is aligned on the origin of the orientation axes and oriented with
>>>>default parameters. After I hit apply, the representation appears in
>>>>the
>>>>correct location and orientation. My questions are why doesn't the
>>>>representation and plane outline both have the same location and
>>>>orientation and why does the representation now show up? The relevant
>>>>code that creates the cuts is found in the makeCut function in the
>>>>attached code file. Is there a better way to create the cuts in 3.12?
>>>>
>>>> My second issue comes about with our cut updating mechanism for this
>>>>display. When one selects and moves the one of the blue indicators (see
>>>>screenshot), the cut is automatically updated to reflect the new
>>>>position in both outline and representation. See the updateCutPosition
>>>>function for more details. This worked quite well in 3.10. In 3.12, as
>>>>soon as the indicator is moved, only outline is moved and the apply
>>>>button lights up. In order to recover the old behavior, I have a
>>>>mechanism to trigger the apply button that I can add at the end of the
>>>>updateCutPosition, but this results in an annoying flashing of the
>>>>corresponding entry in pipeline browser. Is there any way to recover
>>>>the
>>>>old non-flashing behavior?
>>>>
>>>> I apologize for hitting the list the last few days, but we're trying
>>>>to
>>>>move to 3.12 so we don't have to distribute a patched version of
>>>>ParaView for our application. We had some fixes that make our
>>>>application work, but they didn't make it into the 3.10.1 release.
>>>>
>>>> Thanks,
>>>> M
>>>>
>>>> Dr. Michael Reuter
>>>> Data Analysis and Visualization Group
>>>> Neutron Data Analysis and Visualization Division
>>>> Oak Ridge National Laboratory
>>>>
>>>> Office: 1-865-241-7216
>>>> Fax: 1-865-574-6080
>>>> Email: reuterma at ornl.gov
>>>>
>>>> _______________________________________________
>>>> Paraview-developers mailing list
>>>> Paraview-developers at paraview.org
>>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>



More information about the Paraview-developers mailing list