Re: Image handling: update on my status and plans

[mskala at ansuz dot sooke dot bc dot ca]

On Sun, 19 Dec 2004, Eric McDonald wrote:
> that Ed Felten seems to have fueled your competitiveness; I recognize
> that name from elsewhere; I think he had something to do with the DeCSS
> stuff or maybe a DMCA lawsuit....

He was an expert witness in the Federal Microsoft anti-trust case, and
more recently was attacked by the RIAA after leading the team that
broke the SDMI Challenge files.

> The terrain generator ensures that the all terrain with the 'liquid'
> property set has a uniform elevation with all neighboring liquid terrain.

I think what triggers the bug is elevation=0 rather than liquid terrain as
such, but the way the games are designed means that terrain at elevation 0
normally will be liquid.

> As far as the interfaces calling the kernel every time for an image, I
> am mostly for it, since this keep things more consistent and take most
> of the image-handling burden away from the interfaces. However, if we
> ever evolve Xconq into a client-server model, I might be concerned about
> traffic in the case of a network game. Of course, the image-handling
> part of the "kernel" might be able to be linked into the client apps. I

Well, by "kernel" I just meant the code common to all interfaces - it
could well be part of the client-side library rather than the kernel
kernel that lives on the server.  The point is that we shouldn't have to
make each change to the "decide what image to show" code in more than one
place in the source tree; I think we're on the same page about that.

> My thinking has been:
> (1) Calculate elevation gradients (slopes) from cell edge to cell edge.

That's a bit more complexity than I had in mind - what I was thinking of
was simply code that could automatically generate something similar to the
current designer-specified isometric images.  The way those work is with
one image per terrain type.  That image is of a three-dimensional chunk of
(for instance) mountains, with a hexagonal base but sticking up
vertically, probably outside the hex tile boundaries, to express vertical
height.  When the interface draws it on the screen, it also draws a
pedestal underneath it (isometric view of a hexagonal prism) to represent
the height of the hex, which is the height of the bottom of the relief
shown in the image.

One problem with the current approach is that if the view is rotated, the
designer-specified image can't be rotated because doing so would require
converting the 2D image back to 3D, rotating, and then converting back,
and the relief makes that impossible.  It would be unpleasant, but
theoretically possible, without the relief.  The current scheme of NOT
rotating isometric terrain images when the view rotates actually looks
quite good, but it is visibly a schematic rather than realistic portrayal
of terrain.

What I was imagining for automatic generation would be that the designer
specifies a hexagonal overhead view (they already do), the program renders
that into 3D as a flat hexagon, and then if the designer wants relief,
they specify a height field which is used to add the relief.  There would
be just one image, or one image for each of the six view directions, or
one or six images multiplied by the number of "variant" images, generated
per terrain type - not one per hex.  The objective would be to create
images similar to the ones that designers are currently specifying by
hand.  I had not intended that this feature would be combined with the
satellite-image feature - in theory it could be, I suppose, but that would
be another significant computational load.

> It might also be sufficient to just throw down some splines. As long as

I think that anything which takes into account per-cell elevation
gradients, is best left to the hypothetical future developer of a true-3D
interface.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/