Adrian Pederson wrote:
> 
> >The approach I would take is to not define 1-d constraints, but
> >to use 2-d constraints.
> >
> >What I would use is two images, plus an alpha channel which has ones
> >where the constraint image ( z1[x,y] ) should be used, and zeros
> >where the background, terrain-generator-created terrain ( z0[x,y] )
> >should be used.  Image 1 would be defined over regions where the
> >alpha channel is 1, and would be "don't care" elsewhere.
> 
> I've had very similar thoughts, but wouldn't it really be a 3D
> constraint? X and Y from the pixel row and column, and Z from the
> color value (right-handed system).

By 2-d constraint, I mean it is a scalar field defined in two 
dimensions.  It isn't a full 3-d function : these are defined
over arbitray choices of (x, y, z).

> Also, why create a second file
> that needs to be recombined with the original? Wouldn't it be
> better to just store the pixel channels into a 2 dimensional
> array of structures containing the channel info, then do the
> interp and output directly to a completed image file, so what if
> it takes a little more memory. You only really need two channels
> on the input, i think pov uses red for the height (correct me if
> i'm wrong) and the alpha, of course you could always copy the
> calculated values into all 3 RGB channels for the output, if it
> matters.

Actually, in the "tga16" format, it uses red and green combined to
yield 16 bits of height resolution.  True -- one could then
use the blue channel as an 8-bit alpha channel.   However, I am
trying to cast the system in a form which allows pre-existing
unconstrained terrain generation algorithims (such as the
transform-based one used in Beale's excellent gforge code)
to be used with minimal perturbation.

An interesting thing about the use of the tga16 -- the Targa
spec seems to allow for 16-bit grayscale images.... I wonder
why POV didn't chose to use this, instead using 8-bit RGB.

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message