[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