I know I can fix this one using linear filter for my texture but the problem is that the linear filter cause texture bleeding since it blend the closest colors together or something like that. glShadeModel(GL_SMOOTH) or changing the pixelformat of LWJGL isnt helping since the problem is texture based and not polygon based.

One last thing, if I change the pixel format for anything else than 0 I get again little lines between my cubes I don't know if this one I a texture bleeding problem too.http://postimg.org/image/i3a6bller/

--Ps I dont wan't to use shaders if possible. I in the range of the possible I don't want to limit old computers.

Not that I am an expert, but I somehow seem to associate this with depth issues.Do you have depth testing enabled? And if you do have depth testing enabled,Do you have two faces exactly on top of each other?

I have not yet optimized my map yes there's faces at the same place it will probably fix some problems but is there a solution for the texture aliasing since gl linear create texture bleeding? Ps yes dept testing is enabled.Pps . sorry I'm on my phone.

Not that I am an expert, but I somehow seem to associate this with depth issues.Do you have depth testing enabled? And if you do have depth testing enabled,Do you have two faces exactly on top of each other?

I might be wrong here, but I think it's worth checking out.

If he didn't have depth testing enabled all you would see is a bunch of vertices rendered in front of each other. Depth testing should not affect texture bleeding. I agree, show us some code.

Unrelated, but i strongly recommend against have a buffer object for every cube, which it seems you are doing right now. And to be honest, buffer objects aren't that great for this type of geometry anyway. Use vertex arrays or even display lists, if you're ok with using deprecated GL. Edit: Never mind it seems like thats how you render chunks. I also found something else, glTranslatef. Don't use this for moving your chunks when you can just specify starting coordinates for the chunk and pass over expensive matrix calls..

If you have static chunks, why would you ever translate them using more expensive matrix math when you can simply set a start point for your chunk, and then send the vertices to your renderer along with the chunk offset?

If you have static chunks, why would you ever translate them using more expensive matrix math when you can simply set a start point for your chunk, and then send the vertices to your renderer along with the chunk offset?

Because the map has to move when the player is moving to to make the "camera effect" ??

If you have static chunks, why would you ever translate them using more expensive matrix math when you can simply set a start point for your chunk, and then send the vertices to your renderer along with the chunk offset?

This is irrelevant. Default OpenGL automatically precomputes the gl_ModelViewProjectionMatrix, so it's still just a single matrix multiplication for the GPU.

I don't know if it can help but I definitely get texture bleeding with pixel format other than 0.

You're creating your pixel format using

newPixelFormat(8, 16, 0, 16);

. That's 8 bits of alpha (not really usable for 3D), 16 bits of depth and 16 samples per pixel. 16x multisampling isn't supported by any hardware, but on Nvidia hardware at least 16x multisampling is mapped to 2x2 supersampling (double resolution rendering) plus 4x multisampling. It's the most expensive anti aliasing setting you can enable from OpenGL, around 4x to 8x as expensive as no multisampling. Not only is it expensive, it's also screwing up your texture coordinates.

Multisampling works by computing the color of a pixel once, but computing depth and coverage for each sample. With 4x MSAA you get the following layout. The green point is the point for which the color is computed.At edges only some of the 4 samples will be covered by the triangle. Consider a triangle that barely overlaps the pixel's top (red) sample but not the green center point. Despite the fact that the green center point isn't covered, the color will be calculated as if it was covered, but the result will only be written to the top sample. That means that all the vertex attributes, including texture coordinates and colors, will be extrapolated (as opposed to interpolated when the triangle covers the center point), and the texture coordinates generated can be outside the range that the vertices specify. When using sprite sheets, it essentially introduces a new source of texture bleeding.

Solutions: - Like you said, disable all multisampling:

newPixelFormat(8, 16, 0, 0);

- If you're okay with using shaders and OpenGL 3, create a custom texture coordinate varying and set its interpolation qualifier to centroid to prevent extrapolation. - Use a 2D texture array with one sprite per layer instead of a sprite sheet. Since that'll prevent all texture bleeding between sprites you can use everything from bilinear filtering and mipmaps to multisampling without any bleeding.

Like you said, disable all multisampling: new PixelFormat(8, 16, 0, 0);

Thats kinda sad.

Quote

If you're okay with using shaders and OpenGL 3

I'm not, at least for a global solution. I will probably implement them for peoples that suport opengl 3+ but I want a solution for those who don't support opengl3 + and shaders seems to be an other world that I haven't discovered yet.

Quote

- Use a 2D texture array with one sprite per layer instead of a sprite sheet. Since that'll prevent all texture bleeding between sprites you can use everything from bilinear filtering and mipmaps to multisampling without any bleeding.

I know that recent GFXcards have some magic way to play with texture array that doesn't make them slow but isn't a bad solution for older GFXcards?

Texture arrays shouldn't be slower than normal textures. The filtering cost is exactly the same. The only difference is the amount of data you can sample from, which isn't any worse than when using 3D textures which have been supported since forever. Sadly texture arrays are just like the centroid interpolation qualifier limited to OGL3 hardware. In other words, you can't have accurate antialiasing with sprite sheets used as you use them. Traditional 3D textures can also be used, but they won't handle mipmaps correctly since they'll blend between layers as well. You could add a border with the same color as the edge pixels of each sprite, but that won't help if you're using mipmaps.

As you can see, there's no perfect solution without OGL3. You can get two of three of mipmaps, antialiasing and filtering. If you're willing to forsake mipmaps (which will look like crap when the sprites are small on the screen), you can use 3D textures or add borders around the sprites in the sprite sheet.

I decided to add a border around the sprites but I am wondering something let say I have a 512X512 spritesheet would it make slower if I add the border around every sprites while loading. I'm guessing Ill have to make every sprites 2X2 pixel smaller so my texture is a power of two. Do you think this is a good idea if I double the pixels for every edges of the sprites instead of doing this manualy when putting them into the bytebuffer?

I decided to add a border around the sprites but I am wondering something let say I have a 512X512 spritesheet would it make slower if I add the border around every sprites while loading. I'm guessing Ill have to make every sprites 2X2 pixel smaller so my texture is a power of two. Do you think this is a good idea if I double the pixels for every edges of the sprites instead of doing this manualy when putting them into the bytebuffer?

When you add the border is largely irrelevant. The only thing it affects is load time. Nowadays GPUs don't require power-of-2 textures, but if you decide to make your sprites 2 pixels smaller to fit the border you'll need to adjust your texture coordinates so that they don't include the border.

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