  | 
  | 
 
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
"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'
   
   
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
> 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 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
"Kenneth" <kdw### [at] gmail com> 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 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
> 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 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
"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'
   
   
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
"Kenneth" <kdw### [at] gmail com> wrote:
> "Kenneth" <kdw### [at] gmail com> 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 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
"Bald Eagle" <cre### [at] netscape net> 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 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
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'
   
   
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
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'
   
   
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
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'
   
   
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 
 | 
  |