Info from John Carmack (9)

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Sat, 8 Jun 1996 22:32:50 +0200 (MET DST)

Date: Sat, 8 Jun 1996 22:32:50 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <199606082032.WAA18664@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de
Subject: Info from John Carmack (9)

Here's another one. Btw., the flip/mirror question was indeed
a stupid one - recognized this too late. And it must be

s_ofs t_ofs rot_angle s_scale t_scale

obviously, as most Plane lines read "...0 0 0 1 1" now.

b.

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

>From johnc@idnewt.idsoftware.com Fri Jun 7 20:29 MET 1996
Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3)
Content-Transfer-Encoding: quoted-printable
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0)
From: John Carmack <johnc@idnewt.idsoftware.com>
Date: Fri, 7 Jun 96 13:26:18 -0500
To: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Subject: Re: q&a (6)
Content-Type: text/plain; charset="us-ascii"
Content-Length: 3559

You wrote:
>
> Q: gravity is fixed along Z. Would there be unreasonable overhead
> assigning a gravity/current/force vector to a volume (like the
> water/lava attribute is maintained)?

We have "push triggers" that assign a velocity when you are inside
them. We use them for flinging players through gerbil tubes. They
aren't exactly what you want (you have no control when in them),
but it is just qc code and could be changed easily. There are
efficiency issues with using them all over the place, but they
aren't too bad.

> Q: besides lava-style texture animation, is there a simple s/t
> scroll animation? Different speeds?

Not for normal textures, because the light map samples are tied to
a block structure. I could slide the turbulent textures, because
they don't have lightmaps, but I haven't put any interface in for it.
It will probably show up in Quake 2.

> Q: wouldn`t it be better to include the palette (768 bytes) along
> with the mipmap lumps in the BSP? Solely for using DOOM playpal, or
> other full palette replacements. MDL skins etc. will be a problem,
> but entities are external references anyway.

The palette is included along with the misc graphics, like the console
and status bar. If you want to use a different palette, you are
going to have to create all new graphics for everything else. I really
doubt it is worth it.

>
> Q: am I mistaken that, with "s/t_ofs s/t_scale rot", it is not
> possible anymore to flip/mirror a texture, because of using NAT's?

A negative scale is a flip.

>
> This is confusing :-(. Ceterum censeo: shouldn't NAT's be assigned
> within QuakeEd/any editor, and the result be saved as (s,t).
> Semi-auto texture alignment is an editor feature. The brushes
> aren`t human readable anyway. Ah well, I will shut up on this one.
>

The .map file is the editor file format, so it has representations
convenient for the editor. The .bsp file has representations
convenient for rendering.

I tried just putting in s/t vectors for the planes, but it makes
many editor operations cumbersome.

I know, I know. It doesn't feel right to me either.

> Q: the MAP format does not allow for persistent hierarchy/grouping
> (which is useless for qbsp, but useful for editing). Care to
> comment on:
>
> --------------<example>-------------------
>{
> "classname" "worldspawn"
> "message" "The House"
> {
> "_label" "The Bathroom"
> {
> ( .., .., .. ) WALLTILE ....
> ( .., .., .. ) WALLTILE ....
> ...
> }
> {
> // more brushes
> }
> // end bathroom
> }
> {
> "_label" "The Living Room"
> {
> ( .., .., .. ) CARPET ....
> // more brushes
> }
> }
> // more rooms
>}
> --------------</example>-----------------

This is changing with my NT editor. The entity grouping groups brushes
very nicely allready. I am just going to add a little change to qbsp
so that an entity with a classname of "submodel" or something will just
be merged into the world entity for bsp generation.

> The MAP files will have a life expectancy exceeding Quake's by far.
> As far as 3D map editing is concerend, it is time to think
> "progressive refinement" - or "kaizen". Btw., the more I think my
> way through brush based editing, the more I like it - this has been
> a damn good idea.

Yes, I still think I made the right decision for solid based editing,
and I think it will be adopted widely.

I was charmed to see Epic using my "brush" terminology in describing
their unreal editor :-).

John Carmack

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