Info from John Carmack (3a)

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Mon, 3 Jun 1996 19:19:25 +0200 (MET DST)

Date: Mon, 3 Jun 1996 19:19:25 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <>
Subject: Info from John Carmack (3a)

This is that earlier posting on z-buffer usage, as provided
by Brian Martin.

>From Tue Mar 26 17:12:36 1996
Message-Id: <>
Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3)
Received: by NeXT.Mailer (1.118.3)
From: John Carmack <>
Date: Tue, 26 Mar 96 16:11:40 -0600
To: "Brian K. Martin" <>
Subject: Re: quake models
References: <>
Status: RO

You wrote:
> Yes, it would be a real pain in the ass to download a different mdl
> file to the server for each player. That is out of the question.
> But why don't you allow to add one more peice of info to be sent on
> initialization besides the colors, that is a string for a name of
> the mdl to use. like 'player2.mdl'. This would allow so many more
> cool possibilities. You guys don't have to worry about supplying
> the models, just make it possible to use them. My idea was to have
> quake load up the default player.mdl, then if someone wanted to use
> a different one, and the client had it on their disk, they could
> use it. Of course the color values could still be used and maybe
> even you could just overwrite existing mdl info so you don't need
> to read in all the frames, maybe just the texture.

I've been considering the options for a while, and an "optional model"
field is probably pretty good. I wouldn't count on it for 1.0, but
that is the type of thing that might make it in on a revision.

> -- Also, would you be kind enough to give the relevance of the byte
> in the frame data after the max bound values in the mdl files.

It is unused. Three byte structures are non-portable, so it's just

> Also the precalculated indecies go up to 161, but there are some 255's
> in the models that are set to dark with no gouraud shading. I found
> that values like 162 could be used to make things like sparkles and
> stuff. Is this planned of just on accident (i.e. should I pursue
> this if I wanted to hack an mdl file? but I would never do that.)

There shouldn't be any 255s. What model did you see them in? It may
be a bug.

> one other little thing. I was arguing to several people about quake
> using a z-buffer to render models. I can find no proof, no one
> believes me. Every one says it's too slow. (and it is, but it works
> good). Any words?

The alias models are z buffered. The world is rendered with Z
fill, which costs about 15% over just the drawing. Yes, the z
buffering hurts on really large models, but for the majority of
them, it is a speed advantage. If the average polygon size is
only a dozen pixels or so, doing a compare and store to the z
buffer for each pixel is less work than sorting against the other
polygons in the model (let alone properly sorting against the

As for speed... We will ship about 20% faster than qtest1. The
486 performance will still be hopeless, but that is the price for
going to a floating point intensive design. I still stand by it
as the right decision for the lifespan of the product.

John Carmack

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