Mipmapping accuracy

[square]

First, excuse my English.

I have a problem with mipmapped textures :
-To reduce the number of textures I group them in a big texture.
-The polygons are associated to the little textures with textcoord.

It works well with the following constraints:
-Each little texture may have a width and a height equal to a power of two (for mipmapping).
-Each little texture may be located within the big texture in a subdivision of two (for mipmapping)
-The UV textcoords may describe the relative position of the corners of the little texture within the big texture.
-The UV textcoords may be shifted for half of pixel !!!

If I don’t shift the UV textcoords, polygons use a portion of the neighbouring textures.

This phenomena appears again with mipmapping because the shift is no longer valid :
For a 1024x1024 texture, the shift is 0.5/1024
With mipmapping the texture becomes 64x64 for example and the shift may be 0.5/64.

What can I do ?
For example, how can I precise different UV Textcoord for each mipmapping level ?

Thanks.

[Roderic (Ingenu)]

So you know how mipmapping does work.

My first comment was harsh, sorry http://www.opengl.org/discussion_boards/ubb/frown.gif

(That's why I deleted it)

You seems to say that even with repeating border pixels, their is a problem, but AFA I understand, it can only be there that's there's a problem.

The averaging of the pixels color values at texture borders will get worste as your mipmaps will be small, because more and more pixels are averaged.
I do think that you can build your own version of mipmapping functions taking care of not averaging neighboor textures color value.

... tell me how you did your mipmapping levels, please.

[This message has been edited by Ingenu (edited 10-27-2000).]

[zed]

mate u can build your own mipmaps and specify each mipmap level yourself + this way u wont get the colours running into each other.
also i dont know if grouping a lot of textures in a big texture is a good idea sure less binding of textures but u have to contend with bleeding and also the cache

[square]

For Ingenu :
I know how mipmapping works, thanks.

If you READ again my message, you can see the location and size of the little textures are particular. So the mipmapped textures doesn’t mix color of different textures !
For example 16 textures of 128x128 pixels can be stored in a big texture of 512x512 pixels.
Mixing doesn’t occur since the mipmapped texture is larger than 16x16 pixels.
Ok, the colour is bad when the polygon appears very small (one pixel).

So, Ingenu, I don’t have problem when creating mipmaps.

The problem is about textcoords (read first message).
-Shifts have to be set for each textcoords to avoid wrong averaging.
-These shifts are function of the size of the texture (0.5/size)
-It may be different for each level of mipmap

I know it could be impossible.

For Zed :
Thanks for your constructive response

I tried two solutions with gluBuild2Dmipmaps and my own mipmaps function. It doesn’t change anything because the problem is not here.
This application is running in a Silicon NT 320 or 540 so I have a lot of textures and no problem of cache. With this technique I can handle 40000 different textures including radiosity illumination with only 150 big textures 1024x1024 (total 600 Mo).
It works well but some problem appears sometimes with mipmapping.


[This message has been edited by square (edited 10-27-2000).]