POV-Ray : Newsgroups : povray.general : Using a function in a height_field declaration Server Time
28 Dec 2024 03:25:10 EST (-0500)
  Using a function in a height_field declaration (Message 19 to 28 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:15:00
Message: <web.63ebdad843a1dd889b4924336e066e29@news.povray.org>
"yesbird" <nomail@nomail> wrote:
> Thanks, Kenneth.
>
> Of course I've tried to play with arguments scaling , but problem in shifting
> from origin (please look at attachment). Still can't figure out how it work.
>
Your camera was aimed toward -z, which confused me a bit, although I am still
not sure as to what problem you are seeing.

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. (OR, maybe due to the
construction of your sin function itself?) I have not tested a function
height_field in awhile, so I am not sure if the odd mirroring problem was fixed
at some time in the past. (I thought it was.)

Anyway, here's my own version of your scene, with a different camera position.
Maybe it will help to clarify your question and my answer ;-)

--------
#version 3.8;
global_settings { assumed_gamma 1 }

camera
{ // location <1,1,1> * 2
  location <1.5,3,-2>
  look_at <.5,.3,0>
  angle 50
}

light_source { <10,10,10>, rgb <1,1,1> }

#declare somb = function (x,y) { sin (sqrt (x*x + y*y)) / sqrt (x*x + y*y) };

height_field
{
  function 500, 500 { somb(x*20, y*20) }
  smooth
  scale <1, 0.3, 1>
  pigment { green 0.8 }
  }

//----------

plane{y,0 pigment{rgb .2}}

//----- origin markers ---
  union{
cylinder{-5*x,5*x,.07 pigment{rgb .5*<0,1,1>}}
cylinder{-3*y,3*y,.07 translate .00001*z pigment{rgb <.4,1,.4>}}
cylinder{-5*z,5*z,.07 translate .00001*x pigment{rgb <.6,.6,1>}}

text {
    ttf "timrom.ttf" "x"
    .2, 0
    translate -.2*z
    scale 1
    rotate 90*x
    translate <5.5,0,0>
    pigment{rgb 1}
}

text {
    ttf "timrom.ttf" "y"
    .2, 0
    scale 1
    translate <0,3.5,0>
    pigment{rgb 1}
}

text {
    ttf "timrom.ttf" "z"
    .2, 0
    translate -.2*z
    scale 1
    rotate 90*x
    translate <0,0,5.5>
    pigment{rgb 1}
}
 scale .3
 no_shadow
 }


Post a reply to this message


Attachments:
Download 'temp test from newsgroup.jpg' (22 KB)

Preview of image 'temp test from newsgroup.jpg'
temp test from newsgroup.jpg


 

From: yesbird
Subject: Re: Using a function in a height_field declaration
Date: 14 Feb 2023 14:30:00
Message: <web.63ebe0c443a1dd8868fd655b10800fb2@news.povray.org>
> If you mean that the 'center' of the sine wave circle is not 'at the origin'

Exactly, this was a reason of confusion, now everything in on the "place",
almost ... :).
Thanks for beautiful illustration.
--
YB


Post a reply to this message

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


 

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

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