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