"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