Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> I think that leaving the responsability to handle these stacks of
> transformations to the programmer is dangerous and requires too much
> programming skills wrt the goal we intend to reach in terms of programming
> ease and accessibility.

  There's no more skill involved than in the current POV-Ray when you apply
a series of transformations to an object.
  There's no need for a stack. There's no need to revert transformations.
You simply apply a series of transformations to the object at each frame
(basically what you do with the current SDL, but without having to reparse
the object).

  I really can't understand what is the problem people are seeing here.
Could someone please explain to me this?

  Is it that some people seem to think that once you have applied a
texture to the object you can't transform the object without transforming
the texture too? Says who? Just because you can't do it in the current SDL
that doesn't mean it wouldn't be possible in the new one. Even in the
current SDL it's just a *syntactical* limitation. There's absolutely no
technical reason why there couldn't be a command like "apply this
transformation to the object but not its texture". It would simply be
a question of adding the proper syntax for it.

  Seemingly some people also think that if a transformation has been
applied, it's engraved in stone and cannot be removed anymore. Removing
all the transformations is just a question of resetting the transformation
matrix. Then you can re-apply all the transformations you want to the
object, making the modifications you want.

  (Granted, in the current POV-Ray implementation this would require a
bit more of work because certain transformations to certain objects are
"optimized away", for example by applying the transformation to some
object coordinate instead of applying it to the transformation matrix.
Thus such a transformation would indeed by "engraved in stone" and not
possible to revert.
  However, it's perfectly possible to change this system without removing
these optimizations. It's possible to apply all the transformations to
the transformation matrix of the object and then, after all the
transformations have been applied, just before starting the rendering,
it's possible to examine the transformation matrix for certain properties
and if these properties exist, they can be "optimized away" in the same
way as currently. For example, if the object is a sphere there exists a
translation component, the translation can be applied to the center
coordinate of the sphere and removed from the transformation matrix.)

> My point of view is that within a single frame, all transforms should be
> defined at creation time, and post creation transforms should be forbidden

  Why impose such an artificial limitation? It doesn't make any sense.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> I know damn well how they work.

  In that case you are doing a pretty good job at hiding it.

> And you don't solve the problem by 
> reverting things.

  By "reverting" I mean resetting the transformation matrix and applying
the transformations again (with possible changes). Exactly as the current
POV-Ray does, but without the need to reparse the object.
  I really can't see the problem you are having with this.

> How do you revert **only** to the Nth transform so 
> that you change only that one?

  By changing only the Nth transformation you apply to the object? What is
the problem you are seeing here?

> You are assuming, I think wrongly, that 
> no combination of transforms can produce a situation where the result 
> cannot be reset, then some arbitrary transform reapplied to make the one 
> change needed.

  You mean that it's possible to apply certain transformations to a
transformation matrix in a way that the transformation matrix cannot
be reset anymore? Now that would be a rather interesting thing to see.

> Worse, your assertion that all you need to do, if it is a 
> problem, is keep every transform in some sort of array, then reapply 
> them from that, is...

  I didn't say that. What I said is that if you *want* to keep the
transformations in an array, you *can*. However, you don't *have to*.
It makes no sense to force such an array to exist when there is no
need for one.

> What they frack do you think I have been saying? 

  What you have been saying is that every object should have an inner
array of transformations.
  This proposition makes no sense. It makes things needlessly complicated
and, worse, *hard-codes* one possible solution.

  The easiest solution is to *not* have any such array in the object,
but at each frame you simply apply a set of transformations to the object,
exactly as you do with the current POV-Ray, but without the need to
reparse the object. I gave a small example in a previous post.

  What you *can* do if you *want*, for whatever reason, is to have the
transformations in an array and then apply them in a loop to the object.

> Your, "just make some 
> separate transform array", just obfuscates what is going on, by 
> separating the transforms from the object they effect, when they should, 
> logically be considered "part" of the final object

  No, it's *your* solution which is obfuscating things, by forcing the
user to use some kind of array when there isn't a need for one.

  The current POV-Ray SDL doesn't need any transformation arrays, nor does
the new SDL.

> I think you are badly missing my point, both in terms of what I mean and 
> how any such system would end up looking from a user standpoint.

  I think that it's you who is confused about how transformations can and
should be applied to objects. Your array idea is just bad.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:

> > My point of view is that within a single frame, all transforms should be
> > defined at creation time, and post creation transforms should be forbidden
>
>   Why impose such an artificial limitation? It doesn't make any sense.
>
> --
>                                                           - Warp

I agree there is no technical limitation. But I can see drawbacks. In the
current syntax, we write

#declare my_sphere = sphere
{
   0, 1
   pigment {White}
   translate <1,2,3>
}
..../...
trace (my_sphere, ...)

Once the sphere has been created (= after the ending '}' of the syntactical
block), the sphere stays how it is and we have no mean to apply a new
transform to it afterwards. The only way I see to fake this is to create a
new object and transform it:

#declare my_sphere_2 = object {my_sphere translate <4,5,6>}

But the first sphere remains present (even if it had no_image, no_shadow
....).


The new syntax might allow such code:

my_sphere = sphere
{
   0, 1
   pigment {White}
   translate <1,2,3>
}
..../...

my_sphere.translate y;

trace (my_sphere, ...)

And you get what you want, for animations for example, provided you are
programmatically skilled enough to keep track of your objects and what
happens to them.

My opinion (I'd rather say my 'intuition', but may change, I am not that
proud of myself) is that if you perform transformations in different
locations in the code, perhaps out of the scope of the current source file,
you can never be sure for the current object's situation, and therefore for
the end result.

I agree that, with current syntax, you can store transforms in an array,
access this array through the clock or frame_number variable. But I find
this not very handy. I would prefer a build-in mechanism for animations
with relevant syntax. For example, if we attach timelines to objects, we
could write (I put it as it comes to my mind, I am trying ...):

DURATION = 25;

ejection = timeline (direction:vector)  // could be 'animate' keyword
{
    function
    {
        <parabolic trajectory equation>
        return <computed transform>
    }
}

stone
{
    0, 1
    roundness 0.3
    random 123.456
    pigment
    {
        timeline
        {
            [0 agate turbulence 0.3 color_map{CM_LAVA_HOT}] // t<=0
            [2 granite turbulence 0.3 color_map{CM_LAVA_SEMI_HOT}] // t=2
            [5 agate turbulence 0.3 color_map{CM_VOLCANIC}] // t=5
            cycle 3 // restart at t=3 for t>5*n
            interpolate 2
        }
    }

    transform
    {
        translate {CRATER_POS}
        timeline {ejection (DURATION)}
    }
}

And POV4 does the job. And 3rd party tools could easyly generate code for
anims.

Bruno.

Post a reply to this message

>   (Granted, in the current POV-Ray implementation this would require a
> bit more of work because certain transformations to certain objects are
> "optimized away", for example by applying the transformation to some
> object coordinate instead of applying it to the transformation matrix.
> Thus such a transformation would indeed by "engraved in stone" and not
> possible to revert.

Just curious : I wasn't aware of that kind of optimizations (I thought
that everything was done by matrix, as the docs states).  Does it really
makes a difference in speed ?  After all, so few objects are concerned
(sphere, cylinder, what else ?), and it's useless as soon as an non-uniform
scale is applied...

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Just curious : I wasn't aware of that kind of optimizations (I thought
> that everything was done by matrix, as the docs states).  Does it really
> makes a difference in speed ?

  I don't remember if someone has ever made a benchmark.

  I suppose that you could make a comparison with POV-Ray 3.6 by first
rendering a scene with a lot of spheres which are only translated and
then rendering the same scene with the same spheres with the same
translations, but additionally something "scale <1, .9999, 1>" is
applied to each sphere, which would force it to use a transformation
matrix.

  My guess is that it might make a measurable difference, but perhaps
not a huge one (because most of the time is probably spent in the bounding
box hierarchy tests).

-- 
                                                          - Warp

Post a reply to this message

> Sigh.. You are I think making an assumption that, when you do want to 
> change something, you would only want to change "one" transform. But, 
> maybe you have a dozen, each with does something specific to positioning 
> the object, each of which is "also" effected by all of the prior 
> transforms. Tell me, with a real example, not just some assertion that I 
> am imagining a problem, how you do that. Yes, you can use some commands 
> that can revert the object to a known state, like at the origin, then 
> transform it, but that is useless if the transform you need is relative 
> to some arbitrary point, which is the result of 3-4 other prior 
> transforms. How do you, if you are doing say 7 translates, for some odd 
> reason, revert back to the 3rd, change the 4th, then reapply the last 3? 
> You can't, without drastically altering how you handled those transforms 
> in the first place, and reducing them to a bare minimum number needed to 
> do the task. Sure, it might be possible, but it still breaks, as near as 
> I can tell, when you try to provide a post-creation transform on the 
> object, to modify the prior result. Show me that I am wrong, don't just 
> tell me I am.
> 

What do you mean with changing "one" transform? There is only one 
transform per object/texture/camera/thing. POV-Ray doesn't (and doesn't 
need to) keep track of each translate/rotate/scale you type.

Post a reply to this message

> I agree there is no technical limitation. But I can see drawbacks. In the
> current syntax, we write
> 
> #declare my_sphere = sphere
> {
>    0, 1
>    pigment {White}
>    translate <1,2,3>
> }
> ..../...
> trace (my_sphere, ...)
> 
> Once the sphere has been created (= after the ending '}' of the syntactical
> block), the sphere stays how it is and we have no mean to apply a new
> transform to it afterwards. The only way I see to fake this is to create a
> new object and transform it:
> 
> #declare my_sphere_2 = object {my_sphere translate <4,5,6>}
> 
> But the first sphere remains present (even if it had no_image, no_shadow
> ....).
> 
> 
> The new syntax might allow such code:
> 
> my_sphere = sphere
> {
>    0, 1
>    pigment {White}
>    translate <1,2,3>
> }
> ..../...
> 
> my_sphere.translate y;
> 
> trace (my_sphere, ...)
> 
> And you get what you want, for animations for example, provided you are
> programmatically skilled enough to keep track of your objects and what
> happens to them.
> 
> My opinion (I'd rather say my 'intuition', but may change, I am not that
> proud of myself) is that if you perform transformations in different
> locations in the code, perhaps out of the scope of the current source file,
> you can never be sure for the current object's situation, and therefore for
> the end result.

#declare foo = object { foo translate <1,2,3> }

Add a few of those randomly around your code and "you can never be sure 
for the current object's situation". But aren't there times where it 
would be useful, when you know where transformations are being done? 
foo.translate(1,2,3) is just a nicer syntax for that, and also will 
probably run faster (no need to actually create a new object).

Post a reply to this message

> In article <4709fc49@news.povray.org>, war### [at] tagpovrayorg says...
>> Patrick Elliott <sel### [at] rraznet> wrote:
>>> And I don't think you have *at all* addressed what I was getting at. How 
>>> do you do something like IK, without either a) allowing an object like 
>>> reference system *which keeps track of* which order the transforms took 
>>> place in, such that if you move something, then rotate it, you don't 
>>> want to later just rotate it, and assume its going to produce the same 
>>> result, or b) limiting the types of transforms that *are* possible to an 
>>> already parsed object, or c) reparsing every damn thing in the script, 
>>> so you can recalculate just what the heck the object is described doing 
>>> *in that frame*?
>>   You don't need to reparse the entire object if you simply want to apply
>> some new transformations to it. What you do is to reset its transformation
>> matrix and apply the new transformations to it. That's it.
>>
>>   If what you are doing requires remembering and applying a set of
>> transformations in order, you can simply create an array or whatever
>> with these transformations, or whatever you like. However, that's
>> completely irrelevant from the point of view of the object itself.
>>
>>   The only thing you have to be able to specify is whether a transformation
>> is applied to the object only, the texture only, or both.
>>
>>   You don't seem to understand how transformations work.
>>
> I know damn well how they work. And you don't solve the problem by 
> reverting things. How do you revert **only** to the Nth transform so 
> that you change only that one?

There is no such thing as the Nth transform. There is only one 
transformation matrix. You don't seem to understand how transformations 
work.

Post a reply to this message

Warp  wrote in message <470b5016@news.povray.org>:
>   There's no more skill involved than in the current POV-Ray when you apply
> a series of transformations to an object.
>   There's no need for a stack. There's no need to revert transformations.
> You simply apply a series of transformations to the object at each frame
> (basically what you do with the current SDL, but without having to reparse
> the object).
> 
>   I really can't understand what is the problem people are seeing here.
> Could someone please explain to me this?

I am not sure that this is exactly the problem that everyone else has in
mind, but I can see an example. Consider that you are writing an articulated
model using CSG (maybe a robot or something). Consider the elbow: there is
an articulation, meaning a variable rotation.

To make it easily, you proceed that way:

- you move the forearm part to put the elbow at the origin;

- you apply the free rotation;

- you move the forearm to put the elbow at the end of the upper arm.

And later, you move the whole arm as a whole.

If you want to change the free rotation of the elbow, you need to change the
second of the three transformations applied to the forearm.

With the current SDL, the way to do that is to pre-define all the values for
free rotations, and then build the whole object.

With a new SDL, I hope it would be possible to write something like that:

#declare Giskard = Robot(...);
Giskard.forearm.rotate(30*x);

The naive way to write this object is something like that:

#declare Arm = union {
 [... upper arm ...]
 object {
   Forearm
   translate <to move it to the origin>
   rotate <free rotation>
   translate <to the elbow>
 }
}

If things are done that way, it is necessary to be able to change the
rotation between the two translations.

On the other hand, things can be written:

#declare Arm = union {
 [... upper arm ...]
 object {
   object { /* forearm at origin here */
     Forearm
     translate <to move it to the origin>
   }
   translate <to the elbow>
 }
}

In that case, it is enough to be able to apply a new transform to the object
marked by the comment. But maybe this is less efficient.

Post a reply to this message

Bruno Cabasson wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Bruno Cabasson wrote:
>>> andrel <a_l### [at] hotmailcom> wrote:
>>>> Bruno Cabasson wrote:
>>>>> Concerning the animation problem, I see things as follows:
>>>>>
>>>>> Solution 1:
>>>>> -----------
>>>>> The nth frame I(n) of an animation is a function of time only. Its
>>>>> description depends on the sole time parameter. Then you can conceptually
>>>>> write:
>>>>>
>>>>> I(n) = F(tn), with F being the function that describes the scene at time tn.
>>>>>
>>>>> This is POV's point of view, through the 'clock' variable and reparsing the
>>>>> whole scene (except radiosity and photon maps if so specified).
>>>>>
>>>>> This solution requires only the description of the F(t) function.
>>>>>
>>>>> Solution 2:
>>>>> -----------
>>>>> The nth frame I(n) is made by delta wrt first frame. Its description relies
>>>>> on the description of first frame at t0 and a delta function that depends
>>>>> on the time parameter. Then you can conceptually write:
>>>>>
>>>>> I(n) = I(0) + D(tn), with D being the function that describes the variation
>>>>> of the scene between tn and t0.
>>>>>
>>>>> This solution requires the decription of I(0) and the D(t) function.
>>>>>
>>>>> Solution 3:
>>>>> -----------
>>>>> The nth frame I(n) is made by delta wrt previous frame. Its description
>>>>> relies on that of the previous frame I(n-1) and a delta function that
>>>>> depends on the two instants tn and tn-1. Then you can conceptually write:
>>>>>
>>>>> I(n) = G(I(n-1)) = I(n) + d(tn, tn-1), with d being the function that
>>>>> describes the variation of the scene between tn and tn-1.
>>>>>
>>>>> This solution requires the description of I(0) and d(t1, t2) function.
>>>>>
>>>>>
>>>>> Each of these solution is a different approach with pros and cons and
>>>>> implies related features and syntax.
>>>>>
>>>>> Concerning POV4, which of these is preferable?
>>>>>
>>>> none or all
>>> What do you mean exactly? I don't get your point ...
>> simply that if at frame n you want to position and transform an object
>> you will be allowed to access the state in frame n-1, so you can
>> transform incremental (3). You can also reset the transformation
>> variables and start from there (1) or first revert to a known situation
>> either because POV4 gets a mechanism to make a snapshot or because
>> somebody will write a function (formerly a #macro) to do so.
>>
>> So all will be possible and none will be preferable. It depends on the
>> application which one is more natural and if you use a GUI you won't
>> even know.
> 
> OK, but I'm still not sure I get you. You seem to suggest that POV4 should
> implement all 3 approaches for convenience reasons, and that they are
> equivalent wrt this. But would not implementing all 3 (or more) solutions
> yield too a voluminous syntax and wouldn't it be somewhat confusing to the
> user instead of being more convenient? And POV4 would have to implement
> all, which means more development effort.
no not at all, it would be more difficult to implement it in a way that 
only one option is possible.
Here is how is might be done:
scheme 1)
/* everything parsed, now in the segment that positions for frame FrameNr */
object.transform.reset // revert to initial position
object.translate(X(FrameNr),Y(FrameNr),Z(FrameNr))
object.rotate(A(FrameNr),B(FrameNr),C(FrameNr))

scheme 2)
/* everything parsed, now in the segment that positions for frame FrameNr */
/* keep current transform matrix */
object.translate(dX(FrameNr),dY(FrameNr),dZ(FrameNr))
object.rotate(dA(FrameNr),dB(FrameNr),dC(FrameNr))
/* note: rotate and translate do interact */

scheme 3)
/* at the end of the creation of the objects, but before the */
/* positioning of objects for frame FrameNr */
if FrameNr==0
   save_transforms_of_all_objects
else
   load_transforms_of_all_objects
/* everything is now positionable wrt to first frame */
   object.translate(X(FrameNr),Y(FrameNr),Z(FrameNr))
   object.rotate(A(FrameNr),B(FrameNr),C(FrameNr))
end

> 
> BTW, considering the problem of POV4's development: who will? What is the
> manpower and skills available today? We have POV-team and perhaps
> volunteers around here. But it is quite a long-term commitment. Would
> POV-team members be likeley to? Such a developmement requires a good
> implusion at the start AND perennial manpower AND a team developmement
> process. To my understanding (and whish), POV4 cannot be a hack. It
> requires an 'industrial' process, whether or not it is open-sourced.
> Anyway, I don't worry about the testing power ...
> 
>>> POV has currently solution 1.
>> no, it reparses the scene for every frame.
> 
> This is precisely what I(n) = F(tn) means: every frame is a function of the
> sole time parameter through the clock variable. Solution 1 means therfore
> that the scene is reparsed every frame, all stuff of the scene is re-build
> from scratch and from the clock variable or its derived variables such as
> frame_number. They all represent an 'absolute' time.
There is no need to reparse the object creation block in POV4.

Post a reply to this message