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