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.

Implemenation

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:

defining entities

This could be done selecting prepared ASCII inserts, and editing them as necessary. Should use a template mechanism and a selection browser (file browser, preferably) from the very beginning. Another mechanism is creating an entity from a set of brushes. Thus the entity is a template.
defining brushes

This will involve creating, rotating, re-orienting, moving of 4 or more planes. Template selection again.
defining planes

Three coordinates, explicitely or implicitely chosen, e.g. by selecting a class of plane (facing X, in XY, free) Selecting a texture from a ASCII list or browser. Setting negate_s, negate_t, exch_st flags. Setting s_ofs, t_ofs.
reading and writing MAP files
handling entity templates
handling brush and set of brushes templates

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 )
}

Clipping

Carving

Dragging

Shearing

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:

Choose a Facet (in any view, click on a visible surface).
It is now shown in a perpendicular view "down", the view_up matching Z as closely as possible. If it is a floor or ceiling, view_up matches Y.
Adjacent polygons are shown with perspective correct texture mapping. The range of view is chosen as a small multiple of the bounding box of the texture, e.g. from 1.0 zoomed upward. Adjustable interactively and in preferences.
Now mouse/cursor controls rotation, flips and scaling in a Free Mode.
In NAT mode, Naturally Aligned Textures are calculated, only limited changes are possible (cursor/mouse again).

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 dEr95 r3D dread netrsc quake doom legal web