On 2/15/23 05:34, William F Pokorny wrote:
> Yes. Functions as used in height_fields never see called x,y values 
> outside the [0-1] range.

Forgot to plug a new povr function called f_boom() I believe should be 
in any v4.0 release.

#include "functions.inc"
#declare FnChkVals = function (x) {
     select(((x<0.0) | (x>1.0)),
         0,
         0,
         f_boom(x,2,3,4,5,6)
     )
}

height_field {
   function 500, 500 { FnChkVals(y) }
...

A little ugly in that it throws after printing six values, but it offers 
a quick way for 'users' to test values in functions. Above we're testing 
that y as seen in the HF called function is never outside the [0,1] 
range.

Bill P.

Post a reply to this message

Not work for me:

"C:\Projects\povplay\__tests\height_field\scale_y_shift.pov" line 36: Possible
Parse Error: Suspicious identifier found in function! If you want to call a
function make sure the function you call has been declared. If you call an
internal function, make sure you have
included 'functions.inc'.

Script:
--------------------------------------------------------------------------
#include "colors.inc"
#include "functions.inc"

#version 3.8;
global_settings { assumed_gamma 1 }

//
// Axis textures
//
#declare fin_axis = finish { phong 1 reflection {0.10 metallic 0.4 }}
#declare tex_axis_common = texture {
           pigment { rgb <0.70, 0.70, 0.70> }
           finish  { fin_axis }}
#declare tex_axis_x = texture { pigment { rgb x} finish { fin_axis }}
#declare tex_axis_y = texture { pigment { rgb y} finish { fin_axis }}
#declare tex_axis_z = texture { pigment { rgb z} finish { fin_axis }}

//
// Axis
//
#macro axis_base( len, rad, tex_odd, tex_even )
union{
    cylinder { <0, -len, 0>,<0, len, 0>, rad
               texture{ checker texture{ tex_odd } texture{ tex_even }
               translate <0.1, 0, 0.1> }}

    cone{<0, len, 0>, rad * 2, <0, len + rad * 7, 0>, 0 texture{tex_even} }}
#end

#macro axis_xyz( len_x, len_y, len_z, rad, tex_common, tex_x, tex_y, tex_z)
union{
    #if (len_x != 0) object { axis_base(len_x, rad, tex_common, tex_x) rotate<
0, 0,-90>} #end
    #if (len_y != 0) object { axis_base(len_y, rad, tex_common, tex_y) rotate<
0, 0,  0>} #end
    #if (len_z != 0) object { axis_base(len_z, rad, tex_common, tex_z) rotate<
90, 0,  0>} #end }
#end

#macro axis(len_x, len_y, len_z, rad)
    axis_xyz( len_x, len_y, len_z, rad, tex_axis_common, tex_axis_x, tex_axis_y,
tex_axis_z)
#end

//
// Perspective camera
//
#macro camp (_x, _y, _z, _lx, _ly, _lz, _ang)
camera
  { perspective
    location < _x,  _y,  _z>
    look_at  <_lx, _ly, _lz>
    angle _ang
  }
#end

//
// Orthographic camera
//
#macro camo (_x, _y, _z, _lx, _ly, _lz, _ang)
camera
  { orthographic
    location <_x,  _y,   _z>
    look_at  <_lx, _ly, _lz>
    angle _ang
  }
#end

//
// Lights
//
#declare br = 0.8;
light_source {<0,  10, 0>, rgb <1,1,1> * br }
light_source {<0, -10, 0>, rgb <1,1,1> * br }

light_source {< 10, 0, 0>, rgb <1,1,1> * br }
light_source {<-10, 0, 0>, rgb <1,1,1> * br }

light_source {<0, 0,  10>, rgb <1,1,1> * br }
light_source {<0, 0, -10>, rgb <1,1,1> * br }


// Axis
axis (3,3,3,0.02)

// Cameras
camo (10,0,0,0,0,0,45)

#declare FnChkVals = function (x) {
     select(((x<0.0) | (x>1.0)),
         0,
         0,
         f_boom(x,2,3,4,5,6)
     )
}

#declare HF_Poly0_2_2 = height_field {
     function 800, 800 { FnPoly0_2(x,y,z) }
     scale   <2, 2, 2>
     pigment {Red}}

object { HF_Poly0_2_2 }
------------------------------------------------------------------------
YB

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> height_field { //+++++++++++++++++***  <------- Need this
>    function 500, 500 { somb(x*20, (1-y)*20) }

I was playing with something similar last night wi the y-subtraction.

> Yes. Functions as used in height_fields never see called x,y values
> outside the [0-1] range.

All I can say at this point is that it takes a lot of wrangling to get some
things to behave properly, and at the moment, I can't say that I've got it all
straightened out.

The height_field definitely needs to be tailored to use either user-defined
functions or pigment functions, and there are definitely more complications than
just that.

I was able to get most of the issues sorted out in one scene, but they remain in
another.  for whatever reason, pigment {onion} really throws thing off compared
to other things.

At the moment, I'm comparing isosurface and height_field, so maybe somehow those
get to be like comparing apples to oranges, due to the values and how they need
to be handled (y-function for an isosurface}

I did not see the y-shift that yesbird is seeing.

(Sergey:  scaling scales EVERYTHING.   If the hf is 1 unit away from the origin,
then it will scale that offset vector as well.  So, you can take a sphere
cenetered at the origin and scale it, and it will give the expected results, but
if you translate it first, then it will scale the translation as well, and it's
center will wind up farther away from the origin.)


It might be worth having a few people independently test out their own methods
of constructing a function and function {pigment} hf, and compare results, then
we can maybe make a macro that has a solution to reliably  making a hf in the xz
plane.   I spent WAY longer sorting this out than I should have, and I'm still
not satisfied that I fully understand all of the intricacies.

Post a reply to this message

My simple test scene.

Note the vector swizzling.

#version 3.8;
global_settings {assumed_gamma 1}
#declare E = 0.00001;



camera {
 //orthographic
 //location <image_width/2, image_height/2,  -image_width*4>

 location <0, 10, -5>/2

 right x*image_width/image_height
 up y
 //sky y
 look_at <0, 0, 0>
 rotate y*0
}

light_source {<1, 30, -1> rgb 1}
plane {y, 0 pigment {checker}}


#declare BWCM = color_map {
 [0 rgb 0]
 [1 rgb 1]
}

#declare RGCM = color_map {
 [0.0 rgb x]
 [0.54 rgb x+y]
 [0.54 rgb 0] // black elevation line
 [0.55 rgb 0]
 [0.55 rgb x+y]
 [1.0 rgb y]
}


#declare eps = 0.00001;
#declare r = function {sqrt (x*x + y*y) + eps}
#declare Z = function {(18 * sin (r(x, y, z))/ r(x, y, z))+5}

#declare F = function {pigment {onion color_map {BWCM}}}

cylinder {0, y*2, 0.01 pigment {rgb y}}




height_field {
 //function 100 100 {Z (x*8, y*8, z)/25}
 function 100 100 {F(x, z, y).red}
 scale < 1, 1, -1>
 translate <0, 0, 1>
 pigment {gradient y color_map {RGCM} }
}

union {
cylinder {0, y*2, 0.01 pigment {rgb y}}

isosurface {
 //function {y-(Z (x*8, z*8, 0) - 0)/25}
 //function {y-F(x, y, z).red}
 function {y-F(x, 0, z).red}
 threshold 0
 accuracy 0.001
 max_gradient 200
 //open
 all_intersections
 contained_by {box {0, 1}}
 texture {pigment {gradient y color_map {RGCM}} finish {diffuse 1}}
}
 translate -x*2


}

Post a reply to this message

"yesbird" <nomail@nomail> wrote:
> Not work for me:

>          f_boom(x,2,3,4,5,6)

That's a function that only work in his personal "povr" fork.  Not an inbuilt
POV-Ray function.

Post a reply to this message

Hi,
> Sergey:  scaling scales EVERYTHING.
....
> if you translate it first, then it will scale the translation as well, and it's

But I did not translated my objects (see example script).
--
YB

Post a reply to this message

"yesbird" <nomail@nomail> wrote:
> Hi,
> > Sergey:  scaling scales EVERYTHING.
> ....
> > if you translate it first, then it will scale the translation as well, and it's
>
> But I did not translated my objects (see example script).


Nope, you're not, which is why it's so puzzling that there's any y-offset at
all.

However, regardless of whether the translation is inherent, as is the present
case, or intentional, by using a translate directive, the offset still exists
and so it gets affected by a scale directive.

Think about it from a function {} perspective and what it really means when you
scale something - especially if you were going to do it with a matrix
multiplication rather than an SDL directive.

Post a reply to this message

> Think about it from a function {} perspective and what it really means when you
> scale something - especially if you were going to do it with a matrix
> multiplication rather than an SDL directive.

I understand, thank you.
--
YB

Post a reply to this message

Bill,
thank you for clarifying this "space oddity". Now, taking into account your
explanations, I will use this function more carefully :) --
--
YB

Post a reply to this message

[yesbird wrote:]
> This small playground localizes this issue (shifting by Y):
[scene code snip]
>
> I discovered that the height_field function moves the rendered object along
> the Y axis by 1 unit without scaling and this effect increases proportional
> to the scaling amount.

This 'y-movement' that you are seeing-- actually not real movement at all-- is
the typical 'look' and behavior of a height_field when a particular kind of
function is used for it...or even a particular kind of image_map function.

A height_field is just a floating 'shell' surface, which ideally expects to see
function values (or image_map pigment values) that go from 0.0 to 1.0. IF those
values do so, you would see parts of the height_field extend all the way down to
y=0, no matter how large you scaled it afterward. But if the values given to the
function actually start at + 0.4 for example (like a gray rgb 0.4 in an
image_map as it's 'darkest' value), then the function will create the lowest
surface of the HF shell at y=0.4, not y=0  (assuming a final HF y-scale of 1.0).
The shell then appears to float above the surface-- and naturally appears to
move higher as you scale everything up, like Bald Eagle mentioned earlier.

In your example code and image, you're using

#declare FnPoly0_2 = function { pattern {
         granite poly_wave 0.2 scale 0.7
         }
}

then scaling your height_field afterward by <2,2,2>.

I suspect that the poly_wave is adding a positive 'bias' value to the function,
causing *extra* floating of the HF because the function no longer has any zero
values(?). Remove that wave type to see how some parts of the HF then almost
touch y=0, more or less.

A better explanatory example would be to try this function instead-- just an
infinitely-thin surface at y=0.4. It's flat HF 'shell' naturally floats above
the ground (unless you scale y to almost zero!)

#declare FnPoly0_2 = function(y) {x + .4}

then...

#declare HF_Poly0_2_2 = height_field {
     function 10, 10 { FnPoly0_2(y) }
     scale   <2, 2, 2>
     pigment {Red}}

Change the y-scale to see the *apparent* movement.

You will need a non-orthographic camera to see the thin shell; use this one
instead:

camera {
  perspective
  location  <1.5, 2, -3>
  look_at   <.75, .4,  .4>
  right     x*image_width/image_height
   angle 67
}

Post a reply to this message