POV-Ray : Newsgroups : povray.general : Using a function in a height_field declaration : Re: Using a function in a height_field declaration Server Time
15 Jul 2024 13:55:33 EDT (-0400)
  Re: Using a function in a height_field declaration  
From: William F Pokorny
Date: 15 Feb 2023 05:34:19
Message: <63ecb52b$1@news.povray.org>
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 

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 

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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.