Re: No texture patches

Uffe Friis Lichtenberg (
Fri, 19 Apr 1996 00:48:38 +0200 (METDST)

Date: Fri, 19 Apr 1996 00:48:38 +0200 (METDST)
From: Uffe Friis Lichtenberg <>
Subject: Re: No texture patches
In-Reply-To: <>

On Thu, 18 Apr 1996, Bernd Kreimeier wrote:

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


(BTW: Thanks for all the hard work!)

> >From: Uffe Friis Lichtenberg <>
> >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.

This is a problem! Billboard objects would probably always be flat- or
perhaps gouraud-shaded, and not with light maps, so they would always
stand out in some way. This would have to be taken into account when
designing the level, and thus put a constraint on the level designer.
This is a Bad Thing.

> Btw., a better (OpenGL-ish) name for
> such objects pasted to walls would be "decals"

Quite. But having another term for billboard objects used only in this
context would only lead to confusion. Anyway they aren't (as far as I can
see) in any way usable as decals: they are individual objects that can be
placed anywere in the world; they are not bound to a wall!

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

Well that depends on qbsp of course. Though the anti-aliased scaling
isn't a very computationally expensive process, it would be a rather
silly waste of CPU resources to do it everytime the textures were needed.

My guess is that the wad files with textures contain all the four
resolutions needed. Hopefully it is so: this opens up for some
interesting special effects, like secret messages only visible when very
close to the texture (or possibly very far away :). Try fooling round
with MipDip and edit the different mipmaps without resampling them, and
you'll see what I mean.

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

Yes. Even if Quake doesn't support patches it would be rather easy to
implement a small utility that could build the relevant textures using
some sort of patch description. This would of course not bring down the
runtime overhead induced by having many textures in memory at one time, but
would allow level-designers to easily create textures using the many
existion Doom texture packages.

Besides if the target machine has enough RAM it would clearly be more
speed-efficient to disable patch building in real-time!

> 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

Well... Using billboard objects could probably make adding navigational
aids equally easy, but the small variations is still something that Quake
seemingly doesn't support well. This might need a separate utility
depending on how qbsp handles it. Alternatively my previously shown
method of splitting up a surface in several sub-surfaces could solve some
of these problems.

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

Though the combination of mipmap and lightmap is a trivial process
(using colour mixing LUTs, or in Quakes case, colour lighting LUTs) it is
not computationally cheap. It does involve at least one table-lookup per
texel. Adding a patched texture building before (or after) this would add
to the total overhead each time a texture had to be fetched into the
surface cache.

I'm not sure of how much overhead this would amount to, but it is still
something that would slow down Quake. By this reason alone I would say
that the patch building of textures should be done as a preprocessing
step, even though it would make distribution files larger (unless we can
agree on a distribution format that supports patches) and memory
requirements larger. It is though a serious problem that Quake only
supports 256 textures total on a level: lets hope that id fixes this ASAP.

(BTW: files with many areas of great similarity --- as those build using
a patch texture building approach --- would compress very well with
Lempel-Ziv based compression algorithms. This of course includes most of
the compression utilities today. So the net.bandwith load wouldn't
necessarily get excessive.)

> Hope that made more sense, this time.

Quite. I guess the motto of todays lesson would be: buy more RAM :) And
harddisk too...

Uffe. [uphfe]

"This .signature hasn't been left unintentionally void of blankness"