On 2/14/23 14:00, yesbird wrote:
>> You shift it over from the origin in the same way, just with
>> addition/subtraction.
> 
> I know, but why I should shift it ? We are looking straight at the origin, peak
> should be there, or I am missing something ?
> --
> YB
> 

Disclaimer: I'm answering never having spent any meaningful time in the 
height_field code with respect to how it, actually, works.

---

With respect to the centering remember the height_field functionality 
was written well ahead of the ability to code functions in POV-Ray.

The original code worked with images. Image indexing starts in the upper 
left and moves downward by row. Further images in POV-Ray were 
originally set up to exist in the x+,y+ unit square. Shapes more often 
were 'wrapped around y' sitting in/on the x,z plane - as is true for the 
height_field.

When the function capability was added, it was set up to mimic the image 
x,y input values(a). Those values move from the upper left of the 'image 
coded as a function' to the lower right by rows. Specifically: y=0, (x=0 
to x=1) to y=1, (x=0 to x=1).

A function mathematically centered at the origin which we want at the HF 
x,z origin needs to be coded as:

#declare somb = function (x,y) {
sin (sqrt (x*x + y*y)) / sqrt (x*x + y*y)
};

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

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

Aside: There is a divide by zero exception at x=0, y=0 as 'somb' is 
coded. POV-Ray official release users won't see the exception, but it 
might lead to artefacts in the mesh at that corner.

What's the question on the y values? I read through the posts before 
coffee.

Bill P.

(a) - Or it was simply easier to continue to use the 'image' x,y value 
mechanism on coding.

Post a reply to this message

> What's the question on the y values? I read through the posts before
> coffee.
Hi,

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

Example script is three-posts-up, debug screenshot one-post-up in this thread.
--YB

Post a reply to this message

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