"yesbird" <nomail@nomail> wrote:
> > I want to thank YOU for introducing a new pigment construction to me:
> >             pigment{red 1.0 green 0.6}
>
> Always welcome, I don't remember, where I saw it, but this notation is more
> 'human-readable', than others, IMHO. Anyway, we are here to exchange knowledge
> and ideas. Now I'm working on animation of this 'orange'.
>
> > It seems that even an old-timer like me needs to re-read POV-ray's *basic*
> > documentation, now and then ;-)
>
> Yes, we should learn onward :)
> --
> YB

I always use x, y, and z for red, green, and blue.   Especially when coloring
axes.

Post a reply to this message

> Looks delicious! I like the wild colors too.

Thanks to your ideas, I've rendered my first POV animation:

https://www.youtube.com/watch?v=i7kItZ6S6cM

Will be thankful for any critical notes and advises.
--
YB

Post a reply to this message

Attachments:
Download 'fragile.zip' (15 KB)

On 13/02/2023 20:41, Bald Eagle wrote:
> 
> According to:
> https://wiki.povray.org/content/Reference:Height_Field
> 
> (At the very bottom)
> 
> "The height field object also allows for substituting a user defined function
> instead of specifying an image. That function can either be in it's literal
> form, or it can be a call to a function that you have predeclared. The user
> supplied parameters FieldResolution_X and FieldResolution_Y are integer values
> that affect the resolution of the color/index values, not size of the unscaled
> height field."
> 
> There is, of course, no code snippet supplied, so I'm just casting about trying
> to get this to work.
> 
> Has anyone used this method before?

Yes, but this dates back to ... 2003

Gilles Tran used this in his macro examples of "Cloud Generator"
(<http://www.oyonale.com/modeles.php?lang=en&page=36>).


#declare SeaBase = height_field {
 function Resolution,Resolution {
  (sin(y*pi*5)+1)/3+f_ridged_mf(x*14, y*30,z, 1.2,3,6,1.18,5,1)*0.55/3
// (sin(y*pi*5)*0.5+sin(x*pi*4)*0.5+1)*0.4+f_ridged_mf(x*7, y*15,z,
1.2,3,6,1.18,5,1)*0.54*0.2
  }
  #if (SeaSmoothOK = 1) smooth #end
  }

#declare TerrainBase=height_field{
 function Resolution,Resolution {
  f_ridged_mf( x*2, y*2, z,0.6, 3, 6, -1, 3,3 )*0.2
  }
 #if (TerrainSmoothOK=1)
  smooth
 #end
 translate -x*0.5
 }





old man's words ;)

-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

> old man's words ;)

Thanks for sharing the link - there are a lot of useful things there.
--
YB

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Has anyone used this method before?

at the end of
https://ingoogni.nl/povray/sounds-of-povray/the-sound-of-height-fields/

ingo

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > If you mean that the 'center' of the sine wave circle is
> > not 'at the origin' but at z=1 instead, that could be due to a long-standing
> > problem with how functions are kind of mirror-reversed when used in a
> > height_field...
>
> BTW: That old problem had strange effects: no only of the z effect of the
> function being reversed to '-z', but also x to -x. It was -- is? --a
> 'double-reversal' mirror effect...with the 'origin' of the function moved to
> z=1, not at <0,0,0>.
>

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)

These two methods seem to be the only *reliable* ways to fix it. I mention this
again because, for years, I had used an IMAGE_MAP-to-function as my 'standard
candle' tester-- and there is yet another way to fix *its* reversal:

#declare somb =
function{
pigment{image_map{--my image--}
scale <1,-1,1>}
}

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.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> 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.

Hmm. This *could* be due to the <0,0,0> default 'origin' of each pattern being
grossly moved to z=1 in the resulting height_field. In which case, at least
'onion' might BE successfully reversed...but still 'looks' the same there
because the pattern's center has not been moved back to z=0.

I haven't yet compared my other test results to see if this idea holds up re: my
3rd method, for all of the patterns...

Post a reply to this message

"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

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> 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.
>

Yep, I concur.

> > GRADIENT X+Y does reverse, or so it seems.

I actually used gradient x + .3*y, for the very reason you mention. I also
pre-shifted the hexagon pattern a little.

Yet, it's still difficult to correctly assess the visual results, especially
with patterns like granite and bumps which are kind of 'noisy/randomized' to
begin with.

But I now have a bunch of render tests to compare against each other-- which I
am *triple*-checking this time, ha ;-)  And I have a few more experiments to
run, re: the z 'origin' of the patterns shifting to z=1; I'm hoping that those
results will prove fruitful and perhaps indicate what might be the ONE(?) simple
underlying problem...

Post a reply to this message

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

> But I now have a bunch of render tests to compare against each other-- which I
> am *triple*-checking this time, ha ;-)  And I have a few more experiments to
> run, re: the z 'origin' of the patterns shifting to z=1; I'm hoping that those
> results will prove fruitful and perhaps indicate what might be the ONE(?) simple
> underlying problem...

Well, it's a little 1x1 hf - render a bunch of them all at once, and label them
all with text {} objects, and post it so you can put all the permutations side
by side and have more eyes and minds trying to figure it out.

Post a reply to this message