Hi,
Does anyone know how to use a separate
GL_TEXTURE_MAG_FILTER
GL_TEXTURE_MIN_FILTER
parameter for the depth axis?
Many thanks.
Hi,
Does anyone know how to use a separate
GL_TEXTURE_MAG_FILTER
GL_TEXTURE_MIN_FILTER
parameter for the depth axis?
Many thanks.
No can do (unless there's some specific hardware that supports it, like the PS2, and exposes it in an extension, which I think none does)
You may wish to look into TexGen in EYE_LINEAR space to emulate the effect you're looking for.
"If you can't afford to do something right,
you'd better make sure you can afford to do it wrong!"
Thanks!
Too bad though..
Must be a way to get to it, I simpy want to use 3d textures mipmapped and filtered in w/h but unmipped / GL_NEAREST in depth.
Wish things were a little more programmable.
Cheers.
Hi again. Re-activating an old post of mine.
I should probably dig into the specs myself but I can not wait to find out: Could this be done using fragment programs? Im sure it will be easy with GL 2. It would mean that instead of baking a big texture cake, and loosing tex tiling feature, we bind a 3D texture and switch texture using the 3rd (s)texcoord. All textures have to be same size though. This is also very usable for possible multi-layered depth shadow maps / projected soft-shadows.
Cheers.
FritzLang
[This message has been edited by fritzlang (edited 12-07-2002).]
Yes, you can put whatever you want into the "r" coordinte using a fragment program. Just like you can put z into "r" using texgen. However, that doesn't help you, because you will still suffer the filtering problem if you want to use mip mapping or anisotropy. The filtering is implicitly derived from your sampling instruction in the ARB_fragment_program spec.
"If you can't afford to do something right,
you'd better make sure you can afford to do it wrong!"
Thanks again!
So what you are saying is that fragment progams does not expose this type of
control, that after all the actual
function of filtering / mipmap is in the driver, making the effect of the code
below impossible?
// S & T
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_3D, GL_GENERATE_MIPMAP_SGIS,
GL_TRUE);
// R:
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER,
GL_NEAREST);
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER,
GL_NEAREST);
Cheers.
[This message has been edited by fritzlang (edited 12-07-2002).]
Filtering is done during rasterization. If minification is required, then the state you setup is used. Ditto for magnification.
It's not done per texture coordinate.
This case could be reduced do the 2D version where some rows require linear filtering, some require mipmaping, some nearest. How exactly would you do this?
V-man
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Fragment programs don't change the way regular OpenGL texturing filtering works, but it is possible to code your own filters using fragment programs. In your example, you could do 8 lookups into your 3D texture (using nearest filtering), and then do the interpolation however you like using a few lerp instructions.
Bicubic filtering, summed area tables and other interesting filtering schemes are all possible in a similar way.
Bear in mind this is will be considerably slower than a normal texture lookup since you're not taking advantage of the bilinear filtering hardware.
-Simon.
Make sure your texture coordinates on the 'unfiltered axis' are setup in a way that nullifies the effects of linear filtering.
Ie the r texture coordinates should satisfy
r=n*1.0/(texture_depth) + 0.5/(texture_depth)
where n is a whole number.
Eg for a 3D texture with depth of 256, the r coordinate should be one of these
1/512, 3/512, 5/512, 7/512 ...
and so on.
This will not disable the filtering of course, you'll still take the performance hit of the additional texel fetch. But the visual result should be what you want (if I didn't make any blatant mistake).
[QUOTE]Originally posted by V-man:
[B]Filtering is done during rasterization. If minification is required, then the state you setup is used. Ditto for magnification.
It's not done per texture coordinate.
I realise all this. My point was to use
a 3D texture as an array of 2D ones, the 3rd
coordinate just index into a 2D texture and "selects" it. Hence no filter and mipmap in the 3rd axis.
But I realize that getting into pixel programs, I sure loose the speed benefit which was the whole point.
I wanted to minimize texture bindings, being able to have texture id's in a vertex array and being able to use tiling. This way one
does not have to sort the render cue by material.
fritzlang
Posting Permissions
