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