A few thoughts on a possible addition to the normal function in Pov.


 The current implementation of the normal function is controlled
by the pattern type choosen for the normal, is applied by an
internaly controled slope, which is dependant on the pattern type
specified. 
  The options available to overide this behavior is to change the
wave type, which is useful but still limited in scope, and to go
outside the application with the use of an image file applied as
a bump map modifier. This is a versitle approach but requires
the generation of an external file, in the form of an image, and
limits the amount of direct control, inside Pov, you have on
changes to its construction.
  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, or having to resort
to using a bump map applied image as the currently available options
allow for.
  I see several benifits that would come from this and some very
interesting surface topographies would be accoplished in short
time if the user had more internal control of the slope disribution
in a normal by adding a color controlled modifier to the function.

 Is this possible and is it worth additional discussion and or
investigation ?

 I would like to hear what others think of this and what other possible
advantages there may be that I have not covered arisinging from the
addition of such a feature.

 Regards,

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Wed, 07 Apr 1999 10:17:08 -0700, 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, or having to resort
>to using a bump map applied image as the currently available options
>allow for.

You mean something like slope_map?  :)

Post a reply to this message

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?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

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

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

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

On Thu, 08 Apr 1999 00:17:58 -0700, Ken <tyl### [at] pacbellnet> wrote:
>  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.

Hey, finally something I can speak authoritatively on, since I wrote
the patch.  The problem is that the image-reading stuff that I piggybacked
on to do the 'pattern' image type doesn't support filter.  That's not
too surprising, since there aren't any image formats that support 
filtered transparency, either - The ones that support transparency at
all support it in the form of an alpha channel, which is like POV's
transparency.

> Secondly the continued need to reference the function through the use
>of language associated with images maps. It should do away with that
>step. 

Perhaps, perhaps not.  The next superpatch will have some warps in it that
remove any usefulness that might have been gained by using a pigment as an
image for just about anything except height_fields and this thing that you're 
talking about, and the thing that you're talking about could be done with
slope_maps, except that you have to have a way to determine the slope at
each point in the slope map.  The feature was originally added for height
fields, and they have to be sampled anyway, so it makes sense to just use 
the image-handling code that's already there for them.  I should go add 
some antialiasing to the image-generation code sometime, though.  As a 
matter of fact, the next superpatch also adds a function-type to isosurfaces
that takes a pigment as argument, so this whole thing may no longer be
necessary (though height_fields are probably faster than isosurfaces.)

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

Actually, I did it this way for maximum flexibility.  I was originally
going to go rewrite a big chunk of the height_field code, but I realized
that these things had uses outside height_fields, so I made it a lot more
general.  Those who have looked at my motion blur patch or who have 
compared the superpatch to the patches that went into it know that I don't 
shy away from rewriting large chunks of code.  :)

I'll bet someone here (maybe even me...) could work out a macro that takes 
an ordered array of 2-d vectors in ([0..1],[0..1]) and calculates the 
appropriate slopes for you.  It wouldn't be as versatile as the general 
slope_map, but it might be easier for an artist to work with.

Post a reply to this message

On 8 Apr 1999 09:30:15 -0500, par### [at] my-dejanewscom (Ron Parker)
wrote:


>I'll bet someone here (maybe even me...) could work out a macro that takes 
>an ordered array of 2-d vectors in ([0..1],[0..1]) and calculates the 
>appropriate slopes for you.  It wouldn't be as versatile as the general 
>slope_map, but it might be easier for an artist to work with.

You can pull slopes out of an image (height field) by running it
through the diff function in hflab.  I posted a tutorial quite a while
ago about using this and some related tricks to generate slope
dependent textures in standard pov.  I think it was in
povray.binaries.tutorials.  Using it twice, of course, lets you
identify spots where the slope is changing (rim of a valley, etc.).
If anyone is interested and can't find the tutorial, let me know and
I'll dig up my file copy.

Jerry Anning
clem "at" dhol "dot" com

Post a reply to this message

Jerry Anning wrote:

> You can pull slopes out of an image (height field) by running it
> through the diff function in hflab.  I posted a tutorial quite a while
> ago about using this and some related tricks to generate slope
> dependent textures in standard pov.  I think it was in
> povray.binaries.tutorials.  Using it twice, of course, lets you
> identify spots where the slope is changing (rim of a valley, etc.).
> If anyone is interested and can't find the tutorial, let me know and
> I'll dig up my file copy.
> 
> Jerry Anning
> clem "at" dhol "dot" com

  Here is a direct link to what I believe is the tutorial that Jerry was
referring to

http://www.povray.org/cgi-bin/dnewsweb?cmd=article&group=povray.text.tutorials&item=1146

 For those of you that have your news program set to keep older file
headers you can go straight to the post in povray.text.tutorials.
It was posted on 7-18-98.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message