Game Development Community

Gl_clamp And Gl_linear

by Dane McGreevy · in Torque Game Engine · 08/29/2005 (8:18 am) · 10 replies

Hi everyone,

My name is Bryan and I'm part of a 3rd year software team at Melbourne University in Australia. We are working on using satellite photo's in TGE as part of a project for the Geomatics Department. Currently we have altered TGE to use one image over the entire map (I'm not sure if I'm allowed to share how we did this - i'll ask our supervisor - it's not very hard).

At the moment the image looks like this:

www.cs.mu.oz.au/SE-projects/s340gf/Picture/GL_LINEAR_screenshot.JPG
As you can see the texture does not blend over the square borders.

My question is, does anyone know how to use GL_CLAMP to use pixels from the textures on both sides of the border? I've read this is possible in the Red Book (the official OpenGL guide), but haven't yet figured out how to do it.

Using GL_CLAMP without any modification does this:

www.cs.mu.oz.au/SE-projects/s340gf/Picture/GL_CLAMP_screenshot.JPG
We have to change the border colour from the default black to a blend of the pixels on either side of the border.

Sorry for such a long post, just thought I'd check here before I spent any more time on research.

Bryan.

#1
08/29/2005 (10:23 am)
You should be using TSE for this; it already supports it out of box. :)

Meanwhile, you can either set the border to a fixed color which will leave you some wonky rendering artifacts (ie, plainly visible grid over the terrain), or else make sure your texture coordinates line up properly (if it's one big texture), or else touch up your texture tiles so the borders all have matching pixels (Clark Fagot posted a resource on how to do this with the existing blender a while back, search the site for it).
#2
08/30/2005 (4:02 am)
Thanks for your reply Ben. We've spoken to our client about TSE and he said it isn't compatible with what he's making.
#3
08/30/2005 (11:36 am)
That's too bad. :(
#4
08/31/2005 (8:06 am)
Hi again Ben,

Would you happen to have any idea how to use pixels from both sides of the squares as the border colour?

I have managed to change the border colour to green by doing this:

GLfloat borderColour[] = { 0.0f, 1.0f, 0.0f, 0.0f }; // green
glTexParameterfv(GL_TEXTURE_2D, GL_TEXTURE_BORDER_COLOR, borderColour);

but I can't figure out how to use parts of the actual texture as the border colour.

I may have to do a lot of opengl research.

www.cs.mu.oz.au/SE-projects/s340gf/Picture/greenborder.JPG
Regards,

Bryan.
#5
08/31/2005 (8:46 am)
I am pretty sure there is a way to make OGL "bleed" the textures edges, since I've seen such effect in the past. I think you need to disable the usage of the border color, but I don't remember how to do it.

-- EDIT --

Ah! Found it! Use GL_CLAMP_TO_EDGE instead of GL_CLAMP. GL_CLAMP_TO_EDGE was introduced in OGL 1.2. Check this for more details:

home.planet.nl/~monstrous/skybox.html
#6
09/07/2005 (11:31 pm)
I was just speaking to our course coordinator and she suggested that the problem might be a compression artifact. Does Torque do internal compression of images?
#7
09/07/2005 (11:56 pm)
I was just speaking to our course coordinator and she suggested that the problem might be a compression artifact. Does Torque do internal compression of images?
#8
09/08/2005 (2:14 am)
Not typically, no. I'm not sure how this latest post relates to the rest of the thread...
#9
09/12/2005 (9:12 pm)
We are trying to remove the blocky appearance in the image at the top of this post. Our course coordinator said that it looks similar to what happens when you compress an image. We were thinking that if TGE compressed images then if we turned off compression it might help.
#10
09/13/2005 (2:13 am)
Yes, well, that's because the sort of signal processing you do in image compression and the kind that happens in 3d rendering are somewhat similar, and more so when you're cutting things up into tiles.

GL_CLAMP_TO_EDGE will address the seam side of things; getting more texture data in there will fix the "compression" issue. But it'll also be tricky to get enough data out there that things look good, without eating performance or requiring an abnormally high min spec.

The only sort of compress that might be going on here (unless you're loading from a low-quality jpeg) is DXT, which has very distinct artifacts and in general aren't noticeable in noisy textures.