Spider wrote:
> 
> hi Ken.
> I think I have just the thinig you are after, well... I... ok, The superpatch
> :-)
> <snipping from the docs>
> PATTERN:
> pattern Width,Height { [hf_gray_16] PIGMENT }
> This keyword defines a new bitmap image type.  The pixels of the image can be
> derived from any standard pigment.  This image may be used wherever a tga image
> may be used.  Some uses include creating heightfields from procedural textures
> or wrapping a 2d texture such as hexagons around a cylinder.
> A pattern statement be used wherever an image specifier like tga or png may be
> used.  Width and Height specify the resolution of the resulting bitmap image.
> The pigment body may contain transformations.  If present, they apply only to
> the pigment and not to the object as a whole.  This image type currently ignores
> any filter values that may be present in the pigment, but it keeps transparency
> information.  If present, the hf_gray_16 specifier causes POV-Ray to create an
> image that adheres to the TGA 16-bit encoding for heightfield information.
> Example:
> #declare QuickLandscape=height_field {
>   pattern 200,200 {
>     hf_gray_16
>     bozo
>     color_map {
>       [0 rgb 0]
>       [1 rgb 1]
>     }
>   }
> }
> 
> Well, I think it is what you requested. not so ?

It is getting close but a couple of things bother me about the
discription given.

  The first is the lack of support for filtered pigments. I don't
necessarily like using transmit values to create layered pigment patterns.
The two functions behave differently and can have a negative impact
on height dependent color values and intensities.

 Secondly the continued need to reference the function through the use
of language associated with images maps. It should do away with that
step. As this is a patched option I can understand why the author
would steer away from rewriting a lot of code when a few pointer
changes will come close to the desired effect. When it comes time to
make it official I would hope the reference would be dropped completely
opting instead for function command names related to the process.

  I will reread through this new bit of info and give it due consideration.
I just may have to break down and actualy try the Super Patch one of these
days. I have been avoiding primarily because there are so many features
in the official build still unmastered that adding the confusion of
alternative options and syntax strucures has kept me away. The need
for more is better is on the other hand quickly reaching the limits
of on my resolve on this stance.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message