I’m working on an application for rip mapping (extended mip mapping.
For selecting the correct rip map level (LOD), I need to find to partial derivatives Sx,Sy,Tx and Ty) Anyone know how to do this?
I have one method in mind, but for this I need to know the 3D-world to screen mapping and the inverse pixel mapping.
I can’t find the routines in OpenGL to get them. Anyone?
So what I need is: I give some point of a polygon, and the routine gives me the position on screen as a result. Then I give this screen postition, and another routine gives me the corresponding area in texture space for this pixel.
You can calculate the derivatives per vertex, and send them in as interpolands; that might be close enough.
Also, the NVIDIA-specific NV30 program language provides derivatives for almost any quantity at any point in your fragment program.
Why not just turn on GL_ANISOTROPIC filtering with a high degree of anisotropy, and let the hardware do the filtering? It’s likely (but not guaranteed) to go faster than anything you can code yourself in a shader.
Anisotropic is also better than RIP Mapping because it needn’t be axis aligned, but RIP mapping may be faster under some circumstances because of the way it stores prefiltered copies of the texture and reduces the number of taps required.
RIP mapping could also help you go to higher degrees of anisotropic fitering than are supported in hardware for specialist applications, for example a train driving simulator or the runway in a flight simulator. Realistically there seem to be few applications that you’d actually notice anything better than 8:1 anisotropic filtering.
I am curious though, if you are using this in a shader it’s too late to change state so I assume you’d apply the RIP map using blends between multitexture, and that would be much slower and a waste of time IMHO unless this just a demo.
I’d advise doing something on the host to compute if something is severely anisotropic, then use Anisotropic filtering in conjunction with RIP texture to hide the details. This way you can go better than the hardware anisotropic ratio, improve performance and really only approximate the calculation for of texture derivatives and their ratios before choosing a RIP texture, more. Importantly a CPU driven scheme lats you bind a single texture with the s&t ratios desired.
Because of the interraction of anisotropic texture I’d also not build the full RIP maps I’d maybe just build one that’s ohh… 4:1 on each axis. Then turn on 8:1 anisotropic filtering and select the RIP map if the ratio and foreshortening indicated anything 6:1 or better was needed. This way you have a big target to shoot for, the hardware covers for any sloppy arithmetic and you should achive up to 32:1 anisotropic filtering IF you are axis aligned. You will probably also see a performance gain and may want to squeeze your 6:1 threshold to maximize this.
[This message has been edited by dorbie (edited 07-13-2003).]
RIP mapping has one serious problem:
While 2D mipmaps are bounded to 30% higher memory consumption than the level 0 texture, 2d rip maps can go up to 3 times level 0. Keep that in mind.
I’m doing this for a project. The purpose of the project is to illustrate how rip-mapping works and that it is better than mip-mapping. Performance is not the main target of the project.
So I need to stick to rip-mapping for now.
This is what I got. I build the full rip-maps (offline) read them into my program and then I draw the scene (which is composed of quad planes, walls).
So what I need is a method for selecting the correct RIP texture. I do apply the RIP textures by blending multitextures.
As an approximation, I only select a RIP texture for the whole wall in each frame.
So I do not need to compute the derivatives per pixel, only per polygon (perhaps for each vertex of the polygon).
I have two solutions in mind for doing this:
computing the derivatesand use them as selection of the LOD. But I don’t know how to compute the derivatives in OpenGL :-s Anyone can explain it to me?
A more naive method: Computing the screen coordinates of the polygon (and so the amount of pixels covered by the polygon in two dimensions) and comparing this to the amount of texels covering the polygon on screen. By comparing these I know the anisotropy. But I only manage to compute the window coordinates and I need the screen coordinates. Anyone how to compute these? (And I also need to compute the inverse texture mapping, although I might be able to avoid this, still figuring it out).
zeck, my suggestion doesn’t use 3X :-), but it does need anisotropic filtering too… “RIP map enhanced anisotropic filtering…”, The actual overhead is very small beyond the 1.33X for MIP. In addition for constrained cases you need only RIP one axis, for example in a simple maze demo the walls should probably only be RIP maped along one axis, but the floor and ceiling should RIP along two.
Don, there’s not much difference between each of your methods if you want to do them right. Screen space derivatives require projection of something to screen space, although I have implemented some hacks in the past to simply compute V.N to lookup a RIP level (approximate and cheesey but it worked). For quads in a maze this would be a very simple and workable aproach.
Here’s the quick & dirty approach I implemented, the ground is split into quads with a texture handle at each quad. It takes a bit of tweaking to get right, and it is flawed but when I implemented this I was pretty much asking myself the same question you are and I wanted something fast & CPU driven. http://www.sgi.com/software/performer/brew/anisotropic.html
I’ve since tried other things like the projection of the view vector into tangent space and this can work too and be faster than the projection of points into screen space for derivative evaluation, but you do need to account for tangent space derivatives and perspective scale.
Remember that each RIP texture you have is also MIP mapped and the hardware handles that for you so it really boils down to evaluating ratios and making sure a minification filter is appropriate, doing a full blown derivative evaluation is overkill (probably).
[This message has been edited by dorbie (edited 07-14-2003).]