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 ?



Ken wrote:
> 
> Nieminen Mika wrote:
> >
> > Ken <tyl### [at] pacbellnet> wrote:
> > :   It occured to me that it might be useful to be able to apply
> > : an interal, user specified, color map to the function so that you
> > : can directly affect the slope of the pattern instead of relying
> > : upon the internaly controlled wighted average
> >
> >   What's the main difference between this color map you are talking about
> > and the slope_map in povray?
> 
>    I think a lot of what I know about color control for use with height
>  dependant processes, such as HF's and bump maps, prompted me to want to
>  discuss the possibilities of this added normal modifier.
> 
>    It has become easy for me to create very complicated patterns using the
>  various pigment and texture option available in Pov. Taking this process
>  a step farther I can design a complex pattern, control the color to a very
>  large extent, render the image in Pov, then turn around and use the image
>  created as a bump map in a normal statement.
> 
>    This pattern if successful creates a surface effect that looks like the
>  original I designed. In the process of this I have to generate a pov file
>  for the pattern, add lights, camera positions, and an object to hold the
>  pattern. I now have a .pov file and a .tga file, a very large .tga file if
>  I want any resolution control for the bump mapped pattern.
> 
>    Now I produce another pov file, the scene I am working on, that uses the
>  produced image one time to evaluate if the pattern will work as expected.
>  If it does not work then I have to go back to the image producing file, make
>  changes, render it again, and then switch back to the working pov scene for
>  another evaluation run. This process repeats itself until I am satisfied with
>  the results of the surface normal I am working on. All of this switching and
>  evaluating time spent could be reduced dramatically if I could eliminate the
>  image production step.
> 
>    I cannot do the same procedure with slope maps, at least not at this time
>  due mainly to lack of experience and comprehension of the process. I can
>  visualize sloping color combinations that control the height of a slope for
>  height dependent surfaces but my knowledge of the slope map process is not
>  nearly as well defined. I don't personally believe you can make the two
>  perform exactly the same in any case.
> 
>    Basically my suggestion would eliminate the need to generate an extra
>  image, to be used as a bump map, by using the same information I would have
>  used to produce the bump map, directly inside the normal statement. Cuts out
>  the middle man so to speak. It would also eliminate the need to read in the
>  image, store it in a matrix, then extract the correct height values for each
>  pixel and then perturb the surface accordingly. I would think the process
>  would have speed improvements as well as increased control of the pattern
>  since the resolution of the normal pattern would not be controlled by the
>  size or type of external image used for the bump map process.
> 
>    This same concept might possibly be extended to the HF process making
>  it possible to have internally generated HF's. This would certainly be a
>  powerful addition to the tools available in Pov-Ray and only requires
>  ( he say's casually ) a little extra coding to make it work. It would add
>  a whole new dimension to the way surface features could be controlled and
>  manipulated without the need for external utilities. It would also maintain
>  cross platform compatibility if kept within the core programming code.
> 
>    Maybe I'm dreaming, or maybe I should spend more time learning the slope map
>  feature, but it never hurts to throw these things out to the public sounding
>  board to see how it's going to bounce.
> 
>  --
>  Ken Tyler
> 
>  mailto://tylereng@pacbell.net

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message