Doom-Ed

Congratulations to Epic, Unreal looks very good.

A 94 degree day at the dragstrip today. Several 3drealms and Norwood
Autocraft folk also showed up to run. We got to weigh most of the cars on
the track scales, which gives us a few more data points.

11.6 @ 125 Bob Norwood’s ferrari P4 race car (2200 lbs)
11.9 @ 139 John Carmack’s twin turbo testarossa (3815 lbs)
11.9 @ 117 Paul Steed’s YZF600R bike
12.1 @ 122 John Carmack’s F50 (3205 lbs)
12.3 @ 117 Brian’s Viper GTS (3560 lbs)
13.7 @ 103 John Cash’s supercharged M3
14.8 @ ??? Someone’s lexus GS400
15.0 @ ??? Someone’s volkswagon GTI
15.1 @ ??? Christian’s boxter (with Tim driving)

Weight is the key for good ETs. The TR has considerably better power
to weight ratio than the P4, but it can’t effectively use most of the power
until it gets into third gear. The viper is actually making more power than
the F50, (Brian got a big kick out of that after his dyno run) but 350 lbs
more than compensated for it.

I wanted to hit 140 in the TR, but the clutch started slipping on the last
run and I called it a day.

I was actually surprised the F50 ran 122 mph, which is the same the F40 did
on a 25 degree cooler day. I was running with the top off, so it might
even be capable of going a bit faster with it on.

The F50 and the viper were both very consistant performers, but the TR and
the supercharged M3 were all over the place with their runs.

Brian nocked over a tenth off of his times even in spite of the heat, due to
launch practice and some inlet modifications. He also power shifted on
his best run.

It was pretty funny watching the little volkswagon consistantly beat up on
a tire shredding trans-am.

George Broussard had his newly hopped up 911 turbo, but it broke the trans
on its very first run. We were expecting him to be in the 11’s.

We probably won’t run again until either I get the F50 souped up, or my
GTO gets finished.

A 94 degree day at the dragstrip today. Several 3drealms and Norwood
Autocraft folk also showed up to run. We got to weigh most of the cars on
the track scales, which gives us a few more data points.

11.6 @ 125 Bob Norwood’s ferrari P4 race car (2200 lbs)
11.9 @ 139 John Carmack’s twin turbo testarossa (3815 lbs)
11.9 @ 117 Paul Steed’s YZF600R bike
12.1 @ 122 John Carmack’s F50 (3205 lbs)
12.3 @ 117 Brian’s Viper GTS (3560 lbs)
13.7 @ 103 John Cash’s supercharged M3
14.0 @ 96 Scott Miller’s lexus GS400
15.0 @ ??? Someone’s volkswagon GTI
15.1 @ ??? Christian’s boxter (with Tim driving)

Weight is the key for good ETs. The TR has considerably better power
to weight ratio than the P4, but it can’t effectively use most of the power
until it gets into third gear. The viper is actually making more power than
the F50, (Brian got a big kick out of that after his dyno run) but 350 lbs
more than compensated for it.

I wanted to hit 140 in the TR, but the clutch started slipping on the last
run and I called it a day.

I was actually surprised the F50 ran 122 mph, which is the same the F40 did
on a 25 degree cooler day. I was running with the top off, so it might
even be capable of going a bit faster with it on.

The F50 and the viper were both very consistant performers, but the TR and
the supercharged M3 were all over the place with their runs.

Brian nocked over a tenth off of his times even in spite of the heat, due to
launch practice and some inlet modifications. He also power shifted on
his best run.

It was pretty funny watching the little volkswagon consistantly beat up on
a tire shredding trans-am.

George Broussard had his newly hopped up 911 turbo, but it broke the trans
on its very first run. We were expecting him to be in the 11’s.

We probably won’t run again until either I get the F50 souped up, or my
GTO gets finished.

Here is an example of some bad programming in quake:

There are three places where text input is handled in the game: the console,
the chat line, and the menu fields. They all used completely different code
to manage the input line and display the output. Some allowed pasting from
the system clipboard, some allowed scrolling, some accepted unix control
character commands, etc. A big mess.

Quake 3 will finally have full support for international keyboards and
character sets. This turned out to be a bit more trouble than expected
because of the way Quake treated keys and characters, and it led to a
rewrite of a lot of the keyboard handling, including the full cleanup and
improvement of text fields.

A similar cleanup of the text printing hapened when Cash implemented general
colored text: we had at least a half dozen different little loops to print
strings with slightly different attributes, but now we have a generalized one
that handles embedded color commands or force-to-color printing.

Amidst all the high end graphics work, sometimes it is nice to just fix up
something elementary.

Here are some notes on a few of the technologies that I researched in
preparing for the Quake3/trinity engine. I got a couple months of pretty
much wide open research done at the start, but it turned out that none of
the early research actually had any bearing on the directions I finally
decided on. Ah well, I learned a lot, and it will probably pay off at
some later time.

I spent a little while doing some basic research with lummigraphs, which
are sort of a digital hologram. The space requirements are IMMENSE, on
the order of several gigs uncompressed for even a single full sized room.
I was considering the possibility of using very small lumigraph fragments
(I called them “lumigraphlets”) as imposters for large clusters of areas,
similar to aproximating an area with a texture map, but it would effectively
be a view dependent texture.

The results were interesting, but transitioning seamlessly would be difficult,
the memory was still large, and it has all the same caching issues that any
impostor scheme has.

Another aproach I worked on was basically extending the sky box code style of
rendering from quake 2 into a complete rendering system. Take a large number
of environment map snapshots, and render a view by interpolating between up
to four maps (if in a tetrahedral arangement) based on the view position.

A simple image based interpolating doesn’t convey a sense of motion, because
it basically just ghosts between seperate points unless the maps are VERY
close together reletive to the nearest point visible in the images.

If the images that make up the environment map cube also contain depth values
at some (generally lower) resolution, instead of rendering the environment
map as six big flat squares at infinity, you can render it as a lot of little
triangles at the proper world coordinates for the individual texture points.
A single environment map like this can be walked around in and gives a sense
of motion. If you have multiple maps from nearby locations, they can be
easily blended together. Some effort should be made to nudge the mesh
samples so that as many points are common between the maps as possible, but
even a regular grid works ok.

You get texture smearing when occluded detail should be revealed, and if you
move too far from the original camera point the textures blur out a lot, but
it is still a very good effect, is completely complexity insensitive, and is
aliasing free except when the view position causes a silhouette crease in
the depth data.

Even with low res environment maps like in Quake2, each snapshot would consume
700k, so taking several hundred environment images throughout a level would
generate too much data. Obviously there is a great deal of redundancy — you
will have several environment maps that contain the same wall image, for
instance. I had an interesting idea for compressing it all. If you ignore
specular lighting and atmospheric effects, any surface that is visible in
multiple environment maps can be represented by a single copy of it and
perspective transformation of that image. Single image, transformations,
sounds like… fractal compression. Normal fractal compression only deals
with affine maps, but the extension to projective maps seems logical.

I think that a certain type of game could be done with a technology like that,
but in the end, I didn’t think it was the right direction for a first person
shooter.

There is a tie in between lummigraphs, multiple environment maps, specularity,
convolution, and dynamic indirect lighting. Its nagging at me, but it hasn’t
come completely clear.

Other topics for when I get the time to write more:

Micro environment map based model lighting. Convolutions of environment maps
by phong exponent, exponent of one with normal vector is diffuse lighting.

Full surface texture representation. Interior antaliasing with edge
matched texels.

Octree represented surface voxels. Drawing and tracing.

Bump mapping, and why most of the aproaches being suggested for hardware
are bogus.

Parametric patches vs implicit functions vs subdivision surfaces.

Why all analytical boundary representations basically suck.

Finite element radiosity vs photon tracing.

etc.

The rcon backdoor was added to help the development of QuakeWorld (It is
not present in Quake 1). At the time, attacking Quake servers with
spoofed packets was not the popular sport it seems to have become with
Quake 2, so I didn’t think much about the potential for exploitation.

The many forced releases of Quake 2 due to hacker attacks has certainly
taught me to be a lot more wary.

It was a convenient feature for us, but it turned out to be irresponsible.
Sorry.

There will be new releases of QuakeWorld and Quake 2 soon.