3D engines for MUDs

[Niklas Elmqvist]

On Fri, 20 Mar 1998, Miroslav Silovic wrote:

> Michael Hohensee <michael at sparta.mainstream.net> writes:
> 
> > Of course, the POVRAY renderer does take time to work, and wouldn't be
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> This is gross understatement. :) While 2-3 seconds are quite
> acceptable for a game, 1-60 minutes are not.

If we're talking static-screen-like graphics (like in most adventure
games), I agree that 2-3 seconds is quite alright for rendering. However,
if we're talking first-person six-degrees-of-freedom (don't really like
that term...) 3D graphics, something close to 20-40 fps is a *must* (that
is, 1/20 to 1/40 of a second per frame). In addition, if you've seen the
output of some of the new 3D accelerators (3Dfx being prominent among
these), you probably agree that these images are quite adequate and almost
rival simple raytraced images (ok, I'm exaggerating a bit).
Perspective-correct texture mapping, RGBA lights, texture blending and
whatnot is all in a day's (or, actually, a frame's) work for a good 3D
accelerator.

> <ShamelessPlug>
> Feel free to take the code from my renderer for both zbuffering and
> /really/ accelerated raytracing. Gah, now I need to speed up the
> bloody thing for scenes with fewer than 1,000 polygons (as raytracing
> becomes the low overhead operation in the low-complexity case, when
> procedural textures and image pre/postprocessing take over... 320x240
> low-quality previews take 2-3 seconds with 10 objects, 10-20 with
> 1000, using raytracing, and with zbuffering everything gets faster. I
> solved problems with quality loss with zbuffering and as a result, you
> get exactly the same image).

I can get splendid performance out of a 3Dfx accelerator running at
640x480x16bit, and I drool to think about the new Voodoo 2 (especially
the version with 12 megs VRAM) :) 

Okay, to get this back on track a bit, let me say this: I am currently
investigating and implementing a Magic Carpet rendering engine on my own,
and it all looks pretty good. One problem with using a height field is
that it is impossible to create sheer, vertical drops, since the grid
nature of the height field prevents having two heights for the same x-y
position in the map. I've heard that techniques such as TIN (Triangular
Irregular Network), where you approximate a regular grid of triangles with
larger triangles (more efficient with large, flat spaces), not only solves
this somewhat but also significantly reduces the triangle count in a
landscape, but this technique has some inherent problems. First of all,
although TINs reduce the size of the data structure representing the
height field, the "lookup" time during rendering is significantly
increased. In addition, since the TIN consists of large triangles, we get
problems with texture coordinates and the likes if we want to have the
large triangle covered with different textures.

As mentioned earlier, polygon height field rendering is ideally suited for
visualizing large, outdoor areas. This is perfect for those MUDs where
most of the action takes place outdoors. In addition, the height field
nature lends itself easily to fractal terrain generation -- maybe it would
be possible for the server to merely send a seed to the clients and have
them generate the fractal terrain client-side. Has there been any
discussion about anything like this earlier?

If anyone is interested to learn more about polygon heightfield rendering
in game applications, I found a very good whitepaper about this. Download
it from <URL:http://www.ndl.com/ndl/download/TerrainPaper.zip> -- as it
happens, it is in the pesky Word 6.0 format, though. :(

> 	Miro

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
"You can't trample infidels when you're a tortoise. I mean, all you 
 could do is give them a meaningful look."	 
	- Terry Pratchett, Small Gods