maybe that would be a better topic for 2.0 suggestions, but first i should make sure there isnt already a way that im too blind to see.
everybody and their dog have written a terrain renderer, so adding a little more that others didnt have is a tempting goal. so besides wasting time on the “perfect and most efficient quadtree” and smallest size possible i want some flexibility in detail textures and, to make things worse, i want it in one pass.
after my last terrain i decided that 3d textures sound perfect. you could only blend between two adjacent slices, but that seemed ok. of course distant terrain looked horrible, so mipmapping was next… and the end of the 3d approach. though i can specify width and height for each mip level opengl now hates me for trying to break its mipmap chain by not reducing the depth of the texture too.
to get around the selective restriction i added two textures, one containing the 3rd tex coord in each channel, the other containing the blending weight in each channel. its hell to work with it and still wouldnt solve the mipmap problem.
fine, i’ll place them in 2d and all next to each other. silly idea that already didnt work the last time around. texcoord fiddling (adding half a pixel here, subtracting a pixel there) would reduce bleeding and just duplicating the edge pixels would probably be a cheap solution to make them fit. tiling though seems impossible. with one “slice” ranging from 0-.25 theres no way to make it tile (none i could see at least). so after an afternoon of trying to cook up a shader to fix that i realized its impossible to tell if .3 is supposed to be slice2 or a tiled slice1.
next thought was: hey, im not using a gf3 anymore, this card shouldnt mind a dozen textures. in terms of “it works” it doesnt, but judging from the impact of sampling more than 4 textures i would guess the number of pipelines of a rad9800 to be 4.
multiple lookups into the same texture seem much cheaper, but how to store a bunch of textures in one to allow for tiling? for a second i wondered if subimage might help and if even when treated as seperate textures it would allow the driver to be clever. unfortunately i wasnt clever enough to notice that subimage wont allow multiple subimages for the same texture (if it does, i cant see how).
so, what i would need is somewhere between 3d texture and mipmap. multiple slices in one texture that can be independently sampled. removing the restriction for mipmap sizes would be great and allow just that, but somehow i feel the driver is using level 0 to decide how much memory the texture will need instead of adding more with each level (and it saves the trouble to store the offset for each mip level).
can it really be, that with all the programmable hardware and extensions and whatnot its not possible to achieve what i would consider a simple goal?