Re: [Plib-devel] Work outstanding.

[Gil C. <g.c...@ca...>]

<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.

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.

(Hmm... Better get the real story here... Digs back through archive of 
OpenGL messages...)

Aha, here's the basics of it, courtesy of Tom Forysth and Sean Palmer, 
posted September last year:

"I remember Jan Svarovsky from Muckyfoot talking about something like this 
at GDC99 - he called it "Just Too Late" caching :-). For older cards, where 
he had to do manual texture management, he always kept all the visible 
(according to the frustum) 16x16 mipmaps around - they don't take up too 
much memory, so they can all be loaded onto even the most modest card.  But 
he would swap around the larger texture maps at the start of every frame 
according to heristics like "how big do I need this" and things like that. 
However, sometimes the prediction heuristic fails, and you end up drawing a 
large polygon, but you haven't got the properly detailed mipmap levels loaded."

"Rather than interrupt the polygon drawing to load the texture (stalls the 
pipeline badly, especially on older cards), he just drew the poly with the 
16x16 texture (always resident), and loaded the proper high-detail mipmap 
level next frame. So for one frame, the image was blurry, but it sharpened 
up the next frame. He said it was very rare to see any big problems - you 
really had to pick pathological situations to see the artifacts. And the 
performance boost was good."

"I suspect this priority scheme would produce similar effects - sounds 
plausible and cunning. (of course, the Permedia3 doesn't need any of this 
stuff anyway - so I can probably safely adopt the role of netural IHV :-)."

Tom Forsyth, DirectX Team, 3Dlabs
email: Tom...@3D...
On Tuesday, September 28, 1999 6:13 AM, Sean L. Palmer
[SMTP:sp...@po...] wrote:
 > > You mean like I am doing right now? The only extra thing I need to
handle
 > > this stuff is more control over the mipmap stuff, such as giving some
 > > textures a lower priority -- which then should (IMHO) directly relate to
 > > what mipmaps are loaded. If a texture has a low priority, and I have
 > > extra texture memory, then the lower priority texture should have a low
 > > level mipmap loaded in.
 > >
 > > Is this a reasonable thing to ask for? I don't see why it shouldn't be.
 > > Even if we need an extra extension for mipmap priorities on top of the
 > > current texture priorities.
 >
 > How about if smaller mip levels automatically get 2x the higher mipmap's
 > priority? So to completely unload a mipmap chain, set top-level priority
to
 > 0. If you set top-level priority to 1, then for a 256x256 texture the
 > following priorities would be generated down the chain:
 >
 > priority size
 > 1 256x256
 > 2 128x128
 > 4 64x64
 > 8 32x32
 > 16 16x16
 > 32 8x8
 > 64 4x4
 > 128 2x2
 > 256 1x1
 >
 > Thus, teensy mipmaps would generally always be loaded, so no matter what,
 > you'd at least have *something* to draw with. If you were out of memory
and
 > tried to load a similar texture with top-level priority of 16, it could
then
 > free the top 4 mip levels of the priority 1 texture, giving enough room
for
 > all but the highest mip level of the new texture.
 >
<snip>

>Anyone know of any opengl texture management articles that cover scaling 
>back the textures in use automatically?

Have a look at http://vterrain.org/Textures/ground_textures.html for a 
general discussion of this topic.  In fact, the whole Vterrain site is a 
good read for topics relating to this.

Rgds,

Gil