Stephen <mca### [at] aolcom> wrote:
> On 27/02/2013 4:14 PM, Warp wrote:
> > Kenneth <kdw### [at] gmailcom> wrote:
> >> Here are the two code lines given there:
> >
> >> #declare Vec = foo(1,2,3)
> >
> >> and
> >
> >> #declare Val = foo(2,3,4).gray
> >
> >> What do the values (1,2,3) and (2,3,4) represent?
> >
> > They mean whatever the function wants them to mean. The function
> > constructs the vector from those values.
> >
>
> Do you mean that you could write:
>
> #declare Vec = foo(A,B,C)
> #declare Val = foo(X,Y,Z).gray
> or
> #declare Val = foo(1,2,3).gray
> even
>
> And that would the same as writing:
>
> #declare Vec = foo(1,2,3)
> #declare Val = foo(2,3,4).gray
> ?
>
> --
> Regards
>      Stephen

Only so much as A,B,C  or X,Y,Z have defined values.
The A,B,C represent where in 3-space you want to evaluate the underlying pigment
function foo().

for the very simple example in the docs:
#declare foo = function {
  pigment {
    color red 1
    }
  }

as the pigment is red anywhere, any value will return rgb value <1,0,0>.

Where it becomes useful for one example is in building scenes.  Lets say you
want to set down a 100x100 array of spheres.  You could set up a pattern
function (bump for example), then when you go to place each sphere, evaluate the
value of foo() at the center coordinates of each sphere and size it based on
that value.

Or perhaps you have a number of different flowers in a field (lets say five).
Each time you check a spot where you want to place the flower, you can evaluate
foo() at those coordinates and: 1) pick which flower you want to use out of the
5 based on the .red value 2) scale the sizing based on the .green value 3)
roatet the flower based on the .blue value.
This can be better than just random selection, as it allows you to have some
flow and transition continuity (i.e. you'll have distinct patches of each flower
type)

-tgq

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Stephen <mca### [at] aolcom> wrote:
> > On 27/02/2013 4:14 PM, Warp wrote:
> > > Kenneth <kdw### [at] gmailcom> wrote:
> > >> Here are the two code lines given there:
> > >
> > >> #declare Vec = foo(1,2,3)
> > >
> > >> and
> > >
> > >> #declare Val = foo(2,3,4).gray
> > >
> > >> What do the values (1,2,3) and (2,3,4) represent?
> > >
> > > They mean whatever the function wants them to mean. The function
> > > constructs the vector from those values.
> > >
> >
> > Do you mean that you could write:
> >
> > #declare Vec = foo(A,B,C)
> > #declare Val = foo(X,Y,Z).gray
> > or
> > #declare Val = foo(1,2,3).gray
> > even
> >
> > And that would the same as writing:
> >
> > #declare Vec = foo(1,2,3)
> > #declare Val = foo(2,3,4).gray
> > ?
> >
> > --
> > Regards
> >      Stephen
>
> Only so much as A,B,C  or X,Y,Z have defined values.
> The A,B,C represent where in 3-space you want to evaluate the underlying pigment
> function foo().
>
> for the very simple example in the docs:
> #declare foo = function {
>   pigment {
>     color red 1
>     }
>   }
>
> as the pigment is red anywhere, any value will return rgb value <1,0,0>.
>
> Where it becomes useful for one example is in building scenes.  Lets say you
> want to set down a 100x100 array of spheres.  You could set up a pattern
> function (bump for example), then when you go to place each sphere, evaluate the
> value of foo() at the center coordinates of each sphere and size it based on
> that value.
>
> Or perhaps you have a number of different flowers in a field (lets say five).
> Each time you check a spot where you want to place the flower, you can evaluate
> foo() at those coordinates and: 1) pick which flower you want to use out of the
> 5 based on the .red value 2) scale the sizing based on the .green value 3)
> roatet the flower based on the .blue value.
> This can be better than just random selection, as it allows you to have some
> flow and transition continuity (i.e. you'll have distinct patches of each flower
> type)
>
> -tgq

A brief scene using the grey evaluation.  Try changing the pattern type or
scaling in foo():

//START
global_settings {
  charset utf8
  ambient_light 1
  adc_bailout 0.001
  max_trace_level 25
}

camera{
  up y
  right x*image_width/image_height
  angle 60
  location <50,50,-50>
  look_at  0
}


light_source {0 rgb 1.773
  translate <50,30,20>
}


#declare foo=
function{
  pigment{
    bumps
    scale 10
  }
}


#local i=-50;#while (i<51)
  #local j=-50;#while (j<51)

  #declare height=foo(i,0,j).gray;
  cylinder{<i,0,j> <i,10+height*5,j> 0.25 pigment {rgb <1,0,0>}}

  #local j=j+1; #end
#local i=i+1; #end
//END

-tgq

Post a reply to this message

James Holsenback <nom### [at] nonecom> wrote:

> On 02/27/2013 07:39 AM, Thomas de Groot wrote:
> > On 27-2-2013 10:34, Kenneth wrote:
> >> 3.2.1.6.5  "Declaring User-Defined Color Functions".
> >
> > A bit difficult to find ;-)
> >
> > in the 3.7 RC7 offline Docs: 3.3.1.8.5
> > in the online wiki Docs: 2.3.1.8.5
>
> That's where I find them as well, so I don't know where Ken got his
> annotation ... perhaps 3.6...

Sorry, I should have mentioned that. It's in the help files that come with
v3.62 (and in a few earlier versions IIRC.)

Post a reply to this message

James Holsenback <nom### [at] nonecom> wrote:

>
> As far as the content at Reference 3.1.8.5 ... user defined functions is
> an advanced technique. If you've gotten that far there does seem to be a
> build in assumption ...

Yeah, that's probably true; I wish I could say so in my case :-/  I've never
used functions in the way those examples indicate.

Post a reply to this message

On 02/27/2013 01:54 PM, Trevor G Quayle wrote:
> James Holsenback <nom### [at] nonecom> wrote:
>> On 02/27/2013 12:43 PM, James Holsenback wrote:
>> Oh and if you guys haven't already noticed the Reference has undergone a
>> bit of a re-organization
>
> Is there a reason for the reorganization?  Usually reference standards try to
> preserve their organization and clause numbering where possible to maintain
> continuity.  Certainly people using the newest version can use the new reference
> and be followed, however, if people are reading back at old postings on various
> topics, it can cause some confusion.
>
> -tgq
>
>

Well there was considerable debate, and I'll have to admit that I wasn't 
100% on-board with the changes, but in the end it's all good. I'd have 
to say that the main reason(s) for the re-org was to address previous 
inefficiencies (some sections were missing) and to give the layout a 
less "tacked on" appearance. If something is grossly out of whack, sure 
I'd say fix it, however I'm fairly pleased with the end results.

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:

>
> #declare foo = function {
>   pigment {
>     color red 1
>     }
>   }
>
> as the pigment is red anywhere, any value will return rgb value <1,0,0>.

The very simplicity of that one was a source of confusion as well--I came to the
same conclusion as you mention, which didn't make much practical sense. IMO,
that particular function might be more 'useful' (as a 'very simple example') if
the pigment was, say, rgb <1,.3,.7>.

In the v3.62 docs section 3.2.1.6.4  "Declaring User-Defined Vector Functions"
(immediately preceding the one I mentioned), there's another similar(??)
example...

 #declare foo = function {
   transform {
     rotate <90, 0, 0>
     scale 4
   }
 }

 #declare myvector = foo(4, 3, 7);

Would myvector ever return anything other than rotate <90,0,0> and scale 4? Or
am I still totally confused? (BTW, the spline function example in that section
*does* make sense to me, if I'm grasping the fundamental idea correctly.)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
  }
> >
> > as the pigment is red anywhere, any value will return rgb value <1,0,0>.
>
> The very simplicity of that one was a source of confusion as well--I came to the
> same conclusion as you mention, which didn't make much practical sense. IMO,
> that particular function might be more 'useful' (as a 'very simple example') if
> the pigment was, say, rgb <1,.3,.7>.

Hmm, I kind of sense that I'm wrong about my 'fix'; the function would then
return rgb <1,.3,.7> everywhere(?), which doesn't improve the example.

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
>
> For what it does:
>
> #declare Vec = foo(1,2,3) returns the rgb value at the (x,y,z) coordinate
> (1,2,3)
>
> #declare Val = foo(2,3,4).gray does the same thing, but then converts it to a
> single gray value based on rgb->grey conversion formula.

and later...

> Or perhaps you have a number of different flowers in a field (lets say five).
> Each time you check a spot where you want to place the flower, you can evaluate
> foo() at those coordinates...

Those are really clear and useful explanations. Thanks, Trevor! A new 'tool' to
use.

Up 'til now, I've been using eval_pigment to do exactly those kinds of things
(your flowers example.)

As is usual with me... ;-) ... I think that such a simple and concise
description of 'what it does' (the (1,2,3) values etc) would be a good addition
to the documentation--in "Declaring User-Defined Color Functions" perhaps or
somewhere preceding that.

Post a reply to this message

Am 27.02.2013 22:32, schrieb Kenneth:

> In the v3.62 docs section 3.2.1.6.4  "Declaring User-Defined Vector Functions"
> (immediately preceding the one I mentioned), there's another similar(??)
> example...
>
>   #declare foo = function {
>     transform {
>       rotate <90, 0, 0>
>       scale 4
>     }
>   }
>
>   #declare myvector = foo(4, 3, 7);
>
> Would myvector ever return anything other than rotate <90,0,0> and scale 4? Or
> am I still totally confused? (BTW, the spline function example in that section
> *does* make sense to me, if I'm grasping the fundamental idea correctly.)

The example is equivalent to

#declare fooTrans = transform {
   rotate <90, 0, 0>
   scale 4
}

#declare myvector = vtransform(<4,3,7>, fooTrans);

i.e. the function interprets the three parameters as coordinates in 3D 
space, rotates the corresponding point by 90 degrees around the x axis, 
and scales it by a factor of 4.

Post a reply to this message

On 27-2-2013 23:27, Kenneth wrote:
> Up 'til now, I've been using eval_pigment to do exactly those kinds of things
> (your flowers example.)

Same here. :-)

Thomas

Post a reply to this message