Is proper mosaic texturing with mipmapping possible?

[Arun]

First of all, just so I don't get any stupid questions... "Mosaic texturing", or simply "Packed Texturing", is a technique often used for things such as lightmaps where you got a lot of small textures, so you just put them all in a single much bigger OpenGL/D3D texture to achieve higher performance. The only not-stupid tutorial I found on the matter can be found at http://www.blackpawn.com/texts/lightmaps/default.html
This technique is also why, at least according to Gabe, Centroid Sampling is so important in HL2.

Anyhow, back to the real topic at hand which is... Is there, with the latest technical advances or perhaps with lesser known older ones, any way whatsoever to get solid, (nearly) artifact-free mosaic texturing? I'm mostly thinking about using it for a particle system (mostly weather) at this point.
In case anyone doesn't know why it isn't quite-that-obvious: An artifact-free mosaic texture requires you not to have any image in it influence another one. This generally requires you to align texels with a 0.5 offset and put a certain amount of unused (repeating?) texels around every image to prevent problems with filtering (yet another reason John Carmack is right when he says it's ridiculous the driver panel has full control over filtering preferences). However, with mipmapping, this offset is no longer aligned (you can't preserve the 1:1 pixel-to-texel relation), and the distance between two images can sometimes become negative! (considering two or more would be merged together at some or all points) One obvious way to fix that is to reduce the maximum number of mipmapping levels, but that's likely (if not certain) to cause shimmering.

And so I get back to my question: Is it possible to use mosaic texturing in, say, a mipmapped particle system, without any really visible artifacts? Any help would be greatly appreciated, come on, I'm sure someone here at least once tried to deal with such a problem Heck, I'm sure quite a few terrain rendering systems have had to deal with such a problem, and I'm quite curious how they're handling it!

Uttar

 

[Demirug]

Maybe this can help you: http://developer.nvidia.com/object/optimizations_for_dx9.html

Look for "Texture Atlases".

 

[Arun]

Wow, nice Strangely enough, the PDF was a broken link for me, http://developer.nvidia.com/object/nv_texture_tools.html is a real treasure though!
It sure makes me wish the NV50/R520 generation would allow for Volume Textures mipmapping to work in a 4x4x4, 2x2x4, 1x1x4 way That'd sure make this technique several orders of magnitude more straightforward! The comparaison utility in that package is VERY nice too, certainly gave me an even better view of the problems in real world conditions.

Uttar

 

[assen]

Maybe you apply an increasing level of blur to higher mip levels, to smear out the differences, so when polygons "borrow" texels from adjacent sub-textures, the error is visually smaller?

We use texture atlases for meshes, and there have been no visible problems so far. I was thinking of various non-solutions, like ordering the sub-textures within the atlas so that adjacent texture are more likely to be similar color; so far, however, there hasn't been a real need to do something like that.

 

[[maven]]

I haven't looked at the link and neither thought this through (just got up ):
How about seperating the charts with a 1-texel with alpha = 0x00 (and 0xff everywhere else). Then you can check in your pixel shader when a texture sample ins influenced by the outer border of the chart (as soon as alpha > 0x00) and "act accordingly" (whatever that may be). Maybe you could bias to lower (i.e. larger size) mip-map levels?