POV-Ray : Newsgroups : povray.general : Using a function in a height_field declaration : Re: Using a function in a height_field declaration Server Time
20 Jun 2024 23:52:01 EDT (-0400)
  Re: Using a function in a height_field declaration  
From: Bald Eagle
Date: 24 Feb 2023 19:05:00
Message: <web.63f94fd243a1dd881f9dae3025979125@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
Now that I have been playing around again with this function-to-HF mess, I see
> that the mirror-reversal flaw is only in z in the created HF, not both x and z
> like I had thought for years. This why my 'brute-force' fix works successfully:
>
>      height_field{
>      function 500,500{somb(x,y,z)}
>      ...
>      scale <1,1,-1>
>      translate <0,0,1>
>      }
>
> ...as does William P's trick:
>             somb(x, (1-y), z)

So, as I understand it, your way fixes the problem after the function gets
integrated into the heightfield, and Bill's way reverses the data before it gets
integrated into the heightfield.

I would carefully compare these 2 methods using a non-symmetric function.

Now, considering that there may be other differences when using pigments and
image_maps, I'd again use a non-symmetric pattern or image.  I'd use something
that can easily show a mirroring or rotation around any axis.

Maybe find a pigment that is a nice mathematical function that we can use as
in-built pigment, as a function, using the same equation as in source, and as an
image map that we get by rendering a box with the pigment.   Then we can do more
apple-to-apple comparing.

After we establish a rock-solid starting point, we can further poke around and
see what's what.

> So I thought that this 3rd method worked for ALL patterns-- but it does not.
> Other pigment/pattern functions show...'varying' results:
> ONION does not reverse.
> GRADIENT X+Y does reverse, or so it seems.
> GRANITE does reverse-- in some way-- but the visual result is not the same as
> the two 'reliable' methods. The same goes for HEXAGON.
> SPIRAL1/SPIRAL2 appears to reverse in *x*, not z (!)
>
> I would assume that there is some logic to this mish-mash of results, but I
> don't yet grasp it.

Yeah - that all does seem weird - I'd make sure you're not chasing ghosts, as
this seems easy enough to do here.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.