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

Post a reply to this message