AMD Athlon-C 1.33GHz, 768MB of SDRAM, 133MHz bus, Win2K w/SP2, POV-Ray 3.5
Beta.1

I'm trying to make a heightfield, with waves emanating at the center.

height_field
{
 function 300,300
 {
  pigment
  {waves color_map {[0 rgb 0][1 rgb 1]} scale 0.05 translate <1,0,2*clock>/2
noise_generator 2}
  }
 }
 translate -<1,0,1>/2 scale <200,20,200>
 pigment {rgb 1}
}

I tried as you can see to place the ripples which appear at the back of the
heightfield in the center. I did two animations, one translating -2*clock
and another translating 2*clock. The result of both was identical. The
emanation point went further back. Am I missing something or is there a bug
here?

Post a reply to this message

"Tony[B]" wrote:

> Am I missing something or is there a bug here?

It doesn't make much sense to me either but I don't know enough
about functions to really say for sure.

-- 
Ken Tyler - POV-Ray Technical Assistance Group

Post a reply to this message

Wasn't it Tony[B] who wrote:
>AMD Athlon-C 1.33GHz, 768MB of SDRAM, 133MHz bus, Win2K w/SP2, POV-Ray 3.5
>Beta.1
>
>I'm trying to make a heightfield, with waves emanating at the center.
>
>height_field
>{
> function 300,300
> {
>  pigment
>  {waves color_map {[0 rgb 0][1 rgb 1]} scale 0.05 translate <1,0,2*clock>/2
>noise_generator 2}
>  }
> }
> translate -<1,0,1>/2 scale <200,20,200>
> pigment {rgb 1}
>}
>
>I tried as you can see to place the ripples which appear at the back of the
>heightfield in the center. I did two animations, one translating -2*clock
>and another translating 2*clock. The result of both was identical. The
>emanation point went further back. Am I missing something or is there a bug
>here?


The thing that's strange is that a function's two dimensions are coded
as x and y, but the object is oriented in the x,z plane.

To move the waves forward in the z direction of the scene you have to
perform a translation in the y direction of the pigment.

I'm not sure what you're trying to do with the clock, but 
translate <1,1,0>/2 produces a static image with the ripples centred,
whereas you seem to be expecting translate <1,0,1>/2 to do that.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams wrote:

> The thing that's strange is that a function's two dimensions are coded
> as x and y, but the object is oriented in the x,z plane.

I guess this is just one of the prices for using functions absolutely everywhere
in the program. The x/y orientation works great for a pigment, but for a height
field,the need fr an additional transform is not intuitive. I had the same
problem using trace with a function-generated h/f. I had assumed it was a bug.
Thanks for the info.

Post a reply to this message

In article <3BA1F5F9.53C34A9C@aol.com> , Dave Dunn <poi### [at] aolcom>  
wrote:

>> The thing that's strange is that a function's two dimensions are coded as x
>> and y, but the object is oriented in the x,z plane.
>
> I guess this is just one of the prices for using functions absolutely
> everywhere in the program. The x/y orientation works great for a pigment

It also works great for functions that use u/v instead of x/y.  This allows
reusing of parametric functions.


    Thorsten

Post a reply to this message

In article <3ba0efd0@news.povray.org> , "Tony[B]" <ben### [at] catholicorg> 
wrote:

> height_field
> {
>  function 300,300
>  {
>   pigment

Unrelated to your problem, I am wondering why you are using a pigment here.
A pattern would be much easier to control...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
:>  function 300,300
:>  {
:>   pigment

: Unrelated to your problem, I am wondering why you are using a pigment here.
: A pattern would be much easier to control...

  Also unrelated, but this made me remember one thing:

  Can image functions be declared? I remember trying it once but not
succeeding (IIRC it issued an error at the first number).

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3ba2116a@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Can image functions be declared? I remember trying it once but not
> succeeding (IIRC it issued an error at the first number).

You should be able to write a function and call it just the same way as you
call functions in isosurfaces:  function { foo(x,y,z) }

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: You should be able to write a function and call it just the same way as you
: call functions in isosurfaces:  function { foo(x,y,z) }

  What I mean is that if I write something like this:

#declare MyImageFunction = function 256,256 { pattern { ... } }

I get an error at the first '256' (if I remember correctly; I can't confirm
this right now as I'm not at home).

  PS: It might be that it works and that I just typoed somewhere (eg. forgot
the comma or something), and if this is so, just ignore this... :)
  I'll get home soon and test it again.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3ba22523@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>
>   What I mean is that if I write something like this:
>
> #declare MyImageFunction = function 256,256 { pattern { ... } }
>
> I get an error at the first '256' (if I remember correctly; I can't confirm
> this right now as I'm not at home).
>
>   PS: It might be that it works and that I just typoed somewhere (eg. forgot
> the comma or something), and if this is so, just ignore this... :)
>   I'll get home soon and test it again.

Well, you write

 #declare MyImageFunction = function { pattern { ... } }
 height_field
 {
  ...
  function 256, 256 { MyImageFunction(x,y,z) }
 }

which is exactly what the syntax description in the docs says.

I don't see why one would declare an image and be surprised that is doesn't
work (as that is what your example tries to do) - it isn't possible at all
with any image map type and never has been...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message