On 27 Mar 2003 12:25:24 -0500, Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com>
wrote:
> And now I remembe more. Wasn't it ABX who first
> showed some examples using pigment functions as
> vector functions ?

Some long time ago (before isocsg) I had a discussion in p.general about that
but I'm sure I wasn't the first one who used it. At that time I cosidered it
obvious and I hadn't feel I introduce something. Just explained it to the user.

> It is a pity though that the value ranges are
> limited.

Since more things become vector-function based (user-defined camera for example)
there will be patch with such feature available probably.

As for main problem of this part of thread: applying transform-based function to
object can be probably solved method similiar to
http://news.povray.org/cd3outglhk60i0mk3scelr52p9cu5nv8uo%404ax.com so I assume
smart macro could be enough, isn't it?

ABX

Post a reply to this message

Tim Nikias v2.0 wrote:
> To achieve this, I've come up with following method:
> You declare you're object along with a similiar named
> transformation-macro:
> #declare This_Object=...
> #macro This_Object_Transformation(X)
>  transform{ [Stuff based on X] }
> #end

Alternatively, if you want to give the user more freedom, you can simply
put the object itself inside the macro:

#macro This_Object(X)
   object { [Stuff based on X] }
#end

This makes things possible that transformations can't do, for example
altering the function of an isosurface based on X or changing the
positions of individual elements in a blob. Furthermore, the user can
conveniently base other things on X, like the texture of the object.
Even if this has no effect in the water-simulation context, it still is
more handy because the user might want to synchronize some things that
does matter (like shape and transformation) with some other things that
doesn't (like texture).

In my particle system I also needed to know things about objects and
values for any in-between frame clock values, and I have also used the
#macro approach.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Hm, never though about that idea, but it makes sense
combining it...
I guess I didn't think of that, cause I don't work with
functions, and cause I normally model and object, and
then move it around... Thanks!

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> Tim Nikias v2.0 wrote:
> > To achieve this, I've come up with following method:
> > You declare you're object along with a similiar named
> > transformation-macro:
> > #declare This_Object=...
> > #macro This_Object_Transformation(X)
> >  transform{ [Stuff based on X] }
> > #end
>
> Alternatively, if you want to give the user more freedom, you can simply
> put the object itself inside the macro:
>
> #macro This_Object(X)
>    object { [Stuff based on X] }
> #end
>
> This makes things possible that transformations can't do, for example
> altering the function of an isosurface based on X or changing the
> positions of individual elements in a blob. Furthermore, the user can
> conveniently base other things on X, like the texture of the object.
> Even if this has no effect in the water-simulation context, it still is
> more handy because the user might want to synchronize some things that
> does matter (like shape and transformation) with some other things that
> doesn't (like texture).
>
> In my particle system I also needed to know things about objects and
> values for any in-between frame clock values, and I have also used the
> #macro approach.
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision:  http://runevision.com (updated Oct 19)
> POV-Ray Ring: http://webring.povray.co.uk
>
>

Post a reply to this message