|
 |
This small playground localizes this issue (shifting by Y):
----------------------------------------------------------------
#include "colors.inc"
#version 3.8;
global_settings { assumed_gamma 1 }
//
// Axis textures
//
#declare tex_axis_common = texture {
pigment{ rgb <0.70, 0.70, 0.70>}
finish { phong 1 reflection {0.10 metallic 0.4} }}
#declare tex_axis_x = texture {
pigment{ rgb <1.00, 0.00, 0.00>}
finish { phong 1 reflection {0.10 metallic 0.4} }}
#declare tex_axis_y = texture {
pigment{ rgb <0.00, 1.00, 0.00>}
finish { phong 1 reflection {0.10 metallic 0.4} }}
#declare tex_axis_z = texture {
pigment{ rgb <0.00, 0.00, 1.00>}
finish { phong 1 reflection {0.10 metallic 0.4} }}
//
// Axis
//
#macro axis( 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(len_x, rad, tex_common, tex_x) rotate< 0,
0,-90>} #end
#if (len_y != 0) object { axis(len_y, rad, tex_common, tex_y) rotate< 0, 0,
0>} #end
#if (len_z != 0) object { axis(len_z, rad, tex_common, tex_z) rotate< 90, 0,
0>} #end }
#end
axis_xyz( 1.5, 1.5, 1.5, 0.02,tex_axis_common,tex_axis_x,tex_axis_y,tex_axis_z)
//
// Camera from +X +Y +Z
//
/*
camera
{ orthographic
location <5,5,5>
look_at <0,0,0>
angle 40
}
*/
//
// Camera from +Y
//
/*
camera
{ orthographic
location <0,10,0> / 1.5
look_at <0,0,0>
angle 40
}
*/
//
// Camera from +X
//
camera
{ orthographic
location <10,0,0> / 1.5
look_at <0,0,0>
angle 40
}
//
// Light
//
light_source { <0, 10, 0>, rgb <1,1,1> }
light_source { <10,0, 0>, rgb <1,1,1> }
light_source { <0, 0, 10>, rgb <1,1,1> }
//
// Poly0_2 common function
//
#declare FnPoly0_2 = function { pattern {
granite poly_wave 0.2 scale 0.7 }}
//
// No scale - shift by Y
//
#declare HF_Poly0_2_1 = height_field {
function 800, 800 { FnPoly0_2(x,y,z) }
pigment {Green}}
//
// With scale - shift by Y even more
//
#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_1 }
object { HF_Poly0_2_2 }
----------------------------------------------------------------
Post a reply to this message
Attachments:
Download 'scale_y_shift.png' (46 KB)
Preview of image 'scale_y_shift.png'
|
|
|
|
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
|
|
com> wrote:
