[vtk-developers] Re: [vtkusers] Useless triangulation in unstructured grid rendering
John Biddiscombe
biddisco at cscs.ch
Wed Oct 11 11:15:41 EDT 2006
John,
It's much much easier to add an information key. All a filter needs to
do is set
outinfo->Set(vtkDataObject::DATA_GEOMETRY_NOT_MODIFIED());
(or similar name)
during execution and any filter when it executes and query its input to
see if this key is present.
If so, it can just shallowcopy the previously generated mesh back to its
output. Piece of cake really.
In fact this could be used for SCALARS_NOT_MODIFIED too if the mesh
warps, but the values stay the same.
It requires very litt changes to anything except an extra key in
vtkDataObject and any filter which uses it can check for it on a case by
case basis.
JB
> John,
>
> Knowing the filters exist is a problem but they are documented. I
> suppose another possibility is to construct a helper class using these
> filters - a bit like vtkDataSetMapper. The class could also manage a LUT
> so the range can automatically be updated when new scalars arrive.
>
> As for how you might implement such a change, presumably you would need
> to store the input id of a cell/point for each output cell/point. When I
> create UGrids, I only add point and cell field data ("node_numbers" and
> "element_numbers"). These id's can then be used at any downstream stage
> to get the required scalars. So, would I be paying for something I am
> not using?
>
> BTW I am with you 100% on the general principle of filters responding
> more specifically to a change. But on the other hand, I prefer to keep
> classes simple and well defined.
>
> John.
>
> -----Original Message-----
> From: John Biddiscombe [mailto:biddisco at cscs.ch]
> Sent: 11 October 2006 08:50
> To: John Platt
> Cc: vtk-developers at vtk.org
> Subject: Re: [vtkusers] Useless triangulation in unstructured grid
> rendering
>
> John
>
>> As you mentioned, vtkMergeFilter or vtkMergeDataObjectFilter >
>> vtkAssignAttribute already allow you to separate the geometry and
>> attribute data. So, is it worth the additional complexity and effort
>>
> of
>
>> adding a new information key for this purpose?
>>
> The trouble is that these filters must be instantiated by the user - and
>
> the user needs to "know" in advance that the pipeline has geometry
> unchanging. Adding an information key would allow filters which can take
>
> advantage of it to bypass needless geometry recalculations
> (clip/cut/surface extraction/normal generation/many more etc)
> automatically without the user necessarily knowing that the geometry is
> fixed. Only the object generating the data need do anything.
>
> It's a possibility I'd like to consider.
>
> JB
>
>
--
John Biddiscombe, email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
More information about the vtk-developers
mailing list