Re: [Plib-devel] Work outstanding.

[Steve B. <sjb...@ai...>]

Gil Carter wrote:
> 
> <snip>
> 
> >You could write a function that could monitor the frame rate and
> >automatically try replacing texturing to look for swapping but I
> >think that's about as far as you can go.
> 
> I seem to recall people on the OpenGL Gamedev list talking a while ago
> about manually adjusting the MIP map level bias so that you can force the
> hardware to use smaller versions of the textures if you're swapping too
> much.  IOW, if your maximum texture size is 1024x1024, you drop back down
> the MIP tree to use the 128x128 or 64x64 version temporarily to keep the
> framerate up while your renderer gets settled again.

OpenGL 1.2 allows you to clamp the texture map so it doesn't try to use
a MIPmap level that you havn't used.

Also, there is (IMHO) an error in the OpenGL specification for how the
hardware picks which MIPmap to use - which results in a small amount of
texture aliasing at some scales and orientations.  Several OpenGL
implementations allow you to 'bias' the chosen MIPmap level by some
small amount in order to allow you a non-standard mapping function that
will remove that last vestige of aliasing.

> I guess that this idea can also be applied to having objects in the view
> frustum which are distant but visible.  For example, if your game has a
> "god monster" as the final challenge for the user to overcome, the model
> for that monster may well be very complex and heavily textured.  If the
> user can see the monster in the distance, it would be nice to be able to
> load the lo-res versions of the model textures at first, and defer loading
> of the more detailed levels in the MIP tree until you're getting close
> enough to start using them.

That should be simple enough to do - but the amount of storage for a
level boss will never be all that large to warrant the hassle.

Where it *is* useful is in things like flight simulation where you
need to be able so render low detail terrain out 50 miles or more - but
couldn't possibly afford to keep 2,500 square miles of terrain in
memory at any one time.
 
For texture mapping though, it's not a bad idea - but pretty hard to
implement in a general manner.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net