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

Post a reply to this message

In article <4709fb43@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > If you have something like:
> 
> > #declare yy = clock
> > sphere {...
> >   translate <yy,35,61>
> >   texture { some_complex_texture translate 100*x}
> >   translate y*2}
> 
> > Then you **must** reparse the object every single time, because once th
e 
> > object exists internally, it can't be changed.
> 
>   Wrong.
> 
>   The object has its own transformation matrix and the texture its own.
> All transformations applied to the object go to its transformation matrix
,
> and all transformations applied to the texture (be it directly in the
> texture block or indirectly in the object block) go to the transformation
> matrix of the texture.
>   It would be perfectly possible to alter these two transformation matric
es
> afterwards. It's simply a question of which transformations are applied t
o
> the object only, which ones to the texture only and which ones to both.
> 
> > The 
> > transforms you need to be able to change are "not" sitting conveniently
 
> > as the last thing in the object, they are buried deep within the 
> > structure.
> 
>   You seem to have this concept that the transformations are somehow
> stored in the definition of the object, and that this order must be
> preserved.
> 
>   The individual transformations are not stored anywhere. Each transforma
tion
> is simply a command (a kind of "function call" if you like) which modifie
s
> the internal transformation matrix of the object.
> 
>   It would be perfectly possible, after the object has been created (with
> the transformations and all), to reset its transformation matrix and then
> apply the same transformations to it, resulting in the exact same end
> result. The only distinction you have to make is which transformations
> go to the object, which ones to the texture and which ones to both.
> 
> > If we want to be able to animate, without a reparse, we need 
> > an internal representation that allows "each" transform, texture, 
> > object, etc. to exist as accessible elements, not as static 
> > declarations.
> 
>   No we don't.
> 
> > In other words, you need to make it "look" like:
> 
> > yy = yy + 1
> > mysphere.translate(0)=yy,35,61
> 
> > Even as the engine keeps track of "how" those things connect:
> 
> > start->translate(0)->texture(0)->translate(1)->end
> 
>   The engine doesn't need to keep track of that. You should acquaint
> yourself with transformation matrices and how they work.
> 
> > How else do you both allow animation, without a reparse, but also 
> > maintain the capacity to place as many transforms, or other elements,
 
> > into the object as you can now?
> 
>   You can write a thousands individual transformations into an object,
> yet none of them will be (individually) stored anywhere. They are all
> applied to one single 4x4 transformation matrix. POV-Ray doesn't need
> to keep track of the individual transformations nor store them anywhere.
> 
>   The only thing you need to specify is whether a certain transformation
> is applied to the object, to the texture, or both.
> 
> > See what I am getting at? If you want to maintain the "existing" SDL,
 
> > you have to allow for this, or suffer the current consequence of having
 
> > to reparse the "entire" SDL every frame.
> 
>   That's just not true. The only thing you have to allow in the new SDL
> is to be able to apply transformations to the object only, the texture
> only or both at the same time. This is very trivial to do.
>   It's perfectly possible to transform the object but not the texture
> even after the texture has been specified.
> 
> 
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.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

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. Ho
w 
> > 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 a
n 
> > 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 transformatio
n
> 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 transformati
on
> 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? 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. 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... What they frack do you think I have been saying? 
The only difference between your array and mine is that I separate 
"types" of transforms so you don't have to remember if the second 
translate is the 6th transform in the array, not the 5th. The point is 
to still track those transforms in an array of some type, so they can be 
reapplied, *if* you have to manage them that way. 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 (especially if its a 
compound object and things like "how" the texture is applied is changed 
dependent on the position of those sub-objects in some way, as a result 
of those transforms).

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.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> In article <4709fb43@news.povray.org>, war### [at] tagpovrayorg says...
>> Patrick Elliott <sel### [at] rraznet> wrote:
>>> If you have something like:
>>> #declare yy = clock
>>> sphere {...
>>>   translate <yy,35,61>
>>>   texture { some_complex_texture translate 100*x}
>>>   translate y*2}
>>> Then you **must** reparse the object every single time, because once the 
>>> object exists internally, it can't be changed.
>>   Wrong.
>>
>>   The object has its own transformation matrix and the texture its own.
>> All transformations applied to the object go to its transformation matrix,
>> and all transformations applied to the texture (be it directly in the
>> texture block or indirectly in the object block) go to the transformation
>> matrix of the texture.
>>   It would be perfectly possible to alter these two transformation matrices
>> afterwards. It's simply a question of which transformations are applied to
>> the object only, which ones to the texture only and which ones to both.
>>
>>> The 
>>> transforms you need to be able to change are "not" sitting conveniently 
>>> as the last thing in the object, they are buried deep within the 
>>> structure.
>>   You seem to have this concept that the transformations are somehow
>> stored in the definition of the object, and that this order must be
>> preserved.
>>
>>   The individual transformations are not stored anywhere. Each transformation
>> is simply a command (a kind of "function call" if you like) which modifies
>> the internal transformation matrix of the object.
>>
>>   It would be perfectly possible, after the object has been created (with
>> the transformations and all), to reset its transformation matrix and then
>> apply the same transformations to it, resulting in the exact same end
>> result. The only distinction you have to make is which transformations
>> go to the object, which ones to the texture and which ones to both.
>>
>>> If we want to be able to animate, without a reparse, we need 
>>> an internal representation that allows "each" transform, texture, 
>>> object, etc. to exist as accessible elements, not as static 
>>> declarations.
>>   No we don't.
>>
>>> In other words, you need to make it "look" like:
>>> yy = yy + 1
>>> mysphere.translate(0)=yy,35,61
>>> Even as the engine keeps track of "how" those things connect:
>>> start->translate(0)->texture(0)->translate(1)->end
>>   The engine doesn't need to keep track of that. You should acquaint
>> yourself with transformation matrices and how they work.
>>
>>> How else do you both allow animation, without a reparse, but also 
>>> maintain the capacity to place as many transforms, or other elements, 
>>> into the object as you can now?
>>   You can write a thousands individual transformations into an object,
>> yet none of them will be (individually) stored anywhere. They are all
>> applied to one single 4x4 transformation matrix. POV-Ray doesn't need
>> to keep track of the individual transformations nor store them anywhere.
>>
>>   The only thing you need to specify is whether a certain transformation
>> is applied to the object, to the texture, or both.
>>
>>> See what I am getting at? If you want to maintain the "existing" SDL, 
>>> you have to allow for this, or suffer the current consequence of having 
>>> to reparse the "entire" SDL every frame.
>>   That's just not true. The only thing you have to allow in the new SDL
>> is to be able to apply transformations to the object only, the texture
>> only or both at the same time. This is very trivial to do.
>>   It's perfectly possible to transform the object but not the texture
>> even after the texture has been specified.
>>
>>
> 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.
> 
I don't want interfere in your personal fight, but I think this is what 
is going to happen:
- POV4 transformations will be implemented the same as in current POV, 
one transformation matrix per object, texture.
- The language will be enhanced and the processing of it changed in such 
a way that retransforming one or more specific elements will become an 
issue. e.g. in generating the next frame of a complicated object without 
reparsing the lot.
- it'll be up to the user to implement a stack of transformations if he 
thinks he needs one. Reverting to a marked state and replaying the 
changed set of transformations from that point.
- luckily the language will be enhanced in such a way that such an 
implementation is easy.

Also before fighting on, you should first define what you mean by 
creation/post creation etc. I think you have a different view on when an 
object is actually created. Is that e.g at the end of the union defining 
it (Patrick?) or at the end of parsing (warp?).
If you assume the latter (which happens to be my point of view) post 
creation transforms do not exist, by definition. BTW I think the time of 
definition of the shape also needs a name (birth? though you will be 
able to clone after birth... conception?), because it is a significant 
moment in the life of that object. I predict that it'll come up in 
discussions about POV4 frequently.

Post a reply to this message

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 ...

POV has currently solution 1. Solution 2 appears in modelers by attaching
timelines to objects (is it be what we want for POV4?). What I have
understood in the discussion is that it would be preferable to have
something else than reparsing the scene. I made this quick analysis that
yields to 3 solutions. I think a unique solution must be chosen (among the
above 3 or others, please suggest ...). How could several approaches
co-exist without complicating the langage?

I believe that the new syntax must be close to the current, with somme OO
aspects (modules, inheritance, dot operator etc ...), with some higher
level object types (I put it as it comes):

cloudscape, vegetation, human and non human characters, clothing, particle
system, etc ... to be defined ... Please suggest!

And with new features:

sub-surface scattering, shader language (basic, medium, advanced? what would
it need and look like?), mesh-editing features (basic, medium, advanced?),
IK for characters, user-friendly math/geom programming tools (thanks to
gurus), etc ...

If we can achieve to define a language that keeps POV's SDL spirit, with the
nice new features you all talk about, it could be a high level
programming/scripting language for scene designers, as well as an interface
language for 3rd party tools.

POV's new GUI would be a shipped-with and integrated, with handy features,
for example:

text-editing (of course), basic/medium/advanced pre-visualization of shapes,
objects, textures etc ..., animation handling and previsualization,
spline/path editor, color editor, basic/medium mesh editor, proess control
.... etc ...


Bruno

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Patrick Elliott wrote:
> I don't want interfere in your personal fight, but I think this is what
> is going to happen:
> - POV4 transformations will be implemented the same as in current POV,
> one transformation matrix per object, texture.
> - The language will be enhanced and the processing of it changed in such
> a way that retransforming one or more specific elements will become an
> issue. e.g. in generating the next frame of a complicated object without
> reparsing the lot.

It is the Frame(n) = Frame(0) + Delta(tn) scheme, with Frame(0) representing
most of the parsing (initial conditions of the scene, building of objects
....), and Delta(tn) the variation of the scene since first frame. The
function Delta() can be expressed (and syntaxted) as timelines attached to
objects, handled by a corresponding control process. These time lines would
then embody the memory of the transformations to apply through time (the
'array' of transformations in question in the next paragraph)

> - it'll be up to the user to implement a stack of transformations if he
> thinks he needs one. Reverting to a marked state and replaying the
> changed set of transformations from that point.
> - luckily the language will be enhanced in such a way that such an
> implementation is easy.

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. In the scheme I described, only the control process
of timelines can do the job and guarantees sensible operations.

> Also before fighting on, you should first define what you mean by
> creation/post creation etc. I think you have a different view on when an
> object is actually created. Is that e.g at the end of the union defining
> it (Patrick?) or at the end of parsing (warp?).
> If you assume the latter (which happens to be my point of view) post
> creation transforms do not exist, by definition.

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,
unless controlled by the timelines attached to the objects and their control
process within aniations (and in this sole case).


> ... BTW I think the time of
> definition of the shape also needs a name (birth? though you will be
> able to clone after birth... conception?), because it is a significant
> moment in the life of that object. I predict that it'll come up in
> discussions about POV4 frequently.

As we try to make POV have some OO aspects, I'd rather be inclined to keep
the term of 'creation'.


Bruno

Post a reply to this message

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.

> 
> POV has currently solution 1. 
no, it reparses the scene for every frame.

Post a reply to this message

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.

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.


Bruno

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> 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.

  I don't really understand why you are seeing so many problems where
there is none.

  You have a created object. This object has been created at the beginning
of the animation and will stay as it is, in memory, during the entire
animation. It will not be reparsed nor recreated at each frame.

  What you do at each frame, however, is to apply certain transformations
(which depend on the clock, etc) to this object. I just can't see what is
the problem you are seeing there.

  For example, it could be like this, executed at each frame:

theObject.transformation.reset();
theObject.translate(1, 2, 3);
theObject.translate(4, 5, 6);
theObject.translate(.5*clock, .6*clock, .7*clock);
theObject.translate(10, 11, 12);

  Or anything else, for that matter (ie. it doesn't *necessarily* have to
start with a reset of the transformation matrix, but it may in most cases
be the easiest way).

  If you really want to have the transformations in an array, well,
you *can* create such an array if you want to. Just create the array,
and at each frame modify the elements of the array you want, and then
apply the transformations in the array to the object in a loop, and
that's it. That will be exactly what you want, without having to put
an odd transformation array kludge in the object itself.

> 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.

  1) There's no need to revert transformations.

  2) Even if there was, it *is* actually possible to revert transformations
regardless of how they depend on prior transformations and whatnot. Just
acquaint yourself with the subject.

> 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

  I already showed that you can.

> 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.

  You clearly don't understand how transformations work, and you are having
a big misconception about how transformations should be applied to objects
in this case.

-- 
                                                          - Warp

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> - it'll be up to the user to implement a stack of transformations if he 
> thinks he needs one. Reverting to a marked state and replaying the 
> changed set of transformations from that point.

  There's no need for any stack nor the need for reverting if you simply
apply a group of transformation commands to the object at each frame.

  It's basically not any different from how POV-Ray currently does it,
except that it's not necessary to reparse and recreate the object at
each frame. (In theory this wouldn't be necessary in the current POV-Ray
either, except that the current SDL format makes it quite difficult to
do it otherwise. A simple format enhancement would remove the limitation.)

> If you assume the latter (which happens to be my point of view) post 
> creation transforms do not exist, by definition.

  I don't really understand what you are saying there.

  I don't see any problem in taking an existing object and apply more
transformations to it, or even resetting its transformations and applying
new ones.

-- 
                                                          - Warp

Post a reply to this message