View Full Version : Tiling Textures without seams?
05-04-2000, 07:37 AM
I dug around the archives and could not find the answer to this question. I have several polygons which use different texture maps. The texture maps are designed to flow seamlessly between the polygons, but when drawn, there is a visibly crisp edge at the intersection.
I have read that this can be fixed using texture borders, ie: the textures overlap slightly. The only problem is that I can't seem to get this to work. Could anyone point me to a bare-bones demo of this, or give an explanation of how it's done.
The textures are 64x64 (including borders) and the polygons are square tiles.
05-04-2000, 09:28 AM
Your textures can't be 64x64 including borders. Each dimension of a texture must be a power of 2, PLUS 2 if you have borders. So your call to glTexImage2d should have width and height as 66, and border as 1.
05-04-2000, 08:04 PM
Thanks for the response. I was able to get it working with your insights.
I should also mention that OpenGL likes things on 4 byte boundaries, so the new 66x66 textures I was creating got skewed (1 byte per pixel * 66 pixels = not 4 byte aligned). This was causing no end of headache until I read the glDrawPixels entry.. (nice of them not to mention this under glTexImage)
05-05-2000, 02:33 AM
you can fix that with a call to glPixelStorei() with the GL_UNPACK_ALIGMNENT parameter. This sets the aligment of pixel storage for calls to stuff like glCopyPixels() and texture upload functions.
That sets a pixel row in memory to be byte aligned.
05-05-2000, 05:27 AM
Interesting; I didn't know about that...
Do you see much of a performance hit when the pixel data isn't word-aligned?
05-05-2000, 02:59 PM
Thanks for the input, any insights into OpenGL at this point are new to me! http://www.opengl.org/discussion_boards/ubb/smile.gif
Here's one: After implementing all this, including the border and proper byte alignment - suddenly my texture rendering is going software speeds! Eek! I have a GeForce, how would I go about verifying that it's an error in my coding v.s. an unsupported feature of the GeForce drivers?
05-09-2000, 08:00 PM
Most of the consumer level 3D cards has no hardware support for texture borders.
05-10-2000, 08:27 AM
No texture borders in hardware? Damn, didn't know that. That going to be a pain... anyone know any handy workarounds to get the same effect?
05-10-2000, 11:41 AM
Ach! I knew something was wrong... Oh well. So I have to do it myself then?
I'm thinking we'll have to use a texture that is say, 64x64 where the outer one or two pixels is overlapped with the other textures. Then pick the inner 63x63 or 62x62 square as the actual texture coordinates.
That is, when specifying the tex coords, do something like this (for the 63x63 case):
LowerLeft: glTexCoord2f( 1.0/TEXTURE_WIDTH, 1.0/TEXTURE_HEIGHT );
UpperRight: glTexCoord2f( 1.0-(1.0/TEXTURE_WIDTH), 1.0-(1.0/TEXTURE_HEIGHT) );
I've not tried this yet, anyone know if it'll work?
05-10-2000, 11:55 AM
Hey, sorry I'm so late.
That is exactly the way to go Bryan. Call the bilinear interpolation into mind. It somewhat doesn't take just 1 texel in account, it also interpolates with the surrounding. So skew the texture by 1 in every direction and use coordinates 1/64, 1/64, 63/64, 63/64 and it should draw the damn ****... http://www.opengl.org/discussion_boards/ubb/smile.gif It worked for me at least.
05-10-2000, 09:04 PM
You forgot about mipmaping.
Overlapping in 1 pixel solves a problem only for the level#0. http://www.opengl.org/discussion_boards/ubb/frown.gif
05-11-2000, 01:56 AM
Yeah, I thought about offsetting the texcoords slightly inwards, but it's ugly as hell, and he's right about mipmaps being a problem.
IIRC OpenGL 1.2 supports texture edge clamping, which sounds like it would be a better option (if I had a 1.2 implementation). Anybody have experience of using this, performance-wise?
[This message has been edited by MikeC (edited 05-11-2000).]
05-11-2000, 03:34 PM
(Is that you? From the randomize discussion?)
Anyway, in the past I run into a more or less equvilent problem. It was merging the front view of a persons head with the side view. I actualy solved it by something our bussiness people called "inverse raytracing", even so this wasn't right.
What I did was the following, of all the textures I had to display on a mesh, I generated a single one that I could map using a simple enviorment mapping.
(I applogize for my bad english)
This elimenates the problem with bilineray filtering as well as mipmapping.
Hope that put's you on the right way...
05-12-2000, 07:03 AM
Yep, it's me fumbling around in OpenGL. I feel like an idiot with all these matrix stacks and API calls flying around my head. One day I'll have it under control.
I think the Michael Steinberg's responce will fix my problem. This is all for terrain texturing and I'm working with extremely large texture sizes (like 100K x 100K). I won't need mip-mapping because I dynamicly generate the textures on the fly. Just needed some way of getting rid of the anoying seams.
Thanks for all the insights,
11-03-2000, 10:35 AM
So you dynamically generate them on the fly?
Oh well, had a good day... Sorry.
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.