QED - Quake Editor Sketch

This document serves as a sketchy proposal of an editing tool, conveniently named Q.E.D., aka Quot Esset Demonstrandum, if I am guessing correctly - this name will hopefully experience a minor change, later on. This document is closely related to the Quake Editing Primer that introduces terminology and concepts.


QED will be written for Linux, XFree86, using Mesa and the OpenGL API. Lacking the time for any tim consuming alternative, I will probably use OSF Motif 2.0 and the CDE Application Builder which will be available for Linux soon.

I do not know if QED will ever be a useful editing tool. The emphasis will be on implementing different ideas to create brushes, group brushes, and create templates. Even if you will not be able to do map editing with QED, it might ease creation of unusual brushes.

QED - A minimal 3D editing tool

A basic editor should allow for the following basic operations:

Editor Modes of Operation

Brush Editing

Brush Template

A Brush Template is a Brush, stored in a different way. Like a Brush, any Brush Template consists of 4 or more Planes. We should try to store Brush Template using floating point coordinates, but bear in mind that more complicated shapes (i.e. polygonal approximations of quadric or curved surfaces) will change if mapped to a coarse integer grid after sacling down. This mapping will have to occur as soon a a scaled Brush Template is instantiated as a Brush.

In addition, there is no Texture on a Brush Template. I am not yet sure about this, as one might find ways to define texture offsets and orientations invariant with respect to scaling.

Examples of Brush Templates are the tetrahedron, the isocahedron, the cube.

  ( 0 0 0 ) ( 1 0 0 ) ( 0 1 0 )
  ( 0 0 1 ) ( 1 0 1 ) ( 0 1 1 )
  ( 0 0 0 ) ( 0 1 0 ) ( 0 0 1 )
  ( 1 0 0 ) ( 1 1 0 ) ( 1 0 1 )
  ( 0 0 0 ) ( 1 0 0 ) ( 0 0 1 )
  ( 0 1 0 ) ( 1 1 0 ) ( 0 1 1 )





Texture Mode

Texture Entities

This a an editing concept I am proposing that is not used by QuakeEd. The basic idea is that a Brush is supposed to be a block of material, and that "being marble" or any other material is a state in itself. Thus a Facet or a Brush is referencing an Entity, and the Entity is referencing a state and a related visual appearance. Unfortunately, the engine does not handle texture animation issues this way, too.

As far as editing is concerned, the major benefit is a more abstract and intuitive way of maintaining aliases. Instead of choosing a given Texture while editing a Brush, one might as well define a Texture Entity, and try different alternative Textures later on not by changing the Brushes, but only assigning different Textures to the Texture Entities. This, in a different context (namely SGML) is called descriptive vs. procedural markup, and the use of external entities.

In my proposal, Texture Entities are marked by &l; preceeding a Texture Entity name. Thus &l; is no valid character in a Texture Name anymore. Prior to creating a MAP file suitable for qbsp, all external Texture Entities will have to be replaced by valid Texture Names.

Texture Alignment

Texture Alignment Mode

Here is a proposal of a Texture Alignment Mode operation:

There might be more sophisticated means, i.e. a chain mode, in which a sequence of textures is selected, and changes propagate, or a tree mode, in which changes propagates to a subtree. Note that no cycles are allowed on polyhedra. One will have to face a similar problems with assigning skins to MDLs, and perhaps the same editing module might be used for that purpose, too.

home qdev qdev dread rsc qdev doom license web
home dEr95 r3D dread netrsc quake doom legal web
Author: B., email to bernd@nero.uni-bonn.de, with public PGP key
Copyright (©) 1995, 1996 by author. All rights reserved.
Source: $Id: QED.html,v 1.4 1996/06/19 23:52:19 b1 Exp $