POV-Ray : Newsgroups : povray.general : Using a function in a height_field declaration Server Time
17 Apr 2024 17:48:55 EDT (-0400)
  Using a function in a height_field declaration (Message 21 to 30 of 58)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Kenneth
Subject: Re: Using a function in a height_field declaration
Date: 14 Feb 2023 14:35:00
Message: <web.63ebe14443a1dd889b4924336e066e29@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> If you mean that the 'center' of the sine wave circle is
> not 'at the origin' but at z=1 instead, that could be due to a long-standing
> problem with how functions are kind of mirror-reversed when used in a
> height_field...

BTW: That old problem had strange effects: no only of the z effect of the
function being reversed to '-z', but also x to -x. It was -- is? --a
'double-reversal' mirror effect...with the 'origin' of the function moved to
z=1, not at <0,0,0>.

I thought for sure that this had been corrected, but I have not played around
lately with such height_fields to see.


Post a reply to this message

From: yesbird
Subject: Re: Using a function in a height_field declaration
Date: 14 Feb 2023 14:50:00
Message: <web.63ebe5b843a1dd8868fd655b10800fb2@news.povray.org>
> I thought for sure that this had been corrected, but I have not played around
> lately with such height_fields to see.

May be it's time for bug report ?
--
YB


Post a reply to this message

From: Kenneth
Subject: Re: Using a function in a height_field declaration
Date: 14 Feb 2023 15:45:00
Message: <web.63ebf15543a1dd889b4924336e066e29@news.povray.org>
"yesbird" <nomail@nomail> wrote:
> > I thought for sure that this had been corrected, but I have not played around
> > lately with such height_fields to see.
>
> May be it's time for bug report ?
> --

I think that was done long ago; I know that *I* reported it in the distant past,
but probably not to the bug-reports page.

So I did another test... and confirmed that the problem is still there :-(  I'm
almost(?) sure that one of the v3.7 - v3.8 'development' versions in the past
had fixed this behavior...if only temporarily, it seems.

One example here uses the 'onion' pattern; the other uses an
image_map-to-function:

#declare somb =
function{pigment{image_map{jpeg "test image.jpg" once interpolate 2}}}

then...

function 1000, 1000 { somb(x,y,z).gray}

Of course, this weird effect can be fixed after-the-fact, with appropriate
negative scaling etc...
    scale <1,1,-1>
    translate <0,0,1>


Post a reply to this message


Attachments:
Download 'function_mirror_image_in_height_field.jpg' (114 KB)

Preview of image 'function_mirror_image_in_height_field.jpg'
function_mirror_image_in_height_field.jpg


 

From: Bald Eagle
Subject: Re: Using a function in a height_field declaration
Date: 14 Feb 2023 18:30:00
Message: <web.63ec196943a1dd881f9dae3025979125@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > If you mean that the 'center' of the sine wave circle is
> > not 'at the origin' but at z=1 instead, that could be due to a long-standing
> > problem with how functions are kind of mirror-reversed when used in a
> > height_field...
>
> BTW: That old problem had strange effects: no only of the z effect of the
> function being reversed to '-z', but also x to -x. It was -- is? --a
> 'double-reversal' mirror effect...with the 'origin' of the function moved to
> z=1, not at <0,0,0>.
>
> I thought for sure that this had been corrected, but I have not played around
> lately with such height_fields to see.

You might have to play around with this a bit more - but the issue that you may
be seeing is that height_fields are by default "made" in the region <0, 0, 0> to
<1, height, 1>.

Just like an image_map is a unit square.

So usually one just translates it -0.5*(x+z) and it then centered at the origin.

But am definitely seeing a difference in my isosurface vs height_field, so
thanks for this little question - I will see if that's part of the issue with my
scene as well.

- BW


Post a reply to this message

From: Bald Eagle
Subject: Re: Using a function in a height_field declaration
Date: 14 Feb 2023 20:05:00
Message: <web.63ec2eac43a1dd881f9dae3025979125@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> But am definitely seeing a difference in my isosurface vs height_field, so
> thanks for this little question - I will see if that's part of the issue with my
> scene as well.

Yeah, ok - that's weird.
I just played with it and something screwy is indeed happening there.

Maybe Bill Pokorny has a good idea of where to look to see what the problem is.

Strange that no one else mentioned this little quirk...?


Does this make the scaling/translation a ... quirkaround?


Post a reply to this message

From: yesbird
Subject: Re: Using a function in a height_field declaration
Date: 14 Feb 2023 20:40:00
Message: <web.63ec373a43a1dd8868fd655b10800fb2@news.povray.org>
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'
scale_y_shift.png


 

From: yesbird
Subject: Re: Using a function in a height_field declaration
Date: 15 Feb 2023 00:55:00
Message: <web.63ec727a43a1dd8868fd655b10800fb2@news.povray.org>
Quick look at the sources under debugger makes me think that in
Trans:inverse[0][0] we have something strange at the moment of
HField::Transform(), but I am not sure if this value have any influence
(See attachment below)
--
YB


Post a reply to this message


Attachments:
Download 'hfield_bug.png' (177 KB)

Preview of image 'hfield_bug.png'
hfield_bug.png


 

From: yesbird
Subject: Re: Using a function in a height_field declaration
Date: 15 Feb 2023 01:15:00
Message: <web.63ec783f43a1dd8868fd655b10800fb2@news.povray.org>
O, sorry, Trans::invers[1][1]:65535 - This is always questionably :)
--
YB


Post a reply to this message


Attachments:
Download 'hfield_bug_2.png' (128 KB)

Preview of image 'hfield_bug_2.png'
hfield_bug_2.png


 

From: William F Pokorny
Subject: Re: Using a function in a height_field declaration
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 
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

From: yesbird
Subject: Re: Using a function in a height_field declaration
Date: 15 Feb 2023 06:00:00
Message: <web.63ecba2143a1dd8868fd655b10800fb2@news.povray.org>
> 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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

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