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