Re: Image handling: update on my status and plans

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Tue, 4 Jan 2005 mskala@ansuz.sooke.bc.ca wrote:

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

Ah, that's right. It was SDMI, not DeCSS.

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

Right. I was saying that 'liquid' acts an elevation leveler. 
Usually, this means leveling the terrain to a height of 0. 
However, if the problem is caused by elevation == 0, then why 
don't I see it on all cells that are part of the same ocean? This 
is what I was getting at.

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

Yes, absolutely.

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

Right.

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

I see.

Eric