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