Texture coordinate types

  • Follow


Hello,

I don't know if I've choosen the correct subject for this thread, but
currently I've found that there are two "types" of texcoords:
per-vertex and per-face. Most of modelling tools, including blender,
suggests to export per-face texcoords because of some reasons. I
understand that it is possible to assign different texcoords for each
vertex in each face/triangle. Ok, my question is as follows. Lets say i
have some data:

float * vertices;
float * normals;
int * indices;

These I can easily render using glDrawElements. But when I have only
per-face texcoord set, there are more (or less) texcoords than
vertices, so the operation cannot be done. What should I do then? It
may sound funny for some of you, but what are these per-face texcoords
used for? Texture mapping usually is contiguous, so I think per-vertex
texcoords should work fine for most things.

Thanks.

0
Reply stelth (1) 6/20/2005 7:01:43 PM


stelth@europe.com wrote:
> Hello,
>
> I don't know if I've choosen the correct subject for this thread, but
> currently I've found that there are two "types" of texcoords:
> per-vertex and per-face. Most of modelling tools, including blender,
> suggests to export per-face texcoords because of some reasons. I
> understand that it is possible to assign different texcoords for each
> vertex in each face/triangle. Ok, my question is as follows. Lets say i
> have some data:
>
> float * vertices;
> float * normals;
> int * indices;
>
> These I can easily render using glDrawElements. But when I have only
> per-face texcoord set, there are more (or less) texcoords than
> vertices, so the operation cannot be done. What should I do then? It
> may sound funny for some of you, but what are these per-face texcoords
> used for? Texture mapping usually is contiguous, so I think per-vertex
> texcoords should work fine for most things.
>
> Thanks.

Hi, I ran across the same problem recently. As far as OpenGL is
concerned, a vertex is the same as another only if not only the 3D
coordinates are the same, but also texture coordinates, vertex normals
and so on -- what you describe as per-vertex coords --.

You'll have to duplicate all of these vertices that share the same 3D
coords but not texture coords. IOW, the vertices, normals and indices
arrays must have the same size.

HTH

P.S.: Sorry to the OP, I sent him directly the response by mistake.

0
Reply Azdo 6/22/2005 12:09:33 PM


stelth@europe.com wrote:
> Hello,
> 
> I don't know if I've choosen the correct subject for this thread, but
> currently I've found that there are two "types" of texcoords:
> per-vertex and per-face. Most of modelling tools, including blender,
> suggests to export per-face texcoords because of some reasons. I
> understand that it is possible to assign different texcoords for each
> vertex in each face/triangle. Ok, my question is as follows. Lets say i
> have some data:
> 
> float * vertices;
> float * normals;
> int * indices;
> 
> These I can easily render using glDrawElements. But when I have only
> per-face texcoord set, there are more (or less) texcoords than
> vertices, so the operation cannot be done. What should I do then? It
> may sound funny for some of you, but what are these per-face texcoords
> used for?

The simplest is the case of texturing a head. You have the front part 
and the back part on different parts of the texture. Usually the mesh is 
one continous closed surface, to make for more robust simplification for 
LODs for example and for normal calculations etc...

Now the vertex that is on the border between the two regions will 
usually be indexed by two triangles with different coordinates as it 
creates a natural seam in the mesh. This seam is there since designers 
usually set ip like that and you will have the same vertex being indexed 
using two different uv coordinates but of course the same position and 
normal in space.

Solution:

For each vertex, for each uv coordinate that is different from the 
first, duplicate the vertex (position, normal and new uv) and assign its 
new index for the triangle that needs this specific uv. It's called 
vertex duplication and is necessary for all hardware redering as there 
is no separate uv index jumping table for the triangles wich would in 
fact make for very inefficient rendering.

> Texture mapping usually is contiguous, so I think per-vertex
> texcoords should work fine for most things.

There is only per vertex coordinates so you have to add to your vertex 
count by the oddly indexed vertices. That is if you want to use arrays 
for rendering.

I faced the same problem a few years ago and couldn't get my head 
arround it until I realized that there is only one indexing table.

Happy to help!
Pablo
0
Reply Pablo 6/24/2005 8:35:37 AM

stelth@europe.com wrote:

> Hello,
> 
> I don't know if I've choosen the correct subject for this
> thread, but currently I've found that there are two "types" of
> texcoords: per-vertex and per-face. Most of modelling tools,
> including blender, suggests to export per-face texcoords
> because of some reasons. I understand that it is possible to
> assign different texcoords for each vertex in each
> face/triangle. Ok, my question is as follows. Lets say i have
> some data:


It's a common misconception, that a vertex is only defining the
position of a primitives corner. In fact a vertex is the
combination of position, normal, colour, texcoord(s) and other
parameters that can be set using extension. By calling glVertex
all the other vertex values in OpenGL's state machine are
combined with the position of the vertex and sent into the
rendering pipeline.

Also have a look at vertex shaders/programs: They allow you to
manipulate all the parameters that come with a vertex, not only
it's position.

So you don't have a problem at all: Vertices with different
texture coordinate are different vertices. Your modelling
package (at least I know it from Blender) will probably give you
different vertices using per face texcoords.

Wolfgang Draxinger
-- 

0
Reply Wolfgang 6/24/2005 10:06:19 AM

In article <1119294102.992880.26850@o13g2000cwo.googlegroups.com>,
<stelth@europe.com> wrote:

> Hello,
> 
> I don't know if I've choosen the correct subject for this thread, but
> currently I've found that there are two "types" of texcoords:
> per-vertex and per-face. Most of modelling tools, including blender,
> suggests to export per-face texcoords because of some reasons. I
> understand that it is possible to assign different texcoords for each
> vertex in each face/triangle. Ok, my question is as follows. Lets say i
> have some data:
> 
> float * vertices;
> float * normals;
> int * indices;
> 
> These I can easily render using glDrawElements. But when I have only
> per-face texcoord set, there are more (or less) texcoords than
> vertices, so the operation cannot be done. What should I do then? It
> may sound funny for some of you, but what are these per-face texcoords
> used for? Texture mapping usually is contiguous, so I think per-vertex
> texcoords should work fine for most things.

No, you have to export the per-face uv coordinates. Vertices will
commonly have more than one set of texture coordinates. As it happens,
I have an example at hand, from a dataset I exported from Blender:

// Number of vertices, indices into vertex array
FaceRec UI01Faces[26] =
{
        
        { 4, {6, 5, 4, 3} }, 

        { 4, {0, 6, 3, 1} }, 

        { 4, {1, 2, 4, 3} }, 

[...]
};

// Parallel with UI01Faces, two coordinates per vertex
UVCoords UI01UV[26] =
{
        
   {0.438435, 0.874381, 0.091957, 0.874381, 0.091957, 0.729886,
 0.438435, 0.729886},
 ------------------

    {0.484759, 0.867752, 0.451430, 0.874381, 0.451430, 0.729886,
                                             ------------------
 0.484759, 0.736515},

    {0.999121, 0.210889, 0.999121, 0.210889, 0.965792, 0.204260,
 0.965792, 0.204260},
 ------------------

[...]
};

Notice that vertex 3 has different UV coordinates for every use in
these three faces. That just indicates it's at a corner where the UVs
were unwrapped.

                                        --Al Evans--
0
Reply Al 6/28/2005 11:29:09 PM

4 Replies
163 Views

(page loaded in 0.106 seconds)

Similiar Articles:













7/9/2012 8:35:29 PM


Reply: