Re: Map Conversion Utility, Anyone?

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Wed, 13 Mar 1996 19:43:40 +0100 (MET)

From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Wed, 13 Mar 1996 19:43:40 +0100 (MET)
Message-Id: <>
Subject: Re: Map Conversion Utility, Anyone?

>I confess I'm not an expert in the theory behind
>the parallelization of algorithms such as BSP tree generation, so I don't
>know how practical this is

Creation of a BSP is a problem of making decisions (read: selecting the
right toplevel splits). This allows for brute force parallelization.
Heuristics or branch'n'bound are still exploring search trees - you might
try out alternatives in parallel.

I do not know about any BSP specific parallelization. Anybody?

Remebering the quoted John Carmack explanations, "qbsp" will not be the
problem anyway, nor will the radiosity-style "light". According to
this posting, the "vis"ibility list calculation is CPU intensive
despite being fully parallel.

Without looking into the details my guess is that parallelization of
this is not difficult (more or less optimal distribution of source nodes
on target processors), as long as each CPU gets a full copy of the
map data - any other node might be a possible destination for LineOfSight
and visibility checks.

On the other suggestions:

- to my experience, a decent editor is 90% GUI in terms of development
effort. The WAD/PACK details do not matter in this regard. Come to
think of it, it is simply the same problem any decent 3D modeler faces.
Start thinking "plug-ins" instead of node builder etc. :-).

- conversion of DOOM levels requires tools that depend on
WAD/PACK details - as those, in turn, depend on the algorithms
used. Read: id stating the files will change means the algorithms
will change. Thus the "qbsp"/"light"/"vis" tools will change.
While conversion is surely a step to go, I doubt it is a good
intermediate. You will probably neither see those in 2-3 weeks, nor
is the code likely be more reusable than any editor's.
Of course, simplified conversion (no lighting, dummy visibility lists)
are entirely possible.

- a much more valuable intermediate might be working on VRML, DXF or 3DS
conversion, which would allow for both display (utilizing VRML browsers,
POVRAY) and map editing (commercial modeling software).

- note that we do NOT have any map representation in the PACK/WAD/BSP.
It includes pre-processed lookups, but not the Constructive Solid
Geometry scene description. DOOM-speak: SSEGS, but no LINEDEFS.
We have to make up this up (e.g. by taking the Geometric Workbench
from Mantyla).

Of course, converting DOOM files has the advantage that there is
a generally accepted (albeit restricted) map representation, and
working editors. Thus you have a point.

>From: "Brian K. Martin" <>
>I think a doom map converter will be out as soon as some one
>releases a utility which calculates the BSP tree for quake.
>Isn't that what most of you are waiting for?

Indeed :-).