Re: No texture patches

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Thu, 18 Apr 1996 18:40:20 +0200 (MET DST)

Date: Thu, 18 Apr 1996 18:40:20 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <199604181640.SAA01981@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de
Subject: Re: No texture patches

A posting back from the quake-editing era....

>From: Uffe Friis Lichtenberg <uffefl@diku.dk>

>It is clear to us by now that Quake does not support Doom-like
>texture patches, so that we could create a multitude of textures using
>only a small set of building-block-textures. The question is: is it a
>problem that we somehow can circumvent?

>The best I can come up with is implementing signs using billboard
>objects.

Having an object (entity) aligned with a wall will work, as long as
you do not forget that the light maps will not be used on the object,
only on the surfaces behind. Btw., a better (OpenGL-ish) name for
such objects pasted to walls would be "decals"

>I can't really think of a situation where I would wan't the
>texture patches from Doom available,

If I understood correctly: textures are references by MAP files by name.
The "qbsp" utility creates surfaces from brushes, and keeps track of
which textures have been used. Then it will look up the textures in
a (might even by DOOM-style) WAD ("wad" ".../gfx/base.wad"), and create
the mipmaps. I wonder if the anti-aliased scaling is done every time,
and if TEXTURE1/2 are still (perhaps modified) in use.

Any such processing of multi-patch textures (from DOOM or whatever) to
mipmaps could be done seperately.

>Anyway, I think that the problems of integrating texture patches in the
>Quake engine now would surely exceed the gained flexibility (unless
>ofcourse they already are supported, and nobody found out yet :).

Perhaps my page has been inconclusive:

a) using patches saves some texture memory, but not surface cache.
It would ease adding small variations and navigational aids to
basic (flat) textures

b) all available descriptions of the renderer state that the suitable
mipmap from a texture and the light map for (potentially) visible
surfaces are combined once. The result is stored in the surface
cache, as long as memory is available, and the surface remains in
sight.

Adding some simplified patch mechanism (e.g. one flat texture, opaque,
and an optional list of partly transparent patches/decals) to this
preprocessing "mipamp+lightmap -> texture in surface cache" would surely
be feasible. In this case, the decals would be subject to the same
lighting. They might even be flagged for "bright", in that case the
patches would be added after lighting the appropriate mipmap.

Hope that made more sense, this time.

b.