[vtk-developers] New nonlinear celltypes

Soeren Gebbert soeren.gebbert at inpro.de
Tue Dec 20 10:07:20 EST 2005


Hi,
many thanks for your answers and suggestions.

David C. Thompson wrote:

>>One question I have on the use of a generic cell adaptor approach is the
>>recovery of the original cell edges for use in wire frame views. In VTK
>>4, I use an unstructured grid surface filter which preserves nonlinear
>>faces and saves Face Id's which are used in edge filters to detect
>>boundary edges and internally triangulated edges.
>>    
>>
>There isn't an equivalent filter for the generic dataset yet. The
>closest matches are the vtkGenericGeometryFilter (doesn't store cell ID
>or face ID with resulting geometry) and the vtkGenericDataSetTessellator
>(doesn't take lower-dimensional boundaries, but can store cell IDs with
>resulting geometry).
>  
>
That was one important reason for us to implement the new cell types in 
VTK. And because we need the cell informations
while processing the data, we can not use the tessellator to create an 
approximation. The extrapolation and
interpolation algortihm i have designed (maybe bad, but fast) are not 
working anymore in this case.
We need exact point, cell and face ids. Also we need to use shrink, 
threshold and other filter bevor tessellation.

>>Perhaps of more general interest is the question of user contributions
>>which are documented and tested but not implemented in all VTK classes.
>>Insisting on a 100% complete implementation seems to me to be too
>>onerous and could potentially stifle all but the smallest of
>>contributions. 
>>    
>>
>Obviously, Kitware has the final say, but here's my 2 cents. It sounds
>like Soeren is most of the way there. And while I agree that it makes
>the barrier high, VTK would quickly turn into a very difficult piece of
>software to use otherwise. It's not that everything has to be there on
>the first checkin, but there has to be a commitment to follow through.
>If it was simply a filter that only handled a subset of cell types
>(consider some of the volume renderers that only work on tetrahedra), it
>might be one thing -- but the cell API is deeply involved in the VTK
>framework.
>  
>
Indeed. Im trying to figur out what changes have to be made to fully 
support the cell types.
I will have one week, maybe two for doing this, but im working only part 
time .... .
And i would be realy happy if anybody can give me some hints or 
suggestions what is important to implement
and which classes should be modified.

These are the classes i have figured out so far:
Already modified:

Filtering/vtkUnstructuredGrid.h .cxx .h
Graphics/VtkDataSetSurfaceFilter.cxx
Graphics/vtkCutter.cxx
Graphics/vtkGeometryFilter.cxx
Graphics/vtkBoxClipDataSet.cxx
Filtering/vtkGenericCell.h .cxx

Im not sure what to do:

Parallel/vtkExodusIIWriter.cxx
Parallel/vtkEnSightWriter.cxx
Hybrid/vtkExodusReader.cxx

 
Im not able to test everything. And because i have no knowledge in java 
and python, im not able to
test the new cell types within  java and pyhton.

Im currently implementing tests in TCL:
clipQuadraticCells.tcl and ExtractEdgesQuadraticCells.tcl

In tcl i have some wired problems.
For instance: the method GetCellType seems not to return the right Type 
in tcl?? I have to set the number by hand.
Extract edges works, but Contouring and clipping are not working!?
I have tested these functions already in C++ and they working fine.

Can anybody help me what i have to consider or what im doing wrong?

Best regards
Sören Gebbert

btw.:
please excuse my english, im not a native speaker.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20051220/6c8e11bf/attachment.html>


More information about the vtk-developers mailing list