When an image_map is used in a height_field function, the resulting HF shows a
"mirror image"...lower corner of the image_map at x=0, z=1 of the HF, rather
than at x=0, z=0. Adding rotate 180*x or scale -y corrects this (no
translations needed):

height_field{
   function 300,300{
       pigment{image_map{sys "my_image.bmp" map_type 0 interpolate 2}
               rotate 180*x // or scale -y
              }
                   }
            }

Not a problem, once you know that it's necessary.  But I was wondering what the
underlying reason is for the mirror imaging.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
>
> But I was wondering what the underlying reason is for the mirror imaging.
>
> Ken W.

Let me rephrase that into a question  :-) ....

Does anyone know what the underlying reason is for the mirror imaging?

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> Does anyone know what the underlying reason is for the mirror imaging?

  I have asked this exact same question in the past (with regard to
creating heightfields from functions), and the answer is that nobody
knows. I don't know who the original author of the HF code is, and nobody
knows what he was thinking when he did that, or whether it was just a
design error or bug. Certainly there doesn't seem to be any rational
reason for it to behave like that.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > Does anyone know what the underlying reason is for the mirror imaging?
>
>   I have asked this exact same question in the past (with regard to
> creating heightfields from functions), and the answer is that nobody
> knows. I don't know who the original author of the HF code is, and nobody
> knows what he was thinking when he did that, or whether it was just a
> design error or bug. Certainly there doesn't seem to be any rational
> reason for it to behave like that.
>
> --
>                                                           - Warp

Hey, an actual, real-life mystery. Fun!

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
>
> ...Adding rotate 180*x or scale -y corrects this (no
> translations needed)...
>
I've since noticed some behavior of this image_map-to-HF-function that makes the
situation more complex than I originally thought.  While the mirror-image
correcting trick does work, there is still an odd *scaling* problem regarding
the image_map.  If I scale the image_map smaller--in order to "tile" it across
the face of the HF--the scaling doesn't take place from the origin as it
normally would--x=0, z=0--but rather, from x=0,z=1! Strangely, that is the
defacto "origin" of the HF function. This causes havoc when trying to line up
an  equally-scaled image_map TEXTURE to the HF--they scale from different
origin points!

I did figure out a solution, though, that solves both the mirror image problem
AND this odd scaling. It involves putting all of the "corrections" OUTSIDE of
the HF function. (I couldn't find any other way to do it.)  Like so:

height_field{
   function 300,300{
        pigment{
            image_map{sys "my_image.bmp" map_type 0 interpolate 2}
            // the HF image shows an incorrect "mirror image"
            scale .65 // or whatever, to tile the image across the HF
               }
                   }
   scale <1,-1,1> // inverts height of HF to point at -y
   rotate 180*x // flips the HF over--corrects the mirror-imaging, and
                //re-orients the HF height to be in the correct +y direction
   translate 1*z // moves the HF back to its proper place at the REAL origin

   texture{..... scale .65} // an image_map here -- flipped 90*x as usual--
                            // will correctly line up with the HF, and
                            // everything scales together properly.

   scale ....  // additional scaling of entire HF
   translate...
            }

I would assume that using any regular POV pigment pattern in the HF
function--rather than an image_map there--would also exhibit these same
problems, and need the same corrections. Gradient y does; I tried it.

BTW, another odd thing here is that you can't use the ONCE keyword in the HF
function's image_map; no detail shows up at all, just a blank, flat HF. I don't
remember that happening with a normal HF.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

>
> BTW, another odd thing here is that you can't use the ONCE keyword in the HF
> function's image_map; no detail shows up at all, just a blank, flat HF.

I'm wrong about that; it CAN be used and does work. (I must have been looking at
a different test image; sorry for the misinformation.) The only minor glitch is
that the smooth area of the resulting HF not covered by the image_map is
automatically at full height--not at y=0--as if that part of the HF function
were *pure white.*

> I don't remember that happening with a normal HF.
>
Hmm. That's because ONCE(and INTERPOLATE and MAP_TYPE) can't be used in a
regular height_field. Forgot about that. Wheras they CAN be used in a HF
function.

KW

Post a reply to this message

Hmm... That explains some problems I have had in the past to get those 
things right. Thought it was my own misunderstanding.... :-)
Good testing work, Kenneth!

Thomas

"Kenneth" <kdw### [at] earthlinknet> schreef in bericht 
news:web.48013b134a8bd78778dcad930@news.povray.org...
> "Kenneth" <kdw### [at] earthlinknet> wrote:
>>
>> ...Adding rotate 180*x or scale -y corrects this (no
>> translations needed)...
>>
> I've since noticed some behavior of this image_map-to-HF-function that 
> makes the
> situation more complex than I originally thought.  While the mirror-image
> correcting trick does work, there is still an odd *scaling* problem 
> regarding
> the image_map.  If I scale the image_map smaller--in order to "tile" it 
> across
> the face of the HF--the scaling doesn't take place from the origin as it
> normally would--x=0, z=0--but rather, from x=0,z=1! Strangely, that is the
> defacto "origin" of the HF function. This causes havoc when trying to line 
> up
> an  equally-scaled image_map TEXTURE to the HF--they scale from different
> origin points!
>
> I did figure out a solution, though, that solves both the mirror image 
> problem
> AND this odd scaling. It involves putting all of the "corrections" OUTSIDE 
> of
> the HF function. (I couldn't find any other way to do it.)  Like so:
>
> height_field{
>   function 300,300{
>        pigment{
>            image_map{sys "my_image.bmp" map_type 0 interpolate 2}
>            // the HF image shows an incorrect "mirror image"
>            scale .65 // or whatever, to tile the image across the HF
>               }
>                   }
>   scale <1,-1,1> // inverts height of HF to point at -y
>   rotate 180*x // flips the HF over--corrects the mirror-imaging, and
>                //re-orients the HF height to be in the correct +y 
> direction
>   translate 1*z // moves the HF back to its proper place at the REAL 
> origin
>
>   texture{..... scale .65} // an image_map here -- flipped 90*x as usual--
>                            // will correctly line up with the HF, and
>                            // everything scales together properly.
>
>   scale ....  // additional scaling of entire HF
>   translate...
>            }
>
> I would assume that using any regular POV pigment pattern in the HF
> function--rather than an image_map there--would also exhibit these same
> problems, and need the same corrections. Gradient y does; I tried it.
>
> BTW, another odd thing here is that you can't use the ONCE keyword in the 
> HF
> function's image_map; no detail shows up at all, just a blank, flat HF. I 
> don't
> remember that happening with a normal HF.
>
> Ken W.
>
>
>
>
>

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
>
> >
> > BTW, another odd thing here is that you can't use the ONCE keyword in the HF
> > function's image_map; no detail shows up at all, just a blank, flat HF.
>
> I'm wrong about that; it CAN be used and does work. (I must have been looking at
> a different test image; sorry for the misinformation.) The only minor glitch is
> that the smooth area of the resulting HF not covered by the image_map is
> automatically at full height--not at y=0--as if that part of the HF function
> were *pure white.*
>

I forgot to say that the ONCE keyword would only be of use if the image_map is
scaled smaller than the 1 X 1 HF area (otherwise it's redundant, since a
FULL-scale image_map automatically covers the HF just once.)

It may not be obvious as to *why* anyone would want to use a small-scaled
image_map in a HF function, using ONCE; but an example would be combining--in a
rather complicated way :-( -- the image_map with a procedural function made from
a pigment or pigment pattern..the pigment's details covering the *entire* HF.
The visual result would be the image_map part appearing only in a particular
area.

KW

Post a reply to this message