[vtk-developers] Marking data modified

Mon Aug 15 15:16:40 EDT 2016

There are lots of possible solutions, another is to build a next generation
unstructured grid data structure that supports adaptive, on-demand
construction of topology (sort of like polydata does now with cell links,
etc.) including explicit, adaptive representation of edges and faces. It
could support both polygonal (i.e., graphics representations) and meshes
(combinations of 0-3D cells). We've experimented with this and shown good
early results. The original polydata structure was designed probably 25
years ago and was targeted at the graphics systems of the time; we
initially thought that if it lasted 10 years it would be an achievement.
It's time to begin the great migration IMO, we need to think bigger  :-)

Best,
W

On Mon, Aug 15, 2016 at 3:07 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Argh I hate vtkPolyData. Yeah, if the rendering code is looking at the
> MTime of the cell arrays, the caller has to know which one got modified and
> call Modified() on it. Hopefully, sometime not too long in the future, we
> can find a way of separating the various cell arrays into their own data
> objects and not have this mess.
>
> On Mon, Aug 15, 2016 at 2:57 PM, Shawn Waldon <shawn.waldon at kitware.com>
> wrote:
>
>> 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
>>>
>>
>>
>

-- 
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/31ccfe7e/attachment-0001.html>