Ugly texture seams

[Hydrael]

Hello everyone,

I have a problem with mip-mapping combined with a texture tileset.
I use a 2048x2048 Texture which contains 16 512x512 tiles. This tileset is used for terrain rendering - meaning: I have 16 different ground types which I assign by changing the TexCoords. That way I'm able to texture a huge heightmap with only one single glBindTexture.

Works pretty good at great performance, but I do get some ugly seams which look like this:
http://img223.imageshack.us/img223/1884/buggy1lf.jpg

At a distance following effect is caused:
http://img223.imageshack.us/img223/1374/buggy16hi.jpg

I found out, that the problem lies in the mip-map generation.
Is there any way to fix that problem?
Maybe with custum mip-map levels like in a DDS File.

Thanks for any help in advance

[Dia Kharrat]

You need to change your texture generation settings. This post can help:

http://www.devmaster.net/forums/index.php?showtopic=1930

[Hydrael]

You need to change your texture generation settings. This post can help:

http://www.devmaster.net/forums/index.php?showtopic=1930
19272


Thanks a lot, but I already use


glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);


which doesn't seem to work :sad:

[Reedbeta]

Clamp to edge only fixes seams on cubemaps. I'm afraid there is no general way to fix this issue, it is inherent in packing multiple textures together into one. You can make the seams less visible by putting space in between the textures, or by biasing the texture coordinates inward by 0.5 texels or so. However, the seams will return at high mip levels, as shown in your second image.

I would suggest that instead of packing all textures into one you try to use multitexturing. This way you can still render the geometry in a couple of passes, but without texture seams - and you will be able to more easily extend this to texture interpolation schemes like splatting.

[Hydrael]

That's a pity to read :sad:
At the moment it would be possible to convert to multitexturing since I'm working on the world editor, in which performance is secondary.
But I'm afraid that I will get massive performance problems, when it comes to the game itself.
Let me explain why:
I use rather big heightmaps, 512*512 up to 1024*1024, which makes ~500k to ~2.000k triangles just for the geometry.
Those I have to sort,arrange or whatever to perform some effective frustum and/or occlusion culling algorithms (at the moment I use a custom coded method, but since it is not very flexible, I want to go for octrees or something similar later on).
This step will cost a big amount of performance, but it will be necessary.
If I then have to use more than one glBindTexture, I will have to sort the vertices again (respective: sort them by 2 criteria - visibility and active texture(s)) in order to reduce expensive texture changes to a minimum.
I sense a BIG bottleneck there and I don't have any clue how I would speed things up then :/

Do you, by any chance, have any advices I could follow?
Or does anyone know, how professionals texture big worlds (i.e. Jak and Dexter on PS2 or modern MMORPGs)?

Thanks a lot for any hints in advance.

[mysticman]

Me this problem I had it with the filter anisotrophic ON :glare:

[Hydrael]

Me this problem I had it with the filter anisotrophic ON :glare:
19285


I don't think, I got you right :blush:
Do you mean, using anisotrophic filtering solved the problem, or even anisotrophic filtering didn't solve it? :wink:

[mysticman]

Me this problem I had it with the filter anisotrophic ON :glare:
19285


I don't think, I got you right :blush:
Do you mean, using anisotrophic filtering solved the problem, or even anisotrophic filtering didn't solve it? :wink:
19287


I intended that when I activated the filter anisotrophic, the defect, of the distance lines, appeared :wink:

[Reedbeta]

It shouldn't be that big of a bottleneck - glBindTexture calls aren't quite as expensive as you seem to think :) Once you have a list of visible polygons or visible nodes in your data structure, sorting them by texture and rendering them in per-texture batches shouldn't be too slow. Indeed, your bottleneck is likely to be pure vertex processing rather than texture switching, and for this you can help with frustum/occlusion culling, as well as geomipmapping when you get to that point.

[Steven Hansen]

Is your terrain tilable? If so, clamping to edge isn't the right way to do it.

The problem occurs when you use any filtering... anisotropic, bilinear, etc. Unless the mapping is one-to-one, then when your edges are filtered, the hardware examines surrounding pixels and blends them together. So, blending edge pixels with anything other than exactly what you are going to blend them with on the terrain will cause the edges not to line up.

Ack :wacko:

So, there are a couple of approaches. You can try changing your states to not use clamping, or you can use point filtering.

Note: the reason some people use large terrain textures is so that they look good without filtering, and that way edges mesh together better. Point filtering is pretty popular - in a lot of games you get terrain "popping" - where it looks blurry one instant, and the next it is completely in focus. That happens when you reach the distance where mip-map levels change. Instead of a smooth transition (which means filtering is used and edges don't mesh), they are satisfied with the pop instead.

Obviously you will need to apply whichever approach you finally decide on during mip-map generation as well. Often, mip-maps are rendered separately (manually by the artist) to make sure that tiling is functional.

Good luck!

[Hydrael]

I almost got it working now by using custum (but automatic generated) mipmap levels:

Mipmap level 512x512:
http://img151.imageshack.us/img151/354/5123zs.jpg

Mipmap level 64x64
http://img151.imageshack.us/img151/134/640ln.jpg

Mipmap level 4x4 (zoomed in):
http://img151.imageshack.us/img151/1223/44na.jpg

Down to this level I believe it should work, because I initially have a 4x4 Tileset and so every tile should have its own pixel. As you can see the two grass tiles have a green pixel for example.
The problem I now have is, that the texture won't appear on the geometry. I guess that because I'm not going all the way down to 1x1 mipmap level - but if I would, I'd have the same problem again.
Can I somehow tell OpenGL that 4x4 is the lowest mimap level, or use the same texture for the lower levels?

Just in case that also doesn't work, I guess I will follow your suggestion Reedbeta.
In first case, that would mean I'd have to change my internal way of storing vertices in order to be able to batch render by texture, but that's going to be necessary then.

@Steven Hansen
Changing states didn't work either :sad:
The only thing that actually does remove the seams would be turning off mipmapping :lol:
But thanks for the hint with point filtering - that's one more line on my "stuff to try out" list :wink:

[Hydrael]

Ok, I got the custom mipmaps working now - but even with no filtering at all I still get seams :sad:
Seems like what I want to do really isn't possible in combination with mip-maps.
But I wonder, that this never really was an issue. Is it so uncommon to only use a certain area of a texture?

I think I'll go over to use multitexturing now. That's gonna be a load of work since I'll have to rewrite most of my code, but who knows...maybe later on I'll be glad I did that :)

Thanks anyway everyone :wink:

[Ed Mack]

Could you use a pixel-shader to do custom texture sampling and program it to wrap across the texture rectange?

[Hydrael]

Using shaders also came to my mind, but I have to admit that I've never worked with them. I guess, I don't even understand 100% what shaders actually do in theory :blush:
On the other side - shaders have been on my "stuff to learn" list for a while now. Maybe that's a good reason to start working with them :)

You will reckognize it if I did, when you see a "Need help with shaders" thread appear :lol:

[neonoblivion]

I had exactlly the same problem, and I did as previously stated and moved the texture coords slightly in. So where you have from (0,0)-(.25,.25) I do (.01,.01)-(.24,.24). Hope that makes sense. Although that would to break at really far distances It dosen't at the long dists I am using so it shouldn't for you eather. :)

[Reedbeta]

Using pixel shaders for this sort of thing is likely to be slower than multitexturing with multiple glBindTexture calls. But if you want to give it a try, go ahead; pixel shaders are sweet and you will NEVER want to go back to old ways once you learn how to use them :)

[Hydrael]

I had exactlly the same problem, and I did as previously stated and moved the texture coords slightly in. So where you have from (0,0)-(.25,.25) I do (.01,.01)-(.24,.24). Hope that makes sense. Although that would to break at really far distances It dosen't at the long dists I am using so it shouldn't for you eather.
19338


I've already tried the exact same thing - the seams disappeared, but then the textures didn't exactly match any more at close range. That isn't quite as visible as those seams, but it's still a glitch :/

[Hydrael]

Just to let you know:
Like I said, I converted to multitexturing to solve my problem. After that, I studied Shaders a bit and used them for the groundtype blending.
The result looks like this - pretty good I think :wink:

http://img217.imageshack.us/img217/1958/verynice14ei.jpg

[Tufty]

Very nice, I'm impressed :)

[Reedbeta]

Great job!

How fast does it run compared to before?

[Hydrael]

On a Pentium IV 3.2 GHz, 1GB DDR and a Radeon 9700 I get approx. 70-90FPS on a 512*512 (1.5 million vertices) heightmap.
But the code still is very unoptimized and I'm not using VBOs at the moment. So I guess there still is some reserves I can use. At current state, I figure, I could come up to ~150-180FPS, which should be allright.

I don't think my initial idea would have been much faster. And I also believe, that groundblending would have been MUCH more complicated than it is now. Pixel shaders actually are really sweet :wink:
That's why I want thank you again for the advise to use multitexturing (and shaders) :)

[mysticman]

Wahoo! I have the same machine, only with 1.5gb mem :rolleyes:

[Kenneth Gorking]

I doubt the problem was with your mipmaps, 'cause if that was the case, the seems would still be there after you changed to multitexturing...

Anyway, try and offset your texture coordinates with 2/512 outwards from the center. I had those seems too, and this cleared it right up.

[Hydrael]

Oh, sorry - I guess I expressed myself a bit unprecise:
I completly dropped the whole idea with using one single tiled textureset. I instead now do "normal" multitexturing.

[Nautilus]

I had exactlly the same problem, and I did as previously stated and moved the texture coords slightly in. So where you have from (0,0)-(.25,.25) I do (.01,.01)-(.24,.24). Hope that makes sense. Although that would to break at really far distances It dosen't at the long dists I am using so it shouldn't for you eather.*
19338


I've already tried the exact same thing - the seams disappeared, but then the textures didn't exactly match any more at close range. That isn't quite as visible as those seams, but it's still a glitch :/
19352




Hi Hydrael,
perhaps I'm late, perhaps not.
Here is a solution to both the seam AND the matching problems (you had).
Just in case you want to return to use the single mega texture idea from before...

Look at these two *err* marvelous images *cough*:

O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O
O O O O O O O O O O

[fig. 1] - The original tile usage that caused the very first seam problem.
'O' = Pixel.




C C C C C C C C C C
C O O O O O O O O C
C O O O O O O O O C
C O O O O O O O O C
C O O O O O O O O C
C O O O O O O O O C
C O O O O O O O O C
C O O O O O O O O C
C O O O O O O O O C
C C C C C C C C C C

[fig. 2] - The original tile usage after pushing tex-coords inward (following neonoblivion's suggestion).
'C' = no-more-rendered outer ring of pixels.

Seams are gone because the 'C' ring provides the correct blending for the outer pixels displayed,
but tiles won't match because in the end you use a sub-portion of the original tile.

In Figure 1 you had seams... but texture matched perfectly.
In Figure 2 you have the opposite problems.
What to do?
Well, neonobivion's suggestion IS valid.
You only miss one step: make your tiles ready for what he said.

Fire up your favourite image editor.
Get a copy of one of the tiles in your mega texture and stuff it alone into a separate image you will work on (for the sake of simplicity).
Having no idea what's the image editor you use, I'll explain using 3 steps (hopefully universal).

Step 1:
Create a copy of the image. You must have two identical tiles/images loaded (A and B).

Step 2:
Working on the copy (B), shrink it so that it's 2x2 pixels smaller than the original image (A).
For example if 'A' is 64x64 then 'B' must become 62x62 pixels.
Note that I said shrink, not cut. So do not leave any pixel out of the process.
Of course this will change somewhat your tile. You may want to use an anti-alias filter to
smooth the result.

Step 3:
Select all of the pixels in the shrunk image (B) and copy them back onto the original image (A),
careing to center the smaller image (B) into the bigger one (A).

Save the image :wink: Finished.
To avoid to offend your intelligence I won't explain why this works.
Obviously all of the tiles inside your mega texture should be modified in the same way.
Doing so and using the inner tex-coords neonoblivion spoke of, will produce seamless AND
matching tiles.



Regards,
ciao ciao :)

[Hydrael]

Wow, thanks a lot for this great explanation :)
I guess that way it should work.
If I get the time, I will try it out and compare the performance between those two solutions.