Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (803)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  VAO Index Buffer + GL_TRIANGLES: Avoiding flipped textured? + Bleeding Textures?  (Read 35891 times)
0 Members and 1 Guest are viewing this topic.
Offline shadowstryker
« Posted 2016-06-13 11:18:49 »

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
Offline elect

JGO Knight


Medals: 72



« Reply #1 - Posted 2016-06-13 12:17:59 »

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
Offline shadowstryker
« Reply #2 - Posted 2016-06-13 13:05:36 »

Using an index buffer I'd still have flipped textures unless I loaded duplicate data into the vertex and texture coord array, though Sad
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Kernel


Medals: 195



« Reply #3 - Posted 2016-06-13 13:47:29 »

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.

Mathias - I Know What [you] Did Last Summer!
Offline elect

JGO Knight


Medals: 72



« Reply #4 - Posted 2016-06-13 15:11:52 »

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

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 Smiley
Offline ra4king

JGO Kernel


Medals: 508
Projects: 3
Exp: 5 years


I'm the King!


« Reply #5 - Posted 2016-06-15 09:18:18 »

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 Tongue
A better idea is elect's with calculating the positions in the shader!

Offline cylab

JGO Kernel


Medals: 195



« Reply #6 - Posted 2016-06-15 14:47:05 »

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

Mathias - I Know What [you] Did Last Summer!
Offline CoDi^R
« Reply #7 - Posted 2016-06-15 15:05:26 »

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

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.

Robotality - steamworks4j - @code_disaster - codi^r @ #java-gaming
Offline elect

JGO Knight


Medals: 72



« Reply #8 - Posted 2016-06-15 16:37:04 »


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


I recalled you can even use glPrimitiveRestartIndex, read this
Offline shadowstryker
« Reply #9 - Posted 2016-06-18 17:04:28 »

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). Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline shadowstryker
« Reply #10 - Posted 2016-06-20 08:46:08 »

Are you using a spritesheet/tilemap?

If not, you could just pass the number of vertices to the shader and multiply said number to the texture coordinates. This allows you to have tiles.
This is a common method when people do multi-texturing on their terrain. They have the background dirt or grass and the other tiles, such as flowers, gets mixed with the color.

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.
Offline shadowstryker
« Reply #11 - Posted 2016-06-24 00:30:57 »

It's /very/ nifty to not use a tilesheet when doing this.

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! Smiley
Offline theagentd
« Reply #12 - Posted 2016-06-24 03:20:06 »

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.

Myomyomyo.
Offline theagentd
« Reply #13 - Posted 2016-06-25 16:24:21 »

And they also do texture atlases. So you got 1154 * texture and limited by units and ram.
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.

Myomyomyo.
Offline theagentd
« Reply #14 - Posted 2016-06-26 01:12:00 »

I've never had bleeding problems in my implementations.
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

Myomyomyo.
Offline ra4king

JGO Kernel


Medals: 508
Projects: 3
Exp: 5 years


I'm the King!


« Reply #15 - Posted 2016-06-26 22:16:24 »

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.

Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #16 - Posted 2016-06-27 00:44:49 »

-snip-


Offline shadowstryker
« Reply #17 - Posted 2016-07-06 14:28:46 »

And they also do texture atlases. So you got 1154 * texture and limited by units and ram.
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.


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!
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #18 - Posted 2016-07-07 06:05:38 »

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

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #19 - Posted 2016-07-07 22:29:45 »

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

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Pages: [1]
  ignore  |  Print  
 
 

 
Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5544 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4584 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4015 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!