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