Info from John Carmack (10)

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Mon, 17 Jun 1996 11:31:23 +0200 (MET DST)

Date: Mon, 17 Jun 1996 11:31:23 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <199606170931.LAA07422@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de
Subject: Info from John Carmack (10)

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

>From johnc@idcanon1.idsoftware.com Sun Jun 16 19:40 MET 1996
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Content-Transfer-Encoding: quoted-printable
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0)
From: John Carmack <johnc@idcanon1.idsoftware.com>
Date: Sun, 16 Jun 96 12:38:35 -0500
To: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Subject: Re: q&a (7)
Content-Type: text/plain; charset="us-ascii"
Content-Length: 4232

You wrote:
> Q: spherical sky is approximated by six (qtest1?) or more polygons,
> e.g. an isocahedron. Still true? How many triangles? All of them
> culled/clipped against view frustrum each time there is a sky
> surface within view?

It isn't decomposed into polygons at all. The planar polygons that
make up the sky are scaned just like a normal surface, but instead
of doing a perspective subdivision, they do a spherical projection
subdivision.

Before we ship a 3d hardware version, we will have to subdivide them
and just spherically project vertexes, but for software we are better
off with what we have.

> Q: dynamic lighting is based on lightsource/vertex distance? A
> gradient in the ambient part of the light level calculation? Part
> of the texture+lightmap->cached surface processing?

It is done at the surface cache level, where every light sample has
the dynamic lights intensitiy - distance added in. Having the
entire scene dynamically lit cuts the game speed by about 30%, so
it is mostly used for effects and accents.

>
> Q: does QuakeC allow for access to place billboards like the status
> bar in the screen plane (overlay at x,y)?

No. Early on, I tried to paramatize everything, so it would be a free
form game engine, but expediency won out.

> Q: all animated textures do not have lightmaps? This is a technical
> necessity, or just too expensive (update cache every frame, instead
> of shifting s,t)? Shouldn't these maxbright surfaces (lava) be area
> lightsources for vis?
>
> I am still thinking texture animation should be entity based -
> conceptually more elegant, but I am perhaps missing the amount of
> overhead.

Continuous frame cycling animation on regular surfaces has lightmaps,
but the water and sky animations do not -- they bypass the surface
cache entirely and draw straight to the screen.

There is a slight amount of texture control on entities. A brush
model entity (buttons, doors, etc) can control if it uses "normal"
or "alternate" frames of animation. We use this so that buttons
animate until the are pressed, then go to a darker dead texture when
activated.

I admit, it could use some more control here.

> Q: is there a way to create walkable BSP objects? Could BSP objects
> have a clipping/hull tree now? I don't think so - my guess is that
> in a hierarchy of BSP's one would need to take into account all the
> PVS's of those leafs in the parent tree it is (partially) in, in
> addition to its own PVS. During the z-fill pass, of course, as long
> as the POV is inside. Doable, but not on the list?

Sorry, I don't understand.

Doors, plats, trains, etc are all BSP objects that move through the
world.

The limitation is that the do not physically interact with the world
or other BSP obejcts. Non-discrete box to BSP clipping is enough of
a bitch, I don't even want to think about continuous bsp to bsp
clipping.

> Alternatively, is it possible to attach several BSP models to one
> QuakeC entity - one point moves, and a dozen objects follows? In
> this case, e.g. a vehicle could conveniently be composed from
> several BSP models.

No, not currently feasable, but we have had instances where we wanted
to do that.

> There is no way to assign multiple objects to the same entity,
> right? Internal state and physics/visual representation are not
> completely separable in Quake?

Entities and drawable objects are one to one (or zero) mapped.

I'm plenty open to still hearing wishes and suggestions now -- I'm
going to be starting on my next generation engine in a month or
so :-)

John Carmack

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