|
|
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
|
|