Hello GameDev Community.Right now, I'm learning OpenGL and Direct3D by coding some sort of a graphics engine with interchangeable Renderers. Now I've come across a problem with Vertex Buffer Objects in OpenGL. I'm allowed to create Buffers for Vertices, Texture Coordinates, Vertex Colors, Normals and then Create an Index Buffer to tell the Graphics card, which Elements to take for rendering the triangles of my mesh. The Problem is - when I'm using UV mapping in a 3D-Modeling program like Blender3D or 3ds max, I sometimes have multiple Texture Coordinates (in the places where I've set the seams of my mesh) per vertex. Until now I've always exported my mesh with only one texture coordinate tuple per vertex, which resulted in ugly artifacts:http://xcpp.org/alsa...gs/260908_1.pnghttp://xcpp.org/alsa...gs/260908_2.pngMy Question is: How can I use Vertex Buffer Objects with multiple texture coordinates per vertex? An alternative (which I'd prefer) would be to save the Tex. Coordinates per Triangle. But how can I use VBOs with this?Best Regards Azrael, il Meraz

Just put a glClientActiveTexture call before setting your buffer.

Hope this helps.

Does that mean I have to use multiple texture coordinate buffers?
I may have described the problem unclearly - I'm not using multiple textures - I just have triangles in my mesh, which share a vertex, but have different texture coordinates for it.

See here:
http://xcpp.org/alsage/bugs/Problem270908_1.png

Quote:Original post by AzraelilMeraz
Does that mean I have to use multiple texture coordinate buffers?
I may have described the problem unclearly - I'm not using multiple textures - I just have triangles in my mesh, which share a vertex, but have different texture coordinates for it.

See here:
http://xcpp.org/alsage/bugs/Problem270908_1.png

If you are using vbo's (indexed or not), for each vertex a set of properties is stored (depending on what buffers you use), for example: position, normal and texture coordinates. As far as I know, if a certain vertex is used multiple times, but each time you need other texture coordinates, this is not possible. In this case you have to store the vertex and the texture coordinates multiple times in your buffers.

Maybe an example makes this more clear. Say you have a vertex (1, 0, 0) and you have texture coordinates (0.0, 0.0) and (0.5, 0.5). For vertex A (position 1, 0, 0) you want the first texcoord and for vertex B (also position 1, 0, 0) you want the second texture coordinate. In that case you have to use the following buffer:

vertex: 1, 0, 0, 1, 0, 0 (vertex stored twice)
texture: 0.0, 0.0, 0.5, 0.5

I don't know about another solution, unless you are able to do something smart with selecting the right texture coordinate in a shader, with the following setup:

vertex: 1, 0, 0
texture 1: 0.0, 0.0
texture 2: 0.5, 0.5

If there is a way to determine in your shader which texture coordinate you need, this might be an option (although I have never tried something like that). But this depends on a lot of things: this way you can only handle two shared vertices with both different texture coordinates. But what if you have three? Or four?

Often shared vertices have also shared texture coordinates anyway, so a duplicate vertex in your buffer isn't a big problem (you probably won't need it often). And besides that, in the occasions you would need different texture coordinates for two vertices which share the same position, you often also need two normals, because needing different texture coordinates means often that you hit an edge of your mesh (for example the edge of a cube).

[edit]
Last year I wrote an exporter for blender that exports vertices, normals and texture coordinates (multiple if necessary) in a format that could immediately be stored in vbo's. What I did when exporting a new vertex was check if another vertex with exactly the same normal and texture coordinates already exists in the buffer. Only if it found one that was exactly the same, the index created pointed to the existing vertex. Otherwise (for example: the vertex had an other normal or other texture coordinates) a new vertex with normals and texture coordinates was created in the buffer.
[/edit]

Quote:Original post by TheFlyingDutchman
...
Last year I wrote an exporter for blender that exports vertices, normals and texture coordinates (multiple if necessary) in a format that could immediately be stored in vbo's. What I did when exporting a new vertex was check if another vertex with exactly the same normal and texture coordinates already exists in the buffer. Only if it found one that was exactly the same, the index created pointed to the existing vertex. Otherwise (for example: the vertex had an other normal or other texture coordinates) a new vertex with normals and texture coordinates was created in the buffer.

That's exactly what I was thinking about, when I was reading your reply. Thank you very much :)

I've copy/pasted working code from a library of mine:

http://pastebin.com/mc615750 (this file will stay up for a month)

Kinda trying to make a good clean opensource library for OpenGL, that is as functional as DX10-SDK.

Ah, use glEnableClientState(GL_VERTEX_ARRAY); at start of app, don't need to disable it imho. (as long as you'll be using only VBOs- as you should :P).
Also, the type ILVBO was a handle-type with the ILI_VBO struct hidden in the .cpp file, just changed it here directly to *ILI_VBO for you to use the code directly

Quote:Original post by idinev
I've copy/pasted working code from a library of mine:

http://pastebin.com/mc615750 (this file will stay up for a month)

Kinda trying to make a good clean opensource library for OpenGL, that is as functional as DX10-SDK.

Ah, use glEnableClientState(GL_VERTEX_ARRAY); at start of app, don't need to disable it imho. (as long as you'll be using only VBOs- as you should :P).
Also, the type ILVBO was a handle-type with the ILI_VBO struct hidden in the .cpp file, just changed it here directly to *ILI_VBO for you to use the code directly

Thank you for the code, but I have my own, working routines already :). I'll definitely look through your code, since it appears to make use of OpenGL in a more optimized way, but I'll stick to my code for now, because the machine where the programm must be able to run doesn't support OpenGL 2.0.
Also, my real Problem lay only within my Blender exporting script.