[vtk-developers] Marking data modified

[Shawn Waldon]

Will,

See my merge request here:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1818 for that change.  I
didn't get rid of the line that marks the polydata as updated because I
think the old rendering backend needs it.  I was planning to add these docs
changes to the same branch as soon as I figure out what else needs changing.

Shawn

On Mon, Aug 15, 2016 at 2:53 PM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> Why can't you instead of:
>
>     this->HexFacePolyData->Modified();
>     cells->ReplaceCell(0,npts,pts)
>
> do:
>
>     cells->Modified();
>     cells->ReplaceCell(0,npts,pts)
>
> Best,
> W
>
>
>
> On Mon, Aug 15, 2016 at 2:48 PM, Shawn Waldon <shawn.waldon at kitware.com>
> wrote:
>
>> See the example script on this bug report: https://gitlab.kitware.com/vtk
>> /vtk/issues/16812.  It is calling Modified() on the polydata, but to
>> actually see the updated geometry, you have to add
>> pdata.GetPolys().Modified().  And I can only say that for sure because I
>> know the cell in question is polygonal.  ReplaceCell doesn't tell the
>> caller which cell array needs to be updated.
>>
>> Shawn
>>
>> On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>>
>>> Can you provide a bit more detail? Who's MTime is important in this
>>> case? Note that vtkPolyData does not take into account the MTime of the
>>> underlying vtkCellArrays when computing its own MTime. So if the MTime of
>>> the polydata is becoming stale, simply calling Modified() on it should be
>>> sufficient. As far as I can tell, vtkCellArray does nothing with MTime.
>>>
>>> On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon <shawn.waldon at kitware.com>
>>> wrote:
>>>
>>>> Thanks David & Berk,
>>>>
>>>> Ok, I'll add a commit to my branch to update the docs and add you as
>>>> reviewers.  I have a follow-up question though:  vtkPolyData::ReplaceCell.
>>>> This function figures out which cell array the cell is in and then calls
>>>> ReplaceCell on that one.  It can be in Verts, Lines, Polys, or Strips.  So
>>>> the caller may not know which cell array to call Modified on.  What should
>>>> we do in this case?
>>>>
>>>> Shawn
>>>>
>>>> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci <berk.geveci at kitware.com>
>>>> wrote:
>>>>
>>>>> I agree with David.
>>>>>
>>>>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers <
>>>>> vtk-developers at vtk.org> wrote:
>>>>>
>>>>>> I don't specifically know the answer to this one, but in general,
>>>>>> these sorts of things are on purpose for performance in VTK.
>>>>>>
>>>>>> If you want to replace 100 (or even more) cells, you'd want
>>>>>> ReplaceCell NOT to call Modified, and just do it once at the end of
>>>>>> your bulk replacement. I'd be surprised if somebody chimed in and
>>>>>> contradicted this... so I would think just fixing the docs is the
>>>>>> right way to go here.
>>>>>>
>>>>>>
>>>>>> HTH,
>>>>>> David C.
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon <
>>>>>> shawn.waldon at kitware.com> wrote:
>>>>>> > Hi all,
>>>>>> >
>>>>>> > I have been tracking down a bug in the vtkBoxRepresentation where
>>>>>> the
>>>>>> > selected face never updated.  The issue was that the widget was
>>>>>> calling
>>>>>> > ReplaceCell on the vtkCellArray for the selected face polydata, but
>>>>>> never
>>>>>> > calling Modified() on the cell array (though it did call Modified()
>>>>>> on the
>>>>>> > polydata).  With the new OpenGL backend this matters.  The
>>>>>> documentation for
>>>>>> > ReplaceCell doesn't say that you have to do this afterward and the
>>>>>> writer of
>>>>>> > vtkBoxRepresentation used that documentation.
>>>>>> >
>>>>>> > So my question is this: why doesn't ReplaceCell mark the cell array
>>>>>> as
>>>>>> > modified? Is this a bug or on purpose for performance reasons?  I
>>>>>> will
>>>>>> > update the docs or fix ReplaceCell once I know which is wrong.
>>>>>> >
>>>>>> > Thank you,
>>>>>> > Shawn
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Powered by www.kitware.com
>>>>>> >
>>>>>> > Visit other Kitware open-source projects at
>>>>>> > http://www.kitware.com/opensource/opensource.html
>>>>>> >
>>>>>> > Search the list archives at: http://markmail.org/search/?q=
>>>>>> vtk-developers
>>>>>> >
>>>>>> > Follow this link to subscribe/unsubscribe:
>>>>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>> >
>>>>>> >
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>>> vtk-developers
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc. - Building the World's Technical Computing Software
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160815/1ee52fda/attachment-0001.html>