I have an issue regarding texture atlases and "texture bleeding" using mipmaps and anisotropic (or linear) filtering.

I know that this is not directly related to PolyVox, but I thought that since there are a few people on this forum that are developing a "cube game" using PolyVox seemed acceptable.By the way, why not creating a forum category for stuff like this ? Or more directly with integrating PolyVox with other libraries ?

So I'm trying to use only the "middle" of the texture and repeating it so that the "bleeding" disappears.But there my knowledge of shaders is too limited so after several hours of fruitless efforts I'm asking you

The first image you can see see a border around it because I think my texture access is still off by one. I just don't have time to fix it right now.

Anyway, here is what I got... There are several things you need to be aware of:

1) The images of the atlas start in the middle. Therefore, you have to shift each by 0.25 in atlas local coordinate. 2) Since every image is in the middle, the width of each image is only 0.5. (This is assuming all "images" are uniform size; if they are non-uniform, you have to store extra information per image).3) If you are generating per texture texture coordinates from the world position, you have to be make sure they align. Note: You may not have to do this if don't generate tex. coords from world position. I will get to this in a min.

Here are the shader code (it's all Cg): WARNING THis will not work as-is for GLSL since the texture origin are different.

The vertex program:

When I say image, I mean the actual image. A texture atlas is just the entire texture atlas.

* uv1 (texture coordinate 0) is the texture block ID. The index of a block is from 0 to 256. To get it intothe texture coordinates into the range [0, 1] I divide by 256.0. Then in the vertex shader I get it back into the range of [0, 256]. There may be other ways to do this it's just how I'm currently hacking it.

* from the texture block id, I then compute texture atlas row and block x,y. It's just a 1D to 2D array index thing.

* I output the "worldPos" of the cube, which really is the center of a cube. Also, it's not really world coordinate. It's a local coordinate in "chunk space". So if my chunk is 32 x 32 x 256 (i.e. x in [0, 32], y in [0, 256], z in [0, 32]), "worldPos" will range in this.

*I compute per image UV for each image that is in the range of [0, 1] from the interpolated worldPos. Basically, from the vertex shader, textureAtlasOffset is the origin of each image in texture atlas coordinates (remember we offset by 0.25 to get to the middle of the position; I should rename it as image origin). Next, we compute the actual texture atlas uv by adding per image uv to textureAtlasOffset (origin). Also remember that the actual image is in the middle, therefore scale by 0.5.

*Make sure you texture image "align" properly. This because how the per image UV is computed from worldPos.

*Lastly, this is just how I'm hacking it. There may be other ways to do this so to avoid some of this.

what do you mean by that? Are you using Ogre? I didn't even now there was a way to turn off mip mapping, maybe you disabled it in the dds generation?

I think it works for me but I haven't looked to make sure it's actually "working" I mean it looks like it's there...damn.

Oh btw, when I used that tool from that Ogre link, I had some problems with the textures being in unexpected positions in the atlas. I had to write a custom python script to manually output the textures in the order I want. And also, the default dimensions from that tool are weird, the default value likes to strech on the width. It's weird, you just have to mess with it man.

what do you mean by that? Are you using Ogre? I didn't even now there was a way to turn off mip mapping, maybe you disabled it in the dds generation?

Yes I'm using Ogre 1.7. I'm deactivating mipmaps in the .material file like so :

Code:

filtering anisotropic anisotropic none

max_anisotropy 4

That allows anisotropic filtering but deactivates mipmaps. (the "none")

Quote:

Oh btw, when I used that tool from that Ogre link, I had some problems with the textures being in unexpected positions in the atlas. I had to write a custom python script to manually output the textures in the order I want. And also, the default dimensions from that tool are weird, the default value likes to strech on the width. It's weird, you just have to mess with it man.

Yes I too have such problems, the texture order seems to be dependent of the order of the input textures filenames.For the resulting atlas not being size squared (square sized ?) I'm just adding dummy textures at the end...

Who is online

Users browsing this forum: Bing [Bot] and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum