🔒 Locked

Repeating textures and linear filtering

Started by Aardvajk Sep 1, 2008 at 2:57 PM 4 replies 1.5k views

Original Post

Sep 1, 2008 at 2:57 PM

[Direct3D 9, C++] I'm using texture-repeating to fill polygons that make up the solid bits of a level in a 2D game. Problem I'm having is that when linear filtering is on, at the edges of the polygon I'm obviously getting a bleed of colour from the opposite edge of the texture. Obviously I could design all my textures so that the edge pixels were the same colour as the pixel on the opposite side of the texture, but I was wondering if there were any solutions to this that do not impose this restriction. For example, my block texture uses the classic Windows fake 3D effect of having bright edges top and left and dark edges bottom and right. When I use repeat, on the right and bottom sides of the polygon as the screen moves, I sometimes get a 1 pixel wide line of the bright pixels as the texture is wrapped one pixel too far. Is this solvable? Thanks.

jollyjeffers

Sep 1, 2008 at 4:21 PM

Yup, its definitely solvable [smile]

You need to get very familiar with the "Directly mapping texels to pixels" article in the SDK documentation. In a nutshell you need to pull the TC's for each tile in very slightly so that linear filtering doesn't grab the opposite edges texel.

It can be a bit tricky and can play havoc with shared vertices, but it will work. The only other solution is to look into things like texture gutters - duplicated edge pixels and stuff similar to your suggestion.

hth
Jack

Aardvajk

Sep 1, 2008 at 4:28 PM

Okay. I guess that makes sense.

I've used gutters of duplicate pixels recently when using linear filtering on single sprites grabbed from texture atlases, but the trouble with doing that on textures I'm repeating is that the gutters will show up on the textures repeating across the polygons.

Do you think a solution might be to take a vector pointing from each vertex to the shape center, then normalise that and move the vertex in by a slight amount in that direction? As I recall, the article in the SDK you refer to suggests moving vertices a half pixel rather than texture co-ordinates?

I can try it and see, but any further suggestions or input is always appreciated.

Thanks for the response.

jollyjeffers

Sep 1, 2008 at 4:55 PM

Quote:
Original post by EasilyConfused
Do you think a solution might be to take a vector pointing from each vertex to the shape center, then normalise that and move the vertex in by a slight amount in that direction? As I recall, the article in the SDK you refer to suggests moving vertices a half pixel rather than texture co-ordinates?

This should work, and I'm pretty sure I've implemented the equation in both ways - the vertex position and the texture coordinate. I seem to remember there were cases that Nvidia/ATI hardware gave differing results for that required nasty hacks like this [headshake]

You don't really need that article nor its specific solution, more just the simple understanding that a texel is a point and not an area like you might assume. Once you've sussed that one and understand how to offset the coordinate to ensure that sampling only includes pixels you want then thats fine. A piece of paper and a few fraction/ratio calculations is all it needs [smile]

hth
Jack

Aardvajk

Sep 1, 2008 at 5:13 PM

Hmm. Sounds like a solution that happens to work on my hardware might not on someone elses.

Think I might look at going back to using a tilemap for my level and just build polygons from tiles again. Going to mean a whole heap of other problems to solve relating to my collision response, but perhaps there will be a more certain and universal solution to that.

Cheers for all your help.

jollyjeffers

Sep 1, 2008 at 5:49 PM

Quote:
Original post by EasilyConfused
Hmm. Sounds like a solution that happens to work on my hardware might not on someone elses.

Don't take my word on this without doing a bit of research. I distinctly remember there being a lengthy thread in this forum that was discussing/debugging this very issue but I can't honestly remember with any certainty whether vendor differences were a hypothesis or conclusion!

Generally speaking there is little discussion of this issue so if I am remembering correctly it is most likely to be an edge case than a general purpose problem. If you think about it should ATI, Intel or Nvidia have differing texture sampling rules it'd cause absolute chaos for all aspects of computer graphics [oh]

Jack

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.