3D engines for MUDs

[Niklas Elmqvist]

[Koster, Raph:]
> Voxels look great at a distance, and start to "pixelate" really badly 
> as you get close to them. Also, most data files I have seen for voxel 
> objects (as opposed to voxel terrain) are really large. Lastly, if 
> you're doing anything flat, voxels are a waste, as one poly can handle 
> flat very easily, but you need hundreds of thousands of (individually 
> tracked) voxels in current voxel engines.

As mentioned earlier, using triangle-reduction techniques such as TIN
(Triangle Irregular Network, I believe) you can reduce the polygon-count
of your polygon landscapes like you suggest by approximating large flat
areas with large triangles instead of having fixed-size triangles arranged
in a grid (which really is no better than the voxel approach, only that
you get more 'meat' out of the polygon approach since a polygon generally
is larger than one unit across, like voxels are). Compressing the terrain
in this way may be desirable for a networked application such as a MUD
where you want to send the terrain data to the client.

However, from my own (albeit limited) experience with TINs and the
comments in the heightfield rendering paper I will post shortly, the TIN
approach and similar methods really do decrease the size of the data
structure greatly, but this at the cost of rendering performance (that is,
determining which triangles should be part of the current scene). This is
contrary to current game programming idioms such as BSPs where the aim is
to trade long generation times and (often vastly) increased polygon counts
for faster run-time performance. 

Another problem with the TIN approach is that although the heights of a
specific region may very well be approximated with a large triangle, the
textures of this region may not. That is, according to your texture map
(which tells you what kind of texture you want in different parts of the
map), this large polygon should in reality be texture-mapped with quite a
lot of different textures. This is hard if not next to impossible with
today's 3D accelerators, and not something I would like to write and get
any measure of performance out of it ("Gee, let's put together this large
texture with these small ones, there, looks good. Here, texture mapper,
here's your new texture.").

So, IMHO, we're currently stuck with having to use fixed-size triangle
grids/meshes. That said, the technique of continous LOD (see the paper) is
of course a very useful approach here to increase rendering performance.

> Not to say voxels are bad--they are phenomenal looking in any sort of 
> overhead view application, or fixed distance application. They also do 
> great at terrain as long as you can't get too close to the terrain. 
> They're currently getting trendy in computer game development 
> circles, though the concept has been around since the 70s.

I seem to recall reading something about 3D sprites in Game Developer
where they apparently were using some kind of voxel approach to model
extremely good-looking three-dimensional characters. Not polygon-based
models, mind you, but extremely organic-looking and smooth characters
where even things such as belt buckles and facial features are 'real',
i.e. not 'artificial' using texture-maps. 

Take a look at <URL:http://www.animatek.com/caviar.htm> to see these
amazing-looking characters. I believe there is a viewer available for
Windows 95/NT. Animatek also has an amazing 3D landscape
generator/builder called World Builder. Too bad they're not doing this
under the GPL *cough*.

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