Info from John Carmack (11)

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Wed, 26 Jun 1996 12:12:45 +0200 (MET DST)

Date: Wed, 26 Jun 1996 12:12:45 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <>
Subject: Info from John Carmack (11)

Note the part on releasing the tools.


----- Begin Included Message -----

>From Wed Jun 26 05:34 MET 1996
From: John Carmack <>
Date: Tue, 25 Jun 96 22:34:20 -0500
To: Bernd Kreimeier <>
Subject: Re: q&a?

>Err - "interact" does mean "intersect" here? Surely there is
>interaction (i.e. collisions have to be detected). Anyway...

Actually... Brush models do NOT do collision detection with each other.
There are a few reasons for this. The practical one is that if they
collided, every door frame and life bottom would have to be hollowed
out to receive the moving object, creating lots of wasted geometry.
A more serious one is that doing proper continuous collision between
arbitrary models is a real bitch of a problem. Simple intersection
testing isn't bad -- merge the two BSP trees and look for double solids,
but saying: "This complex object is moving towards this other one, give
me the exact time of impact" is HARD. Server time already chews up a
lot of processing.

> I do not understand how the world can contain concave polygons
> or polygons with holes, using a BSP

Qtest1 had non-convex polys, but quake 0.91 does not. If you put the
polygons on the seperating planes instead of in the leafs, they can be
any type you wish. There are tradeoffs both ways.

> Non-moving objects could be maintained in lists of pointers
> in each leaf they're partially in (or subtree they're completely

Basically. The culling is actually done on the server side now, to keep
network traffic down. The refresh is just presented with a list of
objects already known to be in the pvs.

>To be a vehicle, it has to have a walkable inside. Thus it has
>to have a clipping hull, just like a very small level. Now what
>happens once the POV or an entity is inside the bounding box of the
>vehicle? Each movement has to checked against the BSP/hull of the

Brush objects do have proper clipping hulls, so you could ride around in
one, but they do not contribute at all to the PVS culling. They are added
as edges, so there is no extra overdraw of the world, but all the geometry
is still processed.

> >
> >Release of tools and source code for user prog coding and level
> >building.
> To keep us from asking this too often: will this happen prior to
> shipping CD registered? pop.lmp will prevent testing third party
> levels until then.

Yes, it is likely the utilities will be released in the next week or two,
I just need to spend an hour or so packing them up and writing some brief
comments about them.

I worry a little that I would be encouraging people to hack around the crc
checks, though.

> I am preparing a WAD2MAP conversion for DOOM levels: now I suspect
> that you won't be too enthusiastic to see dumptruck loads of DOOM
> levels used with Quake, so feel free to object. Btw., are the
> s_scale/t_scale entries already processed by Quake 0.91, or are
> they just dummies?

Yes, the s/t vectors are properly used in 0.91.

A wad converter might be an interesting way to bootstrap some development
until real editors are available. Use a wad tool for geometry, then run it
through light and vis.

You should be aware that some styles of levels that are commonly created in
DOOM will take an extremely long time to vis: huge open areas with lots of
two sided lines in them.

> >Writing a proper full radiosity replacement for the light utility.
> I plan on looking at HELIOS by Ian Ashdown, to see whether it could
> tweaked to use a NAT grid.

It should be reasonable to resample any given light map to Quake's grid.

> >Reasonable user suggested improvements (keep it in the discussion
> >groups please, I get enough mail as it is)
> Uhmmm - this got me sending this out-of-turn mail. If you want me
> to abandon the q&a from now on, please let me know. In any case,
> I'd like to invite you to use the Hypermail archive of the Quake
> Developers list at your convenience, at

I almost never mind answering well thought out technical questins -- its
the "I want to duck!!!!" type emails that bug me.

> >The Next Generation Technology. (no, I won't give you a code name
> >to talk about!)
> Well, this is a game you already lost: we will talk about NGT - be
> it Next Generation Technology or Next Game Title or Nifty Gruesome
> Texturemapper... thanks for coining this one ;-).


John Carmack

----- End Included Message -----