[vtk-developers] per-face tcoords problem (vtkOBJReader, vtkVRMLImporter)

[Tim Hutton]

Hi Will,

Proper support for tcoords per cell might be nice for the future. It is 
occasionally useful for working with textured surfaces, where two 
neighbouring cells share vertices but the shared vertices have different 
tcoords for each cell. (However, I suspect this is a tiny tiny fraction of 
vtk users.)

For the moment I've rewritten vtkOBJReader to deal with the situation by 
duplicating the vertices (actually better than my workaround below, since 
it also deals with normals properly). I've put the code here:

http://www.eastman.ucl.ac.uk/~thutton/vtkOBJReader.cxx
http://www.eastman.ucl.ac.uk/~thutton/vtkOBJReader.h

It should support all same OBJ features that the previous implementation 
did, as well as now per-face tcoords and per-face normals (by vertex 
duplication if necessary). It works with cow.obj and all other OBJ's I've 
found.

Unless there any obvious problems I'll commit this in the next few days, 
after tidying it up.

A similar solution should be possible for vtkVRMLImporter.

Tim.

At 13:11 08/07/2003 -0400, Will Schroeder wrote:
>Hi Tim-
>
>I think it might be possible to stick the tcoords into a data array 
>associated with the cells. Then the mappers would have to be modified to 
>support tcoords per cell (using the data array). It would require some 
>work but I suspect it could be done without too much trouble.
>
>Please pardon a dumb question: you want---for every face--a tcoord per 
>each vertex of the face. As long as the number of verts per face is 
>constant (e.g.., all triangles) this would be easy to represent as a 
>6-tuple in a data array (r,s, r,s, r,s) corresponding to each triangle.
>
>Will
>
>At 12:02 PM 7/8/2003 +0100, Tim Hutton wrote:
>>Hello VTK developers,
>>
>>The issue of per-face texture coordinates has cropped-up for me again. 
>>Both the OBJ and VRML formats support this but vtkOBJReader and 
>>vtkVRMLImporter do not, and in fact cause eventual access violations if 
>>you try to use them to read certain files.
>>
>>I have a workaround (below) and was wondering if anybody has any 
>>experience with this, or any tips on how I can change vtkOBJReader and 
>>vtkVRMLImporter to cope with this situation?
>>
>>File contains:
>>
>>A: vertices  (eg. 2728 3D points)
>>B: polys  (eg. 5342 int-triplets, indexed into A)
>>C: tcoords  (eg. 3078 2D points)
>>D: tcoord polys  (eg. 5342 int-triplets, indexed into C)
>>
>>Always, n(D)==n(B) since these correspond.
>>
>>My workaround is to construct a new points structure, E and do this: 
>>(pseudo-code)
>>
>>E->SetNumberOfPoints( n(C) );
>>
>>for( i=0; i<n(D); i++ ) {
>>   for( j=0; j<3; j++ ) {
>>     E[ D[i][j] ] = A[ B[i][j] ]; // copy point from A into E
>>   }
>>}
>>
>>the final polydata has:
>>
>>poly->SetPoints(E);
>>poly->SetPolys(D);
>>poly->GetPointData()->SetTCoords(C);
>>
>>One drawback of this method is that by duplicating vertices we have split 
>>the mesh, which means normals cannot correctly be computed. (If you merge 
>>the mesh before computing the normals then the texture no longer maps 
>>correctly.)
>>
>>An added complication is when some polys do not have any tcoords at all, 
>>leaving n(D)!=n(B). But this is even trickier, since VTK cannot cope with 
>>partially-textured surfaces I think. Maybe these polys could be added to 
>>a separate vtkPolyData.
>>
>>I'm loathe to make changes until I'm sure what the right thing to do is, 
>>so I'm looking for guidance! Is there a way to get VTK to use per-face 
>>tcoords "naturally"?
>>
>>Thanks,
>>
>>Tim.
>>
>>---------------------------------------------------------------------------
>>Tim Hutton,                        http://www.eastman.ucl.ac.uk/~dmi/MINORI
>>Research Fellow & PhD student,                   T.Hutton at eastman.ucl.ac.uk
>>MINORI Project, Biomedical Informatics Unit,
>>Eastman Dental Institute, UCL,                   Tel: [+44] (0)20 7915 2344
>>256 Gray's Inn Road, London WC1X 8LD, UK         Fax: on request
>>---------------------------------------------------------------------------
>>This email represents the views of the sender alone and must not be 
>>construed as representing the views of the Eastman Dental Institute. It 
>>may contain confidential information and may be protected by law as a 
>>legally privileged document and copyright work. Its content should not be 
>>disclosed and it should not be given or copied to anyone other than the 
>>person(s) named or referenced above. If you have received this email in 
>>error, please contact the sender.
>>
>>
>>_______________________________________________
>>vtk-developers mailing list
>>vtk-developers at vtk.org
>>http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>
>