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: <199606031719.TAA05014@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de
Subject: Info from John Carmack (3a)

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

-------------------------------------------------------------------
>From johnc@idnewt.idsoftware.com Tue Mar 26 17:12:36 1996
Message-Id: <9603262211.AA22560@idnewt.idsoftware.com>
Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3)
Received: by NeXT.Mailer (1.118.3)
From: John Carmack <johnc@idnewt.idsoftware.com>
Date: Tue, 26 Mar 96 16:11:40 -0600
To: "Brian K. Martin" <brian@phyast.pitt.edu>
Subject: Re: quake models
References: <199603261430.JAA27076@minerva.phyast.pitt.edu>
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
padded.

> 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
world).

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