Re: [Mesa3d-users] 256x256 texture size limitation

[Stephen J B. <sj...@ht...>]

On Thu, 4 May 2000, Robert [ISO-8859-1] Bäuml wrote:

> we're also using Mesa in our project Doom Legacy and recently came over a
> well known problem with 3dfx hardware: There is no support for textures
> above 256x256.

It's a hardware limitation of the 3Dfx card family.

> I know, OpenGL does not guarantee large texture sizes, but
> wouldn't it be a nice feature if there were a SW workaround for this HW limitation
> built into Mesa? 3dfx Voodoo cards are currently widespread and programmers
> wouldn't need to make special hacks for those cards to make it display
> properly.
 
Well, you have to ask what you'd have the software hack *do*.
I can only imagine three options:

1) Automatically drop the resolution when maps larger than 256x256
   are presented.  This is something that the application can
   (and should) do.  Use a proxy texture to discover if your map
   will fit - if it doesn't, throw away that MIPmap level and
   try again with the next one down.

2) Revert to software rendering for large maps (I don't think
   you'd like that - and it would certainly break existing
   programs that use mechanism (1) above).

3) Chop large textures up into 256x256 chunks and do an on-the-fly
   polygon split - applying different textures to different parts.
   I believe that this has been tried before on some Windoze 'mini-GL'
   driver from a company that OEM's the 3Dfx chipset. I forget who
   that was.

   This is probably the fix you are thinking of - but think for
   a moment about the implications:

    * When you split up a polygon, you'll sometimes create 'T' edges
      that'll cause cracking in the database. That sucks.

    * Sometimes, I might have a texture repeat across the polygon
      ten times in each direction.  If that's a 512x512 map, the
      splitting process will generate 800 triangles from that single
      input polygon!!

    * There is no way to avoid seams in your polygons where two
      sub-textures meet along a newly created edge.  You can't
      fix that problem.

    * Switching texture maps is a costly process (compared to
      drawing polygons at least) - whenever you split a polygon
      into four so that you can render it using four sub-maps,
      you get four additional texture map switches.

    * The cost to compute the split up polygons is non-trivial.

    * Bad things happen if you render in glPolygonModes other
      than FILL.

    * Colour shading across the split polygon (which is not
      perspective-correct in the 3Dfx hardware) will result
      in colour and lighting mis-matches along the border
      of polygons that have different texture resolutions.

    * In some multipass algorithms, the two passes may have
      different resolutions of texture map (eg Quake - which
      has really low-res lightmaps).  The change in roundoff
      error that would result from the splitting up of the
      higher resolution map but not the lower resolution
      version would certainly cause Z-fighting.

Note that the older 3Dfx cards have TINY amounts of texture
memory anyway - if you split large maps into tiny ones, you'll
be texture paging all the time.

So, I think that *by far* you are better off living with
the fuzzy maps and going with method (1) - have your
application automatically drop the higher resolution
maps on hardware that can't hack it.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@ht...            http://www.hti.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1