25 replies to this topic

[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:


At a distance following effect is caused:


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]

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

http://www.devmaster...?showtopic=1930

[Hydrael]

Dia said:

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

http://www.devmaster...?showtopic=1930

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]

mysticman said:

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

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]

Hydrael said:

mysticman said:

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

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:

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:


Mipmap level 64x64


Mipmap level 4x4 (zoomed in):


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]

neonoblivion said:

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.

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:

[Tufty]

Very nice, I'm impressed :)

[Reedbeta]

Great job!

How fast does it run compared to before?