22 replies to this topic

[Relfos]

I'm creating a 3d tile based game, where a level is composed of lots of small tiles 10x10 in size, that are stitched together in a big mesh during loading.
The problem is, there are some visible seams between each tile, that seem to be dependent of the camera position.
What could be causing this?
The problem looks a lot worse when multisampling is enabled (and the problem appears on both PC and iPhone port)

[David_pb]

Have a look at: http://www.sjbaker.org/steve/omniv/tiling_textures.html

[Kaptein]

sadly, opengl hasnt got past the point where you have to make the image bigger because sampling reads outside the borders
this is especially the case for atlasing
if you have any plans to allow people with older (power of 2) cards, your textures suddenly get twice as big
if it was up to me, this shouldnt be needed

most people will tell you to use "border", but border doesnt work with multisampling
so, if you plan on enabling GL_MULTISAMPLE, then you must make all your textures twice as big, place the actual texture in the middle, and extrude all the edge pixels out to the sides
then your texcoords will be something like { 0.0 + 0.25, 1.0 - 0.25 } etc. where 0.25 is a const float based on your particular texture sizes

[Erik Rufelt]

sadly, opengl hasnt got past the point where you have to make the image bigger because sampling reads outside the borders
this is especially the case for atlasing
if you have any plans to allow people with older (power of 2) cards, your textures suddenly get twice as big
if it was up to me, this shouldnt be needed

Gotten past the point?
Textures work precisely like they are supposed to. And what does power of 2 have to do with anything about borders?
That certainly doesn't require your textures to be twice as big, especially not in a texture atlas. Also cards that require powers of two get more and more rare.

most people will tell you to use "border", but border doesnt work with multisampling
so, if you plan on enabling GL_MULTISAMPLE, then you must make all your textures twice as big, place the actual texture in the middle, and extrude all the edge pixels out to the sides
then your texcoords will be something like { 0.0 + 0.25, 1.0 - 0.25 } etc. where 0.25 is a const float based on your particular texture sizes

Why doesn't it work?
And why in the world would it require textures to be TWICE as big?
That's certainly not the case either.

[szecs]

Just add a one-pixel wide border.

[Kaptein]

wisdom

i just havent gotten it to work in my case, ive tried many times
the 2^n may be just me reading old tutorials, maybe wrong impression
and the atlasing thing was based on the first assumption, that multisampling requires even more pixels

you see, it works fine with a border until i move far away, then the seams start appearing

[King Joffrey]

Could be the derivatives being messed up. Are you storing the tiles in a single texture?

[Relfos]

Yes, all tiles are stored in a single 512x512. This does not use shaders, as it is an iPhone game.
For now setting the texture filter as GL_NEAREST_MIPMAP_NEAREST fixed the issue (well, almost).
For the other cases, slighty offsetting the UV coords of the tiles one pixel fixed it.

[Kaptein]

i just checked my code to find out why im doing what i do
and yes, im also storing "tiles" in single textures, so i need internal borders too
i think ill try to reduce the images somewhat

[King Joffrey]

Does the view-dependent issue dissappear when you disable mipmapping for the atlas?

[Ashaman73]

This seems to be a texture bleeding issue when linear filtering is enabled. Here are some hints/tricks to get rid of it:
1. You tiles should be of power of two size, this could prevent texture bleeding from mipmapping.
2. Try to use array textures: put each tile on a single layer (thought I don't know if the iphone supports this). Don't try to archive this with 3d textures (=>mipmapping issues)!
3. Try to clamp to the tile borders using a shader, add a small border to the tiles,but your total tile size(including border) should be still a power of 2.

[kruncher]

3. Try to clamp to the tile borders using a shader

Would you mind demonstrating how this works (preferably with a CG shader)?

[Ashaman73]

A simple shader idea (without border,just clamping), 4 textures on a single one, each tileable:

vec2 texture_coord = ..input..

// retrieve fraction part of coords  to map coord into [0..1]
texture_coord = fract(texture_coord);

// clamp to 1/2 pixel, i,e. DELTA = 0.5/1024.0 for 1024 texture, play around with values to see its effect, consider mipmaps, which halfs the resolution at the underlying level
texture_coord = clamp( texture_coord, vec2(0.0)+vec2(DELTA), vec2(1.0)-vec2(DELTA));

// shift and scale texture to according corner
texture_coord = texture_coord * vec2(0.5) + vec2(OFFSET_X,OFFSET_Y);

But I think, that you will archive better quality when using a border (repeating texture accordingly).

Edited by Ashaman73, 12 June 2012 - 05:02 AM.

[kruncher]

Thanks for the example! I will have a play :-)

Also, the screenshots for Gnoblins look amazing, well done!

[kruncher]

I've been experimenting and found that disabling mip-mapping on my texture and simply offsetting UV coordinates (on mesh, not in shader) by 1 / width and 1 / height of atlas using:

lower_left_uv.x += 1 / width;
lower_left_uv.y += 1 / height;
upper_left_uv.x += 1 / width;
upper_left_uv.y -= 1 / height;
upper_right_uv.x -= 1 / width;
upper_right_uv.y -= 1 / height;
lower_right_uv.x -= 1 / width;
lower_right_uv.y += 1 / height;

Whilst this seems to work (through trial and error) is there any logic to this?

thanks

[DemonRad]

you need a incomplete Mipmap pyramid (older cards don't support that. And I never checked if that feature is available into OpenGL ES) Even extruding borders will give seams for lowest mipmap levels. because lowest mipmap levels are an average of above levels.

If you have a 512x512 atlas made of 8x8 tiles each one with 64x64 pixel then instead of using a mipmap pyramid of log2(512)=9 levels. you have to use a mipmap pyramid of log2(64)=6 levels. And you have to care each single tile reducing it by few pixels (for example reduce down to 54x54) and fill the pixels around with extrusion of the tile. With farest geometries artifacts may still occurr, but with some fog are nicely hided. (you still need to readapt texture coordinates to 54x54 subtile instead of 64x64 subtile)


Texture arrays is still a valid alternative (i think TA were born for these problems).

Edited by DemonRad, 13 June 2012 - 01:49 AM.

[kruncher]

you need a incomplete Mipmap pyramid

Are you saying that this applies when I have mipmapping disabled?

Texture arrays is still a valid alternative (i think TA were born for these problems)

Yes these would certainly improve matters because I could take a completely different route. Unfortunately ShaderLab (in Unity) does not provide bindings for sampler2DArray

[Ashaman73]

disabling mip-mapping

Disabling mip-mapping is not the best idea. For one you will get strong artifacts when moving around and using detailed textures, and it is slower than using mipmapping.

Whilst this seems to work (through trial and error) is there any logic to this?

Yes, the reason is, that on a atlas the naive pixel coordinates are often between two adjacent textures. Therefore the samples taken at the border will include texture data from the adjacent texture (reason: linear filtering). To reduce the effect, you need to move your coord away to the center of the border pixel which you have done by moving it by a whole pixel away (half would be enough).

This could be done with lower mipmapping levels too, but in this case you need to move it away depending on the mipmap level, that is

level 0: 1/width
level 1: 1/ (width/2) = 2/width
level 2: 1/ (width/4) = 4/width
level 3: 1/ (width/8) = 8/width
...

As you can see, higher mipmap levels result in a relative broad border, so you can't just calculate it once and apply it to all levels. Either you need to ajdust it dynamically depending on the mipmap level (expensive, newer hardware needed) or you should repeat the border of your tile. As far as I remember the latter has been done in the id-tech5 engine (megatextures utilize lot of atlases).

[kruncher]

Disabling mip-mapping is not the best idea. For one you will get strong artifacts when moving around and using detailed textures, and it is slower than using mipmapping

I don't think that is the case for me because I have an orthographic camera. Somebody suggested to me that there is very little advantage to mipmapping for 2D...

As you can see, higher mipmap levels result in a relative broad border, so you can't just calculate it once and apply it to all levels. Either you need to ajdust it dynamically depending on the mipmap level (expensive, newer hardware needed) or you should repeat the border of your tile. As far as I remember the latter has been done in the id-tech5 engine (megatextures utilize lot of atlases).

Very interesting, thanks for pointing that out.

[Ashaman73]

Somebody suggested to me that there is very little advantage to mipmapping for 2D...

Yes, when you develop a 2d game with a fix 1:1 texture mapping, you don't need mip-mapping at all, I was more or less referring the topic starter who creates a 3d game.