VAO Index Buffer + GL_TRIANGLES: Avoiding flipped textured? + Bleeding Textures?

OpenGL Development
#1

Hey all, I’ve got a quick (possibly a not-so-quick-to-answer) question about coupling an Index Buffer with a VAO in concurrence with GL_TRIANGLE_STRIP for a heightmap and how I’d go about avoiding flipped textures. Here’s an example of how the Triangle Strip works, and what it’s doing right now as a result. The arrows show the order of which vertex is used and when if GL_TRIANGLE_STRIP is used, as does the Index Buffer.

I know the reason it is flipping the textures, I just don’t know how to efficiently fix it. The reason it’s flipping the textures in every other row is because each vertex, coupled with the Index Buffer, can only correspond to one texture coordinate. As a result when it comes time to render the second row of the heightmap, it renders the top of the square using the bottom right/left (BR and BL) coordinates of the texture, as the vertices making up the top of the square are also the vertices making up the bottom of the square above it. However, I have no clue how I’d go about fixing this without duplicating the vertex data so that each vertex can have two texture coords assigned to it (note this would mean a 128x128 heightmap would require data for 65,278 vertices as opposed to the 32639 vertices that would actually be rendered).

Another issue is that I only have 4 possible texture coordinates, yet I need to duplicate the same 4 texture coordinates multiple times so that the index buffer matches up to the correct texture coordinate for each vertex (ex. if the index is 20 then I need at least 20 texture coords loaded into an array for the index buffer to choose a texture coord for the vertex).

From what I can tell you can only use one Index Buffer with a VAO, whereas with a VBO you can have multiple Index Buffers, for example one Index Buffer for vertices, one for texture coordinates, one for normals, etc. Does anyone know of a way, or is anyone able to think of a way around this that doesn’t include creating tons of useless data that will never be used? I could use a shader to calculate the texture coordinates but I’m writing a game library, not a game, so I want it to be as easy to use as possible (so rather than requiring the use to write a shader specifically for heightmaps, I’d rather have it so the user can write a simple shader that’d be capable of rendering any VAO in the program).

Thanks for the help guys, I’m really stuck on this one. :wink:

#2

Don’t use GL_TRIANGLE_STRIP, use plain GL_TRIANGLES. If you exploits properly data localization, it’d be the same thanks to the vertex prefetch/cache

#3

Using an index buffer I’d still have flipped textures unless I loaded duplicate data into the vertex and texture coord array, though :frowning:

#4

That’s the deal - upload redundant indices, but safe on vertices and headaches…

Should have read the whole post, though. It looks you have to repeat the tex-coords or shift texture coordinate generation to the shader. If you want to texture a regular grid or terrain, it might be the way to go anyway.

#5

Uhm, right

some options I may think about are:

  • using GL_REPEAT

  • skipping completely any vbo and ibo, calculate both vertex position and texture coordinate inside the vertex shader using gl_VertexID after setting the size. On the app side use glDrawArrays

ps: you can’t have more than one ibo at time

pps: what happened to V5? I can’t see it in the picture :slight_smile:

#6

Hydroque, very irrelevant. It is obvious you didn’t read the post.

@OP: I definitely don’t recommend using GL_TRIANGLE_STRIP for this, use plain old GL_TRIANGLES and GL_REPEAT. Having repeated indices isn’t too expensive until you reach a few hundred thousand :stuck_out_tongue:
A better idea is elect’s with calculating the positions in the shader!

#7

I think ra4king failed to notice that the pastebin contains the relevant code and not the embedded code snippet…

#8

He has a point, though. shadowstryker is asking a very specific, detailed question. He probably wrote a lot of code already and won’t have much interest in copy&pasting some (rather generic, in my opinion) code snippets.

#9

I recalled you can even use glPrimitiveRestartIndex, read this

#10

I was unable to get glPrimitiveRestartIndex to work towards what I am trying to accomplish here. In the end I decided to go with a less efficient method of fixing this issue and I will do optimization later in development. While it is less efficient it does have minimal impact on the game’s FPS (actually no impact that I can tell), but regardless I’ll still optimize it later because why not?

Basically what I did is I duplicated the vertices so that I could assign multiple texture coords to a single vertex and just modified the index algorithm.

Final Result: a heightmap rendered using indices that correctly tiles the texture(s). :slight_smile:

#11

Currently I am working on a method of multitexturing using a tile map. Using the R, G, B values I can use 4 different textures on the heightmap (1 for each RGB value, and 1 for a background texture). I haven’t finished doing it yet, but it’s almost there.

#12

I got it working with multi-texturing as well. I’m currently using a blend map for multi-texturing, but I need to start looking for a different way to multi-texture the terrain. Typical terrain in modern 3D games (such as Fallout: New Vegas for example) has a lot of variation and using a blend map doesn’t seem to be the way to go about this. If anyone has any suggestions I’d love to hear them, but this thread is pretty much done at this point unless anyone has suggestions about the aforementioned dilemma.

Also here’s what it looks like now! Finally starting to visually see some real progress after working on this library for so long! :slight_smile:

#13

Use a TEXTURE_2D_ARRAY texture, let each vertex have 4 texture layer indices and a weight for each layer. Each vertex can represent a mix of 4 different textures, from a pool of however many you can fit in your texture 2D array (probably up to 1024 or something, depending on texture size/memory usage).

A GL_COMPRESSED_RGB_S3TC_DXT1_EXT texture is 1/6th as small as a standard GL_RGB8 (padded to GL_RGBA8) texture. Add 33% for the mipmaps, and you end up with ~908kb per 1024x1024 texture, or 1154 textures per GB of VRAM, or 4619 512x512 textures per GB.

#14

No, the whole point of texture arrays is to NOT have texture atlases, as they don’t handle filtering well (individual textures bleed together). Texture arrays do not have that problem.

#15

Really? Shit, I guess

  • all my OpenGL experience of ~6 years or whatever
  • plain logic in addition to knowledge of how texture filtering works, especially with mipmaps
  • all the existing topics complaining about bleeding on this forum
  • a quick google search for similar issues
    are all just plain wrong and you’ve revolutionized texture rendering (although a bit late since that problem already got solved with… texture arrays which don’t have any filtering between layers). I can survive you making partly or completely off-topic posts in every single thread like it’s your duty to report in on each and every one of them, but if you start spreading misinformation you’re literally hurting the community as a whole. And yes, technically you’re just stating your “opinion” based on your experience in this case, but it will be interpreted by a lot of people as that the texture bleeding problems they’re having are lying somewhere else, since you’re implying that I’m wrong.

EDIT: Dear god, now it looks like I’m completely schizophrenic. x___x

#16

Hydro, heed theagentd’s words and don’t easily dismiss them. You are aware that you feel most people aren’t being nice to you. A rational person wouldn’t blame the others for “hating” but would look inwards to see what they might be doing wrong.

#17

#18

Hey everybody, thanks for the help so far. I am having issues with texture bleeding in my blendmap. Well, actually in literally all of my textures I started this thread here seeking further help on the problem rather than using up this thread (it’ll also help other people in the future if I can solve my problem in that thread, and they are having the same problem).

If anyone could please help me with the bleeding issue that would be very much appreciated. Thanks in advance and thanks a ton for the help I already received!

#19

This sounds like
A shader issue (mapping)
An Invalid image loading procedure
Not using PNG, DDS, or XMI images
Resulting geometry is not mapped 1:1 with texture

#20

I believe you derailed it. It was a joke ._.