In order to implement object-water interaction into my
frame-independant system, I'll have to come up with a
way to calculate the position of an object at any given
moment. This is to ensure that in any given step of
the water-algorithm, the objects are in the appropriate
place, and not just at the spot where the frame would
dictate them to be.

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

Then, the User creates an array filled with strings, which
are the identifiers for the objects:
#declare Object_List=array[2] {"This_Object","That_Object"}

The macro will then parse the string along with the
transformation-macro, and thus I can create the position
and orientation of the object and any moment I please,
thus making it possible to calculate several steps in a
single frame. Internally, the object would then move
properly across the surface, even though on-screen it
stays put for one frame...

Additionally, this method provides the User with an easy
way to place his objects into the scenery in a precise way
which should line up with the animation of the water and
leaves almost no room for mistakes on the User's side:
object{This_Object This_Object_Transformation(clock)}

The only spot for problems is feeding the appropriate clock-
variable. The water-system is based upon the variable
"water_clock", which should run from 0 to 1. Thus, the object-
interaction will be calculated during that timespan, but I assume
that this should be obvious.

Does anyone have a better idea which meets the requirements:
-frame-independant transformation
-easy and intuitive use

Regards,
Tim

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

Post a reply to this message

"Tim Nikias v2.0" wrote:
> 
> [...]
> 
> Does anyone have a better idea which meets the requirements:
> -frame-independant transformation
> -easy and intuitive use

With transform functions you could easily interpolate between two
transforms but the tricky thing is you can't use the functions to
transform regular objects.  This of course leads to the idea of function
based transforms - this would be an interesting new feature.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

If you're after step-independant animation,
you're right, function-driven transform would definitely
be an exciting feature, though there's still the question
if POV's parsing would be of sufficient speed to actually
be of great use in terms of scripting complex
animation techniques.
Other than that, I'm looking for a nice and clean way
to take samples from an ongoing animation, and
don't need the data inbetween these steps, since the
water-surface algorithm itself is a stepped algorithm.

Aside of that, as I've looked into transform.inc, it seems
you can do object transformation. You'd just have to
convert from regular object to your isoCSG, and then
apply the transformation.
Though in this case, it might be handy to have some tool
which'll read a POV-file as input, and, if its CSG, convert
all the difference/intersection and sphere/box etc into
isoCSG-code, and then transform isosurfaces. This would
be pretty costly though. An other idea might be to use
convert a sphere to a set of data, and then apply the trans-
formation to the data. From this you could later reconstruct
the original sphere in its new position.
The hard part is the conversion and the appropriate approach,
and then returning back to csg where possible.
And for meshes you could save the three corners, transform
it, and then reconstruct the new triangle. Same applies to
surface-normals in case of smooth_triangles...

Well, I could go on talking about this stuff forever, and I guess
you already got the idea... :-)


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

>
>
> "Tim Nikias v2.0" wrote:
> >
> > [...]
> >
> > Does anyone have a better idea which meets the requirements:
> > -frame-independant transformation
> > -easy and intuitive use
>
> With transform functions you could easily interpolate between two
> transforms but the tricky thing is you can't use the functions to
> transform regular objects.  This of course leads to the idea of function
> based transforms - this would be an interesting new feature.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in 
news:3E82C325.E3BF946C@gmx.de:
... 
> With transform functions you could easily interpolate between two
> transforms but the tricky thing is you can't use the functions to
> transform regular objects.  This of course leads to the idea of function
> based transforms - this would be an interesting new feature.

I don't understand what you mean by "function based transforms".

Please explain (and if possible give an example of a problem
that it would solve that is not possible to solve in a "good"
way with POV-Ray v3.5).

(IIRC: "interpolating" between _any_ two arbitrary matrix
transformations are not a well defined problem.)


Tor Olav

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> Christoph Hormann <chr### [at] gmxde> wrote in
> news:3E82C325.E3BF946C@gmx.de:
> ...
> > With transform functions you could easily interpolate between two
> > transforms but the tricky thing is you can't use the functions to
> > transform regular objects.  This of course leads to the idea of function
> > based transforms - this would be an interesting new feature.
> 
> I don't understand what you mean by "function based transforms".
> 
> Please explain (and if possible give an example of a problem
> that it would solve that is not possible to solve in a "good"
> way with POV-Ray v3.5).

Well, as i said you currently can't use functions in transforms, therefore
you can't do much with it.  But as you know you can use transforms in
functions:

function { transform { ... } }

So you can declare two different transform functions and average them
(since current vector function support is limited too you have to use a
pigment function for that):

#declare fn_trans1=function { transform { ... } }
#declare fn_trans2=function { transform { ... } }

#declare fn_x = function { 0.5*(fn_trans1(x, y, z).x + fn_trans2(x, y,
z).x) }
#declare fn_y = function { 0.5*(fn_trans1(x, y, z).y + fn_trans2(x, y,
z).y) }
#declare fn_z = function { 0.5*(fn_trans1(x, y, z).z + fn_trans2(x, y,
z).z) }

#declare fn_trans_avg=
  Vector_Function(
    function { fn_x(x, y, z) },
    function { fn_y(x, y, z) },
    function { fn_z(x, y, z) }
  )

The 'Vector_Function()' macro uses the average pigment trick to combine
three float functions to one vector function.  This macro is included in
megapov's 'mechsim.inc' include file although the version coming with
megapov 1.0 is broken.

> (IIRC: "interpolating" between _any_ two arbitrary matrix
> transformations are not a well defined problem.)

This is surely correct but for situations like this the transforms to
interpolate between are not so different so this method probably leads to
acceptable results.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in
news:3E83121A.13AEC9A1@gmx.de: 

> 
> 
> Tor Olav Kristensen wrote:
>> 
>> Christoph Hormann <chr### [at] gmxde> wrote in
>> news:3E82C325.E3BF946C@gmx.de:
>> ...
>> > With transform functions you could easily interpolate between two
>> > transforms but the tricky thing is you can't use the functions to
>> > transform regular objects.  This of course leads to the idea of
>> > function based transforms - this would be an interesting new
>> > feature. 
>> 
>> I don't understand what you mean by "function based transforms".
>> 
>> Please explain (and if possible give an example of a problem
>> that it would solve that is not possible to solve in a "good"
>> way with POV-Ray v3.5).
> 
> Well, as i said you currently can't use functions in transforms,
> therefore you can't do much with it.  But as you know you can use
> transforms in functions:
> 
> function { transform { ... } }
> 
> So you can declare two different transform functions and average them
> (since current vector function support is limited too you have to use
> a pigment function for that):

I discarded the idea of using user defined pigment functions
as user defined vector functions some time ago, but I don't
remember why. (Maybe I didn't think of the "average trick".)

But it's nice if it really works.


> #declare fn_trans1=function { transform { ... } }
> #declare fn_trans2=function { transform { ... } }
> 
> #declare fn_x = function { 0.5*(fn_trans1(x, y, z).x + fn_trans2(x, y,
> z).x) }
> #declare fn_y = function { 0.5*(fn_trans1(x, y, z).y + fn_trans2(x, y,
> z).y) }
> #declare fn_z = function { 0.5*(fn_trans1(x, y, z).z + fn_trans2(x, y,
> z).z) }
> 
> #declare fn_trans_avg=
>   Vector_Function(
>     function { fn_x(x, y, z) },
>     function { fn_y(x, y, z) },
>     function { fn_z(x, y, z) }
>   )

You can write the above expression like this:

#declare fn_trans_avg = Vector_Function(fn_x, fn_y, fn_z)

(Just in case you didn't know.)


> The 'Vector_Function()' macro uses the average pigment trick to
> combine three float functions to one vector function.  This macro is
> included in megapov's 'mechsim.inc' include file although the version
> coming with megapov 1.0 is broken.
> 
>> (IIRC: "interpolating" between _any_ two arbitrary matrix
>> transformations are not a well defined problem.)
> 
> This is surely correct but for situations like this the transforms to
> interpolate between are not so different so this method probably leads
> to acceptable results.

But this would lead to incorrect result in many
cases. E.g. for rotations:

Interpolate between the rotations of a vector
<1, 0, 0> around the y-axis. First 90 degrees
and then 270 degrees.

The result of each rotation would be <0, 0, -1>
and <0, 0, 1>. And the average of this would
be (<0, 0, -1> + <0, 0, 1>)/2 = <0, 0, 0>, which
is clearly wrong. The result should have been
a rotation of (90 + 270)/2 = 180 degrees about
the y-axis, i.e. <-1, 0, 0>.


Tor Olav

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> [...]
> 
> You can write the above expression like this:
> 
> #declare fn_trans_avg = Vector_Function(fn_x, fn_y, fn_z)
> 
> (Just in case you didn't know.)

Just habit - there was a time during 3.5 pre-beta when you could not and
since i wrote most of the isocsg stuff then i got used to it...

> [...]
> 
> But this would lead to incorrect result in many
> cases. E.g. for rotations:
> 

Sure, but as i said if the rotation is small this can be reasonably
approximated with my method.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in 
news:3E832C90.1732E339@gmx.de:

> Tor Olav Kristensen wrote:
>> 
>> [...]
>> 
>> You can write the above expression like this:
>> 
>> #declare fn_trans_avg = Vector_Function(fn_x, fn_y, fn_z)
>> 
>> (Just in case you didn't know.)
> 
> Just habit - there was a time during 3.5 pre-beta when you could not and
> since i wrote most of the isocsg stuff then i got used to it...
...

Yes I remember. While optimizing some of my older
source code, I found that the "long version" slows
down rendering of isosurfaces.


I'm sorry, but I still do not understand what
you meant by "function based transforms".

Is it just a linear interpolation between the
locations of points after two subsequent
transformations ?


Tor Olav

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> [...]
> 
> I'm sorry, but I still do not understand what
> you meant by "function based transforms".

Well, i meant to base a transfor on a function.  The syntax would be like:

transform { function { ... } }

and the function would have to be a vector function with three parameters
(just like a transform function).  

transform { function { transform { ... } } }

would therefore be the same as 

transform { ... }

The nice thing would be you could do things like averaging (as
explained).  Of course this is not implemented yet and i am not even sure
if it would work under all circumstances (at least nonlinear
transformations would lead to strange results).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
news:Xns### [at] 204213191226:

...
> I discarded the idea of using user defined pigment functions
> as user defined vector functions some time ago, but I don't
> remember why. (Maybe I didn't think of the "average trick".)
...

I just looked into the mechsim.inc file.

And now I remembe more. Wasn't it ABX who first
showed some examples using pigment functions as
vector functions ?

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


Tor Olav

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in
news:3E83326C.A49E0145@gmx.de: 

> 
> 
> Tor Olav Kristensen wrote:
>> 
>> [...]
>> 
>> I'm sorry, but I still do not understand what
>> you meant by "function based transforms".
> 
> Well, i meant to base a transfor on a function.  The syntax would be
> like: 
> 
> transform { function { ... } }
> 
> and the function would have to be a vector function with three
> parameters (just like a transform function).  
> 
> transform { function { transform { ... } } }
> 
> would therefore be the same as 
> 
> transform { ... }
> 
> The nice thing would be you could do things like averaging (as
> explained).  Of course this is not implemented yet and i am not even
> sure if it would work under all circumstances (at least nonlinear
> transformations would lead to strange results).

So this sould enable users to do the same thing
to other primitive objects as we can do to iso-
surface objects today ?

That would be great.

But wouldn't it lead to difficulties determining
the intersections between the "tracing ray" and
complex CSG objects ?

And how should the bounding shapes be determined ?


Tor Olav

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> [...]
> 
> So this sould enable users to do the same thing
> to other primitive objects as we can do to iso-
> surface objects today ?

No, it would not deform the object.  Transforming a box would always
result in a box.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> I just looked into the mechsim.inc file.
> 
> And now I remembe more. Wasn't it ABX who first
> showed some examples using pigment functions as
> vector functions ?

I don't know who 'invented' this technique.  Could be that ABX showed an
example for it recently.

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

This should not be much problem in most cases.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Tim Nikias v2.0" <tim### [at] gmxde> wrote in 
news:3e82d3e5@news.povray.org:

...
> Aside of that, as I've looked into transform.inc, it seems
> you can do object transformation. You'd just have to
> convert from regular object to your isoCSG, and then
> apply the transformation.
> Though in this case, it might be handy to have some tool
> which'll read a POV-file as input, and, if its CSG, convert
> all the difference/intersection and sphere/box etc into
> isoCSG-code, and then transform isosurfaces. This would
> be pretty costly though. An other idea might be to use
> convert a sphere to a set of data, and then apply the trans-
> formation to the data. From this you could later reconstruct
> the original sphere in its new position.
> The hard part is the conversion and the appropriate approach,
> and then returning back to csg where possible.
> And for meshes you could save the three corners, transform
> it, and then reconstruct the new triangle. Same applies to
> surface-normals in case of smooth_triangles...
...

Sorry Tim, but if all your transformations are linear,
then I think that you are making things more difficult
then they are.

Instead of converting a CSG-object to an isosurface,
apply several transformations to it and then convert
it back to a CSG object, you could just multiply all
the matrices for the transformations successively with
an identity matrix and then finally apply the resulting
transformation matrix to your CSG-object.

In POV-Ray script it is done like this:

#declare TotalTransform =
  transform {
    scale <1, 1 + Time/10, 1>
    rotate 45*Time*y
    transform { SomeOtherTransformation }
    translate <1, -2, 3>*<Time, 1, Time*Time>
//    ... and so on ...
  }

object {
  YourCSG_Object
  transform { Totaltransform }
}

(POV-Ray will do all the matrix calculations for you.)


If you need to calculate the whole animation
sequence at once, then just calculate all the
transformations and then store all of them in
an array.

Here's how you could do it:

#declare Transformations[0] =
  transform { TransformationForStep0 }

#declare Transformations[1] =
  transform {
    transform { Transformations[0] }
    TransformationForStep1
  }

#declare Transformations[2] =
  transform {
    transform { Transformations[1] }
    TransformationForStep2
  }

... And so on (e.g. in a while loop) ...


If a transformation for a step depends on the position
(point) or direction (vector) of some objects, then
just apply the transformation for the previous step to
the points/vectors (in their _initial_ "state"). You can
use vtransform() to do this.

(Note that normal vectors for a surface must be treated
differently.)


Tor Olav

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in 
news:3E834C04.8D43EA73@gmx.de:

> 
> 
> Tor Olav Kristensen wrote:
>> 
>> [...]
>> 
>> So this sould enable users to do the same thing
>> to other primitive objects as we can do to iso-
>> surface objects today ?
> 
> No, it would not deform the object.  Transforming a box would always
> result in a box.

But then POV-Ray would need to examine the
vector function in order to make sure that
it does not represent a non-linear trans-
formation.

And if it is only allowed to be a linear
transformation, then I think that it will
only be useful within isosurfaces, pigments
and maybe patterns.

I suspect that this would not allow for new
types of transformations. It would only make
it easier to do certain transformation (that
are already possible today).


Or am I wrong about all this ?


Tor Olav

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> [...]
> 
> But then POV-Ray would need to examine the
> vector function in order to make sure that
> it does not represent a non-linear trans-
> formation.
> 
> And if it is only allowed to be a linear
> transformation, then I think that it will
> only be useful within isosurfaces, pigments
> and maybe patterns.
> 
> I suspect that this would not allow for new
> types of transformations. It would only make
> it easier to do certain transformation (that
> are already possible today).
> 
> Or am I wrong about all this ?

I have no idea what you are talking about.  A transform can always be seen
as a function -  you put in a vector and get out a vector.  Nothing
prevents you to use an arbitrary vector function for that and not just a
transformation matrix.  There might of course be problems when calculation
of the bounding box or similar things imply transformations being linear.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in
news:3E836145.921A71E8@gmx.de: 

> 
> 
> Tor Olav Kristensen wrote:
>> 
>> [...]
>> 
>> But then POV-Ray would need to examine the
>> vector function in order to make sure that
>> it does not represent a non-linear trans-
>> formation.
>> 
>> And if it is only allowed to be a linear
>> transformation, then I think that it will
>> only be useful within isosurfaces, pigments
>> and maybe patterns.
>> 
>> I suspect that this would not allow for new
>> types of transformations. It would only make
>> it easier to do certain transformation (that
>> are already possible today).
>> 
>> Or am I wrong about all this ?
> 
> I have no idea what you are talking about.  A transform can always be
> seen as a function -  you put in a vector and get out a vector. 
> Nothing prevents you to use an arbitrary vector function for that and
> not just a transformation matrix. 
...

Then we are talking about exactly the same thing.

You said that a vector function transformation should
not be able to deform a box; such a transformation of
a box should always result in a box. From this I
reasoned that this would mean that that transformation
step would be linear.(*)

I'm just questioning if allowing for such vector
functions to be used as transformations will introduce
any new possibilities outside isosurfaces and pigments.

Don't misunderstand me. I think we really need vector
functions, but I just don't understand how they can be
so useful in transformations if non-linear trans-
formations with them aren't allowed.


Tor Olav


(*) One could construct transformations that are non-
linear and that will preserve _some_ boxes as boxes
through the transformation. E.g.:

VectorFunction(x, y, z) { <select(x, -x, x)*x, y, z> }

(But I think that many boxes will be deformed by
this transformation.)

Another non-linear transformation function that
comes to my mind are this:

VectorFunction(x, y, z, w) { <x/w, y/w, z/w> }

This would be a useful 4D vector to 3D vector
transformation.

But I am having trouble coming up with 3D to 3D
transformations that are non-linear and that will
guarantee that all boxes are preserved as boxes.

Do you have any examples ?

Post a reply to this message

I was just rambling about Christoph's idea of using
functions for transformations.

My system does work like I initially suggested (or actually,
will work):
it takes an object and a macro, both are supplied by the
user. If he wants the object move along a spline, fine, he
just sets a translate Along_Spline in the transformation-macro.
Thus I can access any moment of the objects path by calling
the macro with an appropriate value for X, and I can take samples
of the objects' positions and calculate the interaction with the
surface.
Thats all I need, and since no one has come up with a better
solution so far, thats what I'm gonna do.

Never planned on using functions for this.
(Hope I'm not sounding offensive here, but the Outlook just
quits working every now and then, and I feel like I should
make myself short and clear, and prevent it from crashing
before sending the message...)

Regards,
Tim

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

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> [...]
> 
> Then we are talking about exactly the same thing.
> 
> You said that a vector function transformation should
> not be able to deform a box; such a transformation of
> a box should always result in a box. From this I
> reasoned that this would mean that that transformation
> step would be linear.(*)
> 

Well, i think in fact you are right but the reason is somewhat different -
a function based transform would be somewhat difficult to invert and
transforming objects requires the inverse transform...

You could of course transform at least some objects directly and not by
transforming the ray instead like it is currently done but this would be a
completely different thing.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in
news:3E83828D.A385D8F8@gmx.de: 

> 
> 
> Tor Olav Kristensen wrote:
>> 
>> [...]
>> 
>> Then we are talking about exactly the same thing.
>> 
>> You said that a vector function transformation should
>> not be able to deform a box; such a transformation of
>> a box should always result in a box. From this I
>> reasoned that this would mean that that transformation
>> step would be linear.(*)
>> 
> 
> Well, i think in fact you are right but the reason is somewhat
> different - a function based transform would be somewhat difficult to
> invert and transforming objects requires the inverse transform...

Yes, I had a "diffuse" suspicion of something like
that when I wrote this:

'But wouldn't it lead to difficulties determining
the intersections between the "tracing ray" and
complex CSG objects ?'


Tor Olav

Post a reply to this message

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