"clipka" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
> > The only problem with a function image is the really odd 'upside-down mirror
> > image' behavior of the resulting pattern 'slice' (at least when it's used to
> > make a HF, anyway.) Try making a function image from an image_map to see
> > what I mean.
>
> Ah, so *that's* why I found myself in need of a scale <1,1,-1> when I
> migrated a particular scene from an auto-generated mesh to an
> auto-generated-df3-based height field these days...
>
> I actually have an Idea how this came to be so:
>
> Where's <0,0> in an image?
>
> In a POV context, for some reason I'd be quite quick to claim that it must be
> the bottom left corner.
>
> In an image editing context, however, (0,0) classically designates the top
> left corner.

YES, you've hit the nail squarely on the head. The x/z 'origin' of an image_map
function in POV_Ray is, strangely enough, at <0,1>, not <0,0>. That took me a
bit of experimenting to find. And your explanation of how it possibly came to
be is the final piece of info that solves the puzzle. Yet *at the moment* I'm
not so sure now that the same thing applies to POV pigments or patterns (see
below.)
>
> So height field code, normally dealing with images, might have to swap around
> the image's y co-ordinate for proper operation. And it might do just the same
> for function images - but the function images may fail to do a similar
> re-normalization for the input pattern.

> So the issue may actually be in function images in general, not patterns in
> height fields...

Since posting my reply, I've gone back for yet *another* round of experimenting
with function images and HFs (this time using the HF_Square macro in
shapes.inc), and I've seen some odd behavior.  Part of that is due to a problem
in that macro itself (which I just found a fix for); but my 'fix'--to reorient
how the macro 'sees' an image_map function--does not seem to operate the same
way on functions made from POV-Ray pigments or patterns. I'm getting
conflicting results, in several different ways, so--whether dealing with this
HF macro or a regular HF-- I'm not so sure now that pigments/patterns and
image_maps are even operating the 'same' way when 'functionalized.' Using the
HEXAGON and RADIAL patterns--which have a definite 'direction' or
orientation--they come out looking *exactly* the way they should when used in
the HF_Square macro--no 'mirror image' stuff to contend with, no altered x/z
origin point. Yet an image_map function there DOES need my fix (as a
similar-but-different 'mirror-image' fix was required in a regular HF.) I need
to go back to a 'regular' HF and see if those two specific patterns show up
correctly there as well.

It's all quite weird, and I continue to experiment. I think I *can* say this: A
regular HF and the HF_Square macro seem to operate differently when presented
with functions. (Not so weird in itself; they probably have different code
paradigms.) But nailing down that difference--and the image_map vs.
pigment/pattern discrepancies--is taking some time and thought.
>
> ...(after all, if I'm not mistaken, function images are the only
> way to create a height field from a pattern in the first place).

Yes, that's the only way I know of too.

KW

Post a reply to this message