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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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

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

Warp a écrit :

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

Patrick Elliott escribió:
> 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

Bruno Cabasson escribió:
> 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

Patrick Elliott escribió:
> 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

Bruno Cabasson wrote:
> 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'.
> 
My point is that there are more than one moment where an object is 
'created'. The first time when is is fully constructed for the first 
time at some arbitrary point with its transform matrix fully reset. The 
final time is when the rendering starts at that point is has reached its 
final position, orientation and scale. In between there may be moments 
that it is repositioned (etc.) and included in a larger object, so that 
from the perspective of that object it is fully created but the compound 
can still be transformed. It might even be technically possible that the 
implementation would allow to reposition an object from within a shader 
program, but I would be against that.

What I was saying is that we should distinguish between the 'first 
creation' and the 'final creation'. Calling both simply 'creation' will 
  lead to confusion (as shown is this thread. Much of what you and 
Patrck are writing does not make sense to me, because for me 'creation' 
is 'final creation').

Post a reply to this message

Patrick Elliott nous apporta ses lumieres en ce 2007/10/08 17:58:
> 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? 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.
> 
There are NO list/array of transformations, just one and only one transform 
matrix that hold the CUMULATIVE result of every transformation thet was applied 
to your object. You always only apply ONE cumulative transform. Fast and effecient.
If you were to keep a list of transforms, it would be memory ineffecient and 
slow. You would have to always apply every transformations for every ray that 
encounter the object. Direct rays, refracted rays, reflected rays and shadow 
tests. You will also need to apply all of those listed transformations for any 
CSG operation you want to do with the transformed object(s). SLOW and ineffecient.

ALL object always have a texture, even if you don't provide one: There is 
something called a Default Texture. Any texture you supply replace the parts of 
that default texture with those you define. Any left over part remains that of 
the default.
If you apply the texture before the transform, then the transform also apply to 
the texture, and you can considere the texture as "part" of the object.
If you apply the transform before you apply the texture, that transform don't 
apply to the texture. If you apply another transformation, then that last 
transformation will also apply to the texture. The texture is still an integral 
part of the object.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you can recite your high school 
Trig book from memory.

Post a reply to this message

In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> 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 mat
rix,
> >> and all transformations applied to the texture (be it directly in the
> >> texture block or indirectly in the object block) go to the transformat
ion
> >> matrix of the texture.
> >>   It would be perfectly possible to alter these two transformation mat
rices
> >> afterwards. It's simply a question of which transformations are applie
d 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 convenient
ly 
> >>> 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 transfo
rmation
> >> is simply a command (a kind of "function call" if you like) which modi
fies
> >> the internal transformation matrix of the object.
> >>
> >>   It would be perfectly possible, after the object has been created (w
ith
> >> the transformations and all), to reset its transformation matrix and t
hen
> >> 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 anywher
e.
> >>
> >>   The only thing you need to specify is whether a certain transformati
on
> >> 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 havi
ng 
> >>> to reparse the "entire" SDL every frame.
> >>   That's just not true. The only thing you have to allow in the new SD
L
> >> 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 positionin
g 
> > 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 transform
s 
> > in the first place, and reducing them to a bare minimum number needed t
o 
> > do the task. Sure, it might be possible, but it still breaks, as near a
s 
> > 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.
> 
Well, in any language that would allow parsing, then animation 
"internally", without a reparse, its *both*. I.e., you instance a 
complete object on the first "pass" if you will, much as you would 
compile a language. Once this is done, code execution, and any changes 
to the object "allowed" in that context, can still happen, but the 
"objects" are now static in all other respects. In other words, you 
never really stop parsing, in the sense of executing branching, loops or 
other commands that have an affect on the objects, but you also 
*don't/can't* do the equivalent of arbitrarily changing the parameters 
of an object that has already been created, any more than you can do the 
following in any compiled/JIT type language:

sub blah(a, b, c)
  'do stuff
end sub

sub blah(a)
  'do something completely different.
end sub

call blah(1, 2, 3)

At best, you are going to get an error just trying to redefine the same 
function, at worst, if the language allowed it, you would redefine it to 
the later version, and you would get an error due to the parameters 
being wrong. You are thus **not** generally allowed to do that. Same 
with an object. So, what I am looking at is something like a JIT compile 
of the script. Objects get defined *once*, then from then on you make 
changes to *that* object. No reparsing happens, because the *script* 
executes like any other JIT. You can change variables, etc., within 
limits, or even attributes of the object **if** some method exists for 
getting at them, but you can't reparse the object all over again to 
remake it for the next frame, you have to take what *exists* and change 
what parameters are "allowed" at that point. The problem is, if getting 
it to that point requires 5-6 interlocked transforms *before* the one 
you plan to make changes to in the next frame, you need some way to make 
sure it is in that state "before" making that transform, then you also 
have to make sure any additional transforms that happen "after" that 
point also take place, and in the right order. The alternative is to do 
them all after the fact, which shoots huge holes in any attempt to make 
it object oriented, or you have to deny the ability to make multiple 
transforms on objects or their sub-objects, as you are currently able 
to.

The only other solution I could see would be the "mark" the transforms 
you "want" to be able to change later, then only allow access to those. 
So, in that case, every transform up to that point becomes the objects 
"default" state, to which your change is applied. That still doesn't 
solve the problem, because then it also has to remember and reapply any 
additional state changes that need to happen "after" that as well. All 
you end up doing is decreasing the number of state changes you have to 
track, without actually changing the problem.

Finally, if you do keep an array of all the transforms applied to a 
specific object, to be replayed, then why not keep them in a list *on* 
the object, where it makes sense, instead of in a separate array/table, 
which has no obvious connection to the original object at all? And 
then.. I am not sure what POVRay does in such cases, but what happens if 
you do something like:

union {
  object1
  object2
  scale .5
  object3
}

Does it transform all three, or the first two, *then* union the third? 
If the later, then you have a huge problem because no list of transforms 
"can" produce the same result, unless you also replay the exact process 
of instancing the objects in the union as well. I would hope that it 
deals with it as one complete object, instead of changing the size of 
the first two, then adding the third. That would make is possible to 
simply apply a list of transforms. If it doesn't work that way though, 
then the objects themselves become strongly dependent on the order of 
operations as well.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470b5016@news.povray.org>, war### [at] tagpovrayorg says...
> 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 programm
ing
> > ease and accessibility.
> 
>   There's no more skill involved than in the current POV-Ray when you app
ly
> 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 repars
e
> 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 SD
L
> 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 transformatio
n
> 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 b
e
> > defined at creation time, and post creation transforms should be forbid
den
> 
>   Why impose such an artificial limitation? It doesn't make any sense.
> 
I think we are talking past each other here in some respects. Yeah, I 
agree, if they work in the sense that they should, i.e., scaling 
"before" defining the last object in a union also scales "that" object, 
not just the prior ones, then applying all transforms "after" is 
perfectly valid. It doesn't fundamentally change my argument, which is 
that, "If you are going to store that stuff in an array, lets at least 
assign the array to something that "looks" like its part of the object, 
and not some separate entity." In other words, if you are going to apply 
10 transforms to object Z, then *make that array* part of the Z object, 
*at least* from the perspective of the coder. That way you can tell 
"what" they belong to by simply referencing the object they belong to, 
not some arbitrary array that has no association, save that you just 
happen to use it for that.

Or is there some huge objection to making it even than simplified?

Oh, and the idea of placing each "type" of transform into a separate 
array is more like a filter. I.e., you want to change the 3rd "scale", 
just reference the 3rd scale in the array, even if it is "actually" the 
7th transform. This doesn't even need to be a separate array, just a 
function call that counts the transforms in the main array, until it 
gets the "nth" transform of the type requested. In other words, 
something like:

function translate(n)
  c = -1
  for each temp in self.transforms
    if type(temp) = "translate" then
      c = c + 1
    end if
  next
  if c > -1 then
    return c
  else
    return -1
  end if
end function

"transforms" being the "array" that is used to track "all" transforms 
applied to that object in the original SDL step that created it, which 
would be identical to the existing SDL. This doesn't prevent you adding 
new transforms, either via the existing SDL method, or via the object 
reference, or even *deleting* one that was previously applied (which 
isn't currently possible).

Hope that is clearer.

-- 
void main () {
  If Schrödingers_cat is alive  
    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:
> that, "If you are going to store that stuff in an array, lets at least 
> assign the array to something that "looks" like its part of the object, 
> and not some separate entity." In other words, if you are going to apply 
> 10 transforms to object Z, then *make that array* part of the Z object, 
> *at least* from the perspective of the coder.

Why not just allow arrays that can be indexed by objects? Then you can 
have multiple arrays of transformations per object. You could have a 
"walking" array, indexed by body part, where each element is an array of 
transforms to be applied at each step of the walk cycle, then a 
"running" array indexed by body parts ....

Walking gets
object arm = cylinder(....)
object leg = blob(...)
translate(arm, walk[arm].translates[frame % 6])
rotate(arm, walk[arm].rotates[frame % 6])
translate(leg, walk[leg].mytranslate[frame % 6])

Running gets
object arm = cylinder(....)
object leg = blob(...)
translate(arm, run[arm].translates[frame % 6])
rotate(arm, run[arm].rotates[frame % 6])
translate(leg, run[leg].translates[frame % 6])

 > That way you can tell
> "what" they belong to by simply referencing the object they belong to, 
> not some arbitrary array that has no association, save that you just 
> happen to use it for that.

Arbitrary associations is the meat of programming. There's no real 
reason that a translation "belongs" more to an object than to an 
animation cycle than to a room of the house you're modeling.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Patrick Elliott nous apporta ses lumieres en ce 2007/10/10 01:42:

> I think we are talking past each other here in some respects. Yeah, I 
> agree, if they work in the sense that they should, i.e., scaling 
> "before" defining the last object in a union also scales "that" object, 
That's not a valid syntax and generate an error at the next object encountered.
You can transform any individual element.
You can transform the whole CSG object, but ONLY after every last one of it's 
elements have been included.
> not just the prior ones, then applying all transforms "after" is 
> perfectly valid. It doesn't fundamentally change my argument, which is 
> that, "If you are going to store that stuff in an array, lets at least 
> assign the array to something that "looks" like its part of the object, 
> and not some separate entity." In other words, if you are going to apply 
> 10 transforms to object Z, then *make that array* part of the Z object, 
> *at least* from the perspective of the coder. That way you can tell 
> "what" they belong to by simply referencing the object they belong to, 
> not some arbitrary array that has no association, save that you just 
> happen to use it for that.
> 
> Or is there some huge objection to making it even than simplified?
> 
> Oh, and the idea of placing each "type" of transform into a separate 
> array is more like a filter. I.e., you want to change the 3rd "scale", 
> just reference the 3rd scale in the array, even if it is "actually" the 
> 7th transform. This doesn't even need to be a separate array, just a 
> function call that counts the transforms in the main array, until it 
> gets the "nth" transform of the type requested. In other words, 
> something like:
> 
> function translate(n)
>   c = -1
>   for each temp in self.transforms
>     if type(temp) = "translate" then
>       c = c + 1
>     end if
>   next
>   if c > -1 then
>     return c
>   else
>     return -1
>   end if
> end function
> 
> "transforms" being the "array" that is used to track "all" transforms 
> applied to that object in the original SDL step that created it, which 
> would be identical to the existing SDL. This doesn't prevent you adding 
> new transforms, either via the existing SDL method, or via the object 
> reference, or even *deleting* one that was previously applied (which 
> isn't currently possible).
> 
> Hope that is clearer.
> 
You obviously miss a fundamental point: there is only ONE transform matrix per 
object that contain the SUMATION of every single transforms applyed to that 
object. There is no transform array, there never was any such thing.
Using an array of transforms would be wastefull. It would uselessly use extra 
memory. It would make rendering slow as the whole array will need to be computed 
for every ray that encounter the object, as well as any CSG operation that use 
that object. That array will need to be dynamic as you can never tell beforehand 
how many transforms will be applyed to any particular object, adding some 
useless overhead, and requiring still more memory.

-- 
Alain
-------------------------------------------------
Don't waste your time on a man/woman, who isn't willing to waste their time on you.

Post a reply to this message

Alain wrote:
> You obviously miss a fundamental point: there is only ONE transform 
> matrix per object that contain the SUMATION of every single transforms 
> applyed to that object. There is no transform array, there never was any 
> such thing.

I'm amazed at the number of people arguing
"This is how the next one should be."
"No, this is how the current one is."
"But this is how the *next* one should be."
"Don't you understand this is how the current one *is*?"

> Using an array of transforms would be wastefull. It would uselessly use 
> extra memory.

It's only useless if you don't need it.

> It would make rendering slow as the whole array will need 
> to be computed for every ray that encounter the object, 

Nonesense. Once the tracing starts, you compute the final transformation 
matrix, just like you do now when there are multiple transforms.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:470cf833$1@news.povray.org...
> Alain wrote:
>> You obviously miss a fundamental point: there is only ONE transform 
>> matrix per object that contain the SUMATION of every single transforms 
>> applyed to that object. There is no transform array, there never was any 
>> such thing.
>
> I'm amazed at the number of people arguing
> "This is how the next one should be."
> "No, this is how the current one is."
> "But this is how the *next* one should be."
> "Don't you understand this is how the current one *is*?"

that's not how it is, it's more like this:

"This is how the next one should be."
"No, this is how the current one is, and there's absolutely no reason why 
that particular part should change."
"But this is how the *next* one should be."
"You really don't understand why the current one is the way it is, do you?"

If you ask me, keeping an array of transformations makes it all needlessly 
complicated. If you want such an array, define it yourself in SDL, there's 
absolutely no need for it in the POV-core.

In my opinion, the main idea of the new SDL should be to seperate the 
core-functionality from the user-definable functionality.  At the very base 
of the rendering-process, having an array of transformations is simply 
ridiculous.  If users want such an array, then I'm sure someone will write 
an inc-file (or whatever) that makes this possible and even easy to do.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> What I was saying is that we should distinguish between the 'first 
> creation' and the 'final creation'. Calling both simply 'creation' will
 
>   lead to confusion (as shown is this thread. Much of what you and 
> Patrck are writing does not make sense to me, because for me 'creation'
 
> is 'final creation').
> 
How about "intermediary" creations then, just to confuse things more. 
lol Technically, by your definition, the object is never "created" until 
the frame in rendered, at least in any system like we are talking about, 
where each "frame" is defined not by re-running the entire script, but 
only via the command "in" the script.

In other words, in the current model we do this:

render("myfile")

in a true animation system, we do this:

'Set up a bunch of objects.
...
render
'Change the objects some.
...
render
'Change them some more.
...
render

The "render" step is explicit in the script, since it only happens 
"when" all the changes are made, not an external process that just runs 
an SDL through it, and recalcs the data for everything as it does it, 
based on the existing clock scheme, which is kind of limited. Mind you, 
making that change, depending on how it was done, could break existing 
SDL. Mind you, a command that "requests" the prior behavior could be 
used to solve that. Note, allowing a "render" command to explicitly tell 
it when you are ready to render the result means you could simply do:

light {...}
camera {...}
plane {...}
object1 {...}
render
object2 {...}
render
...

And produce a frame by frame set of changes. Could be useful for 
debugging too. Not sure what is causing a problem, go through one object 
at a time, until you find a frame where the problem crops up.

Note: Obviously one thing you can do with this is make the "render" 
command do several things. If you haven't set any animation/clock 
parameters, then it generates the same name each time. If you have set 
them, it increments a frame count each time you use it, while also 
incrementing the clock by the predefined amount. Obviously, to limit the 
need for the definition files currently used, since you might want 
better control over things, you would want clock data 
accessable/changable via something like:

clock.state - on/off
clock.start_frame
clock.frame
clock.end_frame
clock.increment

Same possibly even with things like the render size, etc.

You could conceivably even allow "render" to also allow "render
(frame_number, fill)". I.e., if you want to freeze frame, instead of 
generating 10 identical frames you just change the "frame" you are on, 
then specific that everything between "last frame" and "current frame" 
gets filled with the last rendered image.

Mind you this could be done, in *some* software by just telling that to 
duplicated those frames, but not all of them will do that, and if at 
some point someone added a stream encoder to POVRay, being able to 
explicitly tell it that frames 5-15 are duplicates would speed up the 
process of both generating those frames "and" encoding them, the encoder 
could just be told, by the engine, to encode the same "frame" ten times, 
at the frame rate it was already given. No additional "data" need be 
produced.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470ced0a$1@news.povray.org>, ele### [at] netscapenet 
says...
> Patrick Elliott nous apporta ses lumieres en ce 2007/10/10 01:42:
> 
> > I think we are talking past each other here in some respects. Yeah, I
 
> > agree, if they work in the sense that they should, i.e., scaling 
> > "before" defining the last object in a union also scales "that" object,
 
> That's not a valid syntax and generate an error at the next object encoun
tered.
> You can transform any individual element.
> You can transform the whole CSG object, but ONLY after every last one of 
it's 
> elements have been included.
> > not just the prior ones, then applying all transforms "after" is 
> > perfectly valid. It doesn't fundamentally change my argument, which is
 
> > that, "If you are going to store that stuff in an array, lets at least
 
> > assign the array to something that "looks" like its part of the object,
 
> > and not some separate entity." In other words, if you are going to appl
y 
> > 10 transforms to object Z, then *make that array* part of the Z object,
 
> > *at least* from the perspective of the coder. That way you can tell 
> > "what" they belong to by simply referencing the object they belong to,
 
> > not some arbitrary array that has no association, save that you just 
> > happen to use it for that.
> > 
> > Or is there some huge objection to making it even than simplified?
> > 
> > Oh, and the idea of placing each "type" of transform into a separate 
> > array is more like a filter. I.e., you want to change the 3rd "scale",
 
> > just reference the 3rd scale in the array, even if it is "actually" the
 
> > 7th transform. This doesn't even need to be a separate array, just a 
> > function call that counts the transforms in the main array, until it 
> > gets the "nth" transform of the type requested. In other words, 
> > something like:
> > 
> > function translate(n)
> >   c = -1
> >   for each temp in self.transforms
> >     if type(temp) = "translate" then
> >       c = c + 1
> >     end if
> >   next
> >   if c > -1 then
> >     return c
> >   else
> >     return -1
> >   end if
> > end function
> > 
> > "transforms" being the "array" that is used to track "all" transforms
 
> > applied to that object in the original SDL step that created it, which
 
> > would be identical to the existing SDL. This doesn't prevent you adding
 
> > new transforms, either via the existing SDL method, or via the object
 
> > reference, or even *deleting* one that was previously applied (which 
> > isn't currently possible).
> > 
> > Hope that is clearer.
> > 
> You obviously miss a fundamental point: there is only ONE transform matri
x per 
> object that contain the SUMATION of every single transforms applyed to th
at 
> object. There is no transform array, there never was any such thing.
> Using an array of transforms would be wastefull. It would uselessly use e
xtra 
> memory. It would make rendering slow as the whole array will need to be c
omputed 
> for every ray that encounter the object, as well as any CSG operation tha
t use 
> that object. That array will need to be dynamic as you can never tell bef
orehand 
> how many transforms will be applyed to any particular object, adding some
 
> useless overhead, and requiring still more memory.
> 
And you are missing the point that you can't functionally work things 
that way in animation. Lets put it any other way, you have a matrix:

|0 0 0 1|
|4 3 1 0|
|1 0 2 3|
|5 2 3 0|

Or something, this is just random made up, but it serves the point. 
Where in that matrix is the "rotate this after moving it to point X, so 
that it acts like an arm, instead of rotating at the object center"? 
Even if you revert, you **still** have to then move it to the point on 
the object needed to rotate it, before also doing what ever else you 
need to make it work right. The fact that the cumulative matrix contains 
everything done to that point is ****meaningless**** from the standpoint 
of animation, because when animating you don't give a frack what the 
"final" result is, you want to render based on intermediary results, 
which changes that matrix "for every frame". If you revert it, you still 
have to keep track of what transforms you did, and in what order, so 
that you get the right matrix, which means you are **still** using up 
the memory to keep track of them in some fashion, while your seem to 
imagine that you can just wave a magic wand and have the memory issue go 
away. Either way, you have to reapply all the transforms "in each 
frame". I don't see how storing those in something that references them 
as part of the object they belong to does "anything" to change how much 
memory ends up being used.

Basically, you are still thinking in terms of a script that goes through 
in one pass, producing one "single" final result, which has to be 
rebuilt in the next frame. All objects in a script that doesn't reparse 
"never" reach that "complete" state you are going on about, they are in 
continual transition, so its not possible to just generate a static 
matrix, which automatically solves every problem. You still have to 
change that matrix in a way that produces the result you want, which 
isn't practical if you are working with an already transformed objects, 
which has multiple changes to the matrix, all of them interdependent on 
each other. And, even if you are right, I have yet to see you provide 
any example to prove either of us discussing the issue from our side of 
the line with proof that you are right and we don't get it. In fact, the 
only solution you can come up with is basically the same thing we are 
already saying, just separated from the object.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470cecd7@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > that, "If you are going to store that stuff in an array, lets at least
 
> > assign the array to something that "looks" like its part of the object,
 
> > and not some separate entity." In other words, if you are going to appl
y 
> > 10 transforms to object Z, then *make that array* part of the Z object,
 
> > *at least* from the perspective of the coder.
> 
> Why not just allow arrays that can be indexed by objects? Then you can 
> have multiple arrays of transformations per object. You could have a 
> "walking" array, indexed by body part, where each element is an array of
 
> transforms to be applied at each step of the walk cycle, then a 
> "running" array indexed by body parts ....
> 
> Walking gets
> object arm = cylinder(....)
> object leg = blob(...)
> translate(arm, walk[arm].translates[frame % 6])
> rotate(arm, walk[arm].rotates[frame % 6])
> translate(leg, walk[leg].mytranslate[frame % 6])
> 
> Running gets
> object arm = cylinder(....)
> object leg = blob(...)
> translate(arm, run[arm].translates[frame % 6])
> rotate(arm, run[arm].rotates[frame % 6])
> translate(leg, run[leg].translates[frame % 6])
> 
Umm. Because it doesn't make much sense? Seriously, any such transforms 
are going to be "very" specific to the IK chain of the particular object 
you are working with. There is no point in making an array called 
"walk", which contains the needed transforms, instead of making it part 
of the object, because logically it can't be applied to any "other" 
objects. The only argument that could be made is that you might want 50 
marching robots, which all move the same way. If you plan to add any 
sort of variability in their motion though, you run into the same 
problem, no single set of transforms will be applicable to "every" IK 
chain in those 50, so trying to apply the same one to all of them won't 
work.

This does present an issue though. Its true that storing these "will" 
hog memory. The simplest solution is to store a master list, which 
includes calls to a function that can vary the motion, dependent on the 
objects ID, of some sort. In other words, instead of storing something 
like: arm.transform(6)="rotate <4,5,3>", you store arm.transform(6)
="rotate <calc_angle(self.ID),5,3>", where calc_angle would get the 
"frame" number from the animation object, check the ID, then figure out 
what its supposed to do from that.

In a sense, when rendering, no object ever "completes" its creation 
cycle until the final parse happens. All objects exist, with "blank" 
transform matrices, **until** you call "render" at which point the 
"script" inside the array is played out for each level, starting at the 
deepest, until a final matrix for each object is completed, *then* the 
render happens. I don't see how else you handle it and *still* preserve 
the current SDL model. You can't simply revert, without replaying the 
transforms anyway, nor can you just toss a new one in, and hope that 
somehow the engine will produce the result you wanted. You have to delay 
final creation "until" you inform the engine that you want it to render 
the result.

Again, as with my prior post on that, a scene marked to use the "old" 
behavior wouldn't do that, it would complete, then render. In a scripted 
animation though, "complete" when talking about the state of an object 
is either referring to one where the types and number of transforms are 
"intentionally" limited, or its a real fuzzy concept, at best. lol

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470cf833$1@news.povray.org>, dne### [at] sanrrcom says...
> Alain wrote:
> > You obviously miss a fundamental point: there is only ONE transform 
> > matrix per object that contain the SUMATION of every single transforms
 
> > applyed to that object. There is no transform array, there never was an
y 
> > such thing.
> 
> I'm amazed at the number of people arguing
> "This is how the next one should be."
> "No, this is how the current one is."
> "But this is how the *next* one should be."
> "Don't you understand this is how the current one *is*?"
> 
> > Using an array of transforms would be wastefull. It would uselessly use
 
> > extra memory.
> 
> It's only useless if you don't need it.
> 
> > It would make rendering slow as the whole array will need 
> > to be computed for every ray that encounter the object, 
> 
> Nonesense. Once the tracing starts, you compute the final transformation
 
> matrix, just like you do now when there are multiple transforms.
> 
> 
Thank you. A force of reason. lol

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470d186a$1@news.povray.org>, zeg### [at] povplacecom 
says...
> "Darren New" <dne### [at] sanrrcom> wrote in message 
> news:470cf833$1@news.povray.org...
> > Alain wrote:
> >> You obviously miss a fundamental point: there is only ONE transform 
> >> matrix per object that contain the SUMATION of every single transforms
 
> >> applyed to that object. There is no transform array, there never was a
ny 
> >> such thing.
> >
> > I'm amazed at the number of people arguing
> > "This is how the next one should be."
> > "No, this is how the current one is."
> > "But this is how the *next* one should be."
> > "Don't you understand this is how the current one *is*?"
> 
> that's not how it is, it's more like this:
> 
> "This is how the next one should be."
> "No, this is how the current one is, and there's absolutely no reason why
 
> that particular part should change."
> "But this is how the *next* one should be."
> "You really don't understand why the current one is the way it is, do you
?"
> 
> If you ask me, keeping an array of transformations makes it all needlessl
y 
> complicated. If you want such an array, define it yourself in SDL, there'
s 
> absolutely no need for it in the POV-core.
> 
> In my opinion, the main idea of the new SDL should be to seperate the 
> core-functionality from the user-definable functionality.  At the very ba
se 
> of the rendering-process, having an array of transformations is simply 
> ridiculous.  If users want such an array, then I'm sure someone will writ
e 
> an inc-file (or whatever) that makes this possible and even easy to do.
> 
> cu!
> 
Your seriously missing the point. Sure, you could just create an array, 
but we are looking at how you A) maintain the syntax while B) also 
supporting **real** animation and flexibility in a new SDL. Lets put it 
simpler. Right now, if you used SDL like the following certain things 
will happen:

object {
  foot{some_transforms}
  low_leg{some_transforms}
  top_leg{some_transforms}
  some_transforms
}

The parser is going to "immediately" perform each transform 
"statically" to each sub object, then to the final one, parse the rest 
of the script, then render. You *can't* do it that way in a SDL/script 
that doesn't exit, it has to be able to handle the "final" creation 
"just before" the render, so you can make changes from frame to frame, 
without reparsing the entire file. What I would be proposing is:

object {
  foot{some_transforms} // Object created, transforms stored in 
foot.transforms.
  low_leg{some_transforms} // Object created, transforms stored in 
low_leg.transforms.
  top_leg{some_transforms} // Object created, transforms stored in 
top_leg.transforms.
  some_transforms //Final transforms still stored, since they may 
contain things "dependent" on function calls or variables, which may 
change.
}
 // Transform functions stepped through for every object, generating 
**this** frames transformation matrices, then the engine renders the 
result.
render
top_leg.transform(2)="rotate <5,0,0>" // Change position of the leg.
// Again, the matrices are created for "this" frame, then rendered.
render

Mind you, a good system will also flag object that do change between 
frames, so only those objects that "need" to have there matrix 
recalculated have it done. Noting too that those containing "variables" 
instead of specific locations must always be recalculated (since the 
variables could change). That won't slow things down, it will bloody 
speed them up, for all objects that don't have "calculated" rotations, 
translations, etc., since the last thing you want to do is recalculate 
the transform matrix for 500 static objects that "don't move" between 
one frame and the next, if all you want to do is make the robot take a 
step. The current SDL has to recalculate ***every*** matrix for 
***every*** frame. Memory be damned. Yes, it "might" take more, 
depending on if some shortcut does/doesn't exist to help avoid that 
issue, but you can't fix the limitation that exists in how the current 
SDL works by pretending it doesn't exist at all, or that you can fix it 
by without changing how the parser/engine works.

-- 
void main () {
  If Schrödingers_cat is alive  
    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:

>> 
> And you are missing the point that you can't functionally work things
> that way in animation. Lets put it any other way, you have a matrix:
> 
> |0 0 0 1|
> |4 3 1 0|
> |1 0 2 3|
> |5 2 3 0|
> 
> Or something, this is just random made up, but it serves the point.
> Where in that matrix is the "rotate this after moving it to point X, so
> that it acts like an arm, instead of rotating at the object center"?
> Even if you revert, you **still** have to then move it to the point on
> the object needed to rotate it, before also doing what ever else you
> need to make it work right. The fact that the cumulative matrix contains
> everything done to that point is ****meaningless**** from the standpoint
> of animation, because when animating you don't give a frack what the
> "final" result is, you want to render based on intermediary results,
> which changes that matrix "for every frame". If you revert it, you still
> have to keep track of what transforms you did, and in what order, so
> that you get the right matrix, which means you are **still** using up
> the memory to keep track of them in some fashion, while your seem to
> imagine that you can just wave a magic wand and have the memory issue go
> away. Either way, you have to reapply all the transforms "in each
> frame". I don't see how storing those in something that references them
> as part of the object they belong to does "anything" to change how much
> memory ends up being used.
> 
> Basically, you are still thinking in terms of a script that goes through
> in one pass, producing one "single" final result, which has to be
> rebuilt in the next frame. All objects in a script that doesn't reparse
> "never" reach that "complete" state you are going on about, they are in
> continual transition, so its not possible to just generate a static
> matrix, which automatically solves every problem. You still have to
> change that matrix in a way that produces the result you want, which
> isn't practical if you are working with an already transformed objects,
> which has multiple changes to the matrix, all of them interdependent on
> each other. And, even if you are right, I have yet to see you provide
> any example to prove either of us discussing the issue from our side of
> the line with proof that you are right and we don't get it. In fact, the
> only solution you can come up with is basically the same thing we are
> already saying, just separated from the object.
> 

I'm not all that technical as far as Povray goes, but I have made quite a
few animations of robot arms (industrial ones) with multiple joints and
tools. I never had a need for an array of transformations but always
applied transforms "from the hand back".
Sorry, can't show any code here but it's basically something like :
object { Hand rotate x * Something }
object { Wrist rotate z * SomethingElse }
object { LowerArm rotate z * AnotherSomething }
object { UpperArm rotate z * AnotherSomethingTo }
object { Shoulder rotate z * JetMoreSomething }
object { Base rotate y * Avalue }

In the end the Hand object goes through a bunch of transforms that will put
it where I want it
-- 
Ger

Post a reply to this message

Patrick Elliott a écrit :

> Or something, this is just random made up, but it serves the point. 
> Where in that matrix is the "rotate this after moving it to point X, so 
> that it acts like an arm, instead of rotating at the object center"? 
> Even if you revert, you **still** have to then move it to the point on 
> the object needed to rotate it, before also doing what ever else you 
> need to make it work right. The fact that the cumulative matrix contains 
> everything done to that point is ****meaningless**** from the standpoint 
> of animation, because when animating you don't give a frack what the 
> "final" result is, you want to render based on intermediary results, 
> which changes that matrix "for every frame". If you revert it, you still 
> have to keep track of what transforms you did, and in what order, so 
> that you get the right matrix, which means you are **still** using up 
> the memory to keep track of them in some fashion, while your seem to 
> imagine that you can just wave a magic wand and have the memory issue go 
> away. Either way, you have to reapply all the transforms "in each 
> frame". I don't see how storing those in something that references them 
> as part of the object they belong to does "anything" to change how much 
> memory ends up being used.

But this could be handled in SDL, no ?  Keeping track of every
transform, and having a directive to indicate what should be
reparsed and what shouldn't...

Fabien.

Post a reply to this message

Patrick Elliott wrote:
> Umm. Because it doesn't make much sense? Seriously, any such transforms 
> are going to be "very" specific to the IK chain of the particular object 
> you are working with. There is no point in making an array called 
> "walk", which contains the needed transforms, instead of making it part 
> of the object, because logically it can't be applied to any "other" 
> objects.

Errr, well, have you used Hash Animation Master? As long as you name the 
bones the same there, you can apply the "walk" to anything you want.

However, you missed my point, which was that if the array is separate 
from the object, you can have multiple arrays and hence multiple sets of 
transformations that apply to the object at different times in the 
animation.  If the character walks a while, then runs a while, do you 
put the walk transformations or the run transformations in the object?
If the array can be indexed by the object itself, then there's no 
question in the code of the transformation being "off separate" 
somewhere that's hard to find.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Patrick Elliott wrote:
> In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
> says...
>> What I was saying is that we should distinguish between the 'first 
>> creation' and the 'final creation'. Calling both simply 'creation' will 
>>   lead to confusion (as shown is this thread. Much of what you and 
>> Patrck are writing does not make sense to me, because for me 'creation' 
>> is 'final creation').
>>
> How about "intermediary" creations then, just to confuse things more. 
> lol Technically, by your definition, the object is never "created" until 
> the frame in rendered, at least in any system like we are talking about, 
> where each "frame" is defined not by re-running the entire script, but 
> only via the command "in" the script.
> 
> In other words, in the current model we do this:
> 
> render("myfile")
> 
> in a true animation system, we do this:
> 
> 'Set up a bunch of objects.
> ...
> render
> 'Change the objects some.
> ...
> render
> 'Change them some more.
> ...
> render
> 
> The "render" step is explicit in the script, since it only happens 
> "when" all the changes are made, not an external process that just runs 
> an SDL through it, and recalcs the data for everything as it does it, 
> based on the existing clock scheme, which is kind of limited. Mind you, 
> making that change, depending on how it was done, could break existing 
> SDL. Mind you, a command that "requests" the prior behavior could be 
> used to solve that. 

You could also assume that a render command is implicit at the end of 
parsing if none is given.


Note, allowing a "render" command to explicitly tell
> it when you are ready to render the result means you could simply do:
> 
> light {...}
> camera {...}
> plane {...}
> object1 {...}
> render
> object2 {...}
> render
> ...
> 
> And produce a frame by frame set of changes. Could be useful for 
> debugging too. Not sure what is causing a problem, go through one object 
> at a time, until you find a frame where the problem crops up.
> 
> Note: Obviously one thing you can do with this is make the "render" 
> command do several things. If you haven't set any animation/clock 
> parameters, then it generates the same name each time. If you have set 
> them, it increments a frame count each time you use it, while also 
> incrementing the clock by the predefined amount. Obviously, to limit the 
> need for the definition files currently used, since you might want 
> better control over things, you would want clock data 
> accessable/changable via something like:
> 
> clock.state - on/off
> clock.start_frame
> clock.frame
> clock.end_frame
> clock.increment
> 
> Same possibly even with things like the render size, etc.
> 
> You could conceivably even allow "render" to also allow "render
> (frame_number, fill)". I.e., if you want to freeze frame, instead of 
> generating 10 identical frames you just change the "frame" you are on, 
> then specific that everything between "last frame" and "current frame" 
> gets filled with the last rendered image.
> 
> Mind you this could be done, in *some* software by just telling that to 
> duplicated those frames, but not all of them will do that, and if at 
> some point someone added a stream encoder to POVRay, being able to 
> explicitly tell it that frames 5-15 are duplicates would speed up the 
> process of both generating those frames "and" encoding them, the encoder 
> could just be told, by the engine, to encode the same "frame" ten times, 
> at the frame rate it was already given. No additional "data" need be 
> produced.
>

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > It would make rendering slow as the whole array will need 
> > to be computed for every ray that encounter the object, 

> Nonesense. Once the tracing starts, you compute the final transformation 
> matrix, just like you do now when there are multiple transforms.

  It's not a question of efficiency, it's a question of not hard-coding
one specific solution where no such hard-coding is necessary at all.

  (Besides, it *is* a question of efficiency too: Those arrays will
consume extra memory which is not necessary to be consumed. This may
become an issue with millions of objects.)

-- 
                                                          - Warp

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> But this could be handled in SDL, no ?

  The main problem is that this "store all transformations in an array
inside the object" is a hard-coded solution which makes no sense. It
needlessly fixes this "problem" (which really isn't a problem at all,
which is something they just cannot seem to comprehend) with one single
hard-coded solution. If someone would like to use a different approach
then the internal array would be a completely useless waste of memory.

  Let's assume someone is implementing something where he really wants,
for whatever reason, to store all the individual transformations in a
data structure (instead of simply executing a series of commands which
will accumulate the transformations into a single transformation matrix).
What happens if the data structure he wants to use is a list? What if he
wants to have *several* data structures containing alternative sets of
transformations? What if he wants the transformations in a binary tree?
He will have to implement these solutions in SDL, and the transformation
array inside the object will be a useless waste of memory.

  Moreover: What if, which will be the usual case, he doesn't need to
store the individual transformations anywhere? Who is going to give him
back the memory wasted by the useless internal transformation array?

  The right solution is to be able, at each frame, to apply a set of
transformations to the object as function calls (which syntax is to
be decided). Internally these transformations will work as currently
in POV-Ray (ie. they are accumulated into a transformation matrix).

  If someone really wants to use an array to store individual transformations
then he can do so. However, most importantly, he is not *forced* to do so
if he doesn't want to.

-- 
                                                          - Warp

Post a reply to this message

Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> But this could be handled in SDL, no ?
> 
>   The main problem is that this "store all transformations in an array
> inside the object" is a hard-coded solution which makes no sense. It
> needlessly fixes this "problem" (which really isn't a problem at all,
> which is something they just cannot seem to comprehend) with one single
> hard-coded solution. If someone would like to use a different approach
> then the internal array would be a completely useless waste of memory.
> 
>   Let's assume someone is implementing something where he really wants,
> for whatever reason, to store all the individual transformations in a
> data structure (instead of simply executing a series of commands which
> will accumulate the transformations into a single transformation matrix).
> What happens if the data structure he wants to use is a list? What if he
> wants to have *several* data structures containing alternative sets of
> transformations? What if he wants the transformations in a binary tree?
> He will have to implement these solutions in SDL, and the transformation
> array inside the object will be a useless waste of memory.

That's what I meant : implement the "transformation history" using SDL.

If the SDL is powerful enough, it could even be automatic : each time
something tranforms an object, an "event" mechanism adds the transform
to the history.

Objects could even have some kind of "extended data" that could be attached
to them, and be used as the user wishes. (it would help things like
parent-chlid relations between objects)

>   If someone really wants to use an array to store individual transformations
> then he can do so. However, most importantly, he is not *forced* to do so
> if he doesn't want to.

Yep.

Fabien.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> It would make rendering slow as the whole array will need 
>>> to be computed for every ray that encounter the object, 
> 
>> Nonesense. Once the tracing starts, you compute the final transformation 
>> matrix, just like you do now when there are multiple transforms.
> 
>   It's not a question of efficiency, it's a question of not hard-coding
> one specific solution where no such hard-coding is necessary at all.

Sure. I'm not the one advocating that every object gets such an array. 
:-) I'm just pointing out that some of the objections are mistaken. 
Arrays you can index by objects and into which you can store anything 
(including transformations) would seem to be the obvious way to go.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

In article <470dbc43$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > Umm. Because it doesn't make much sense? Seriously, any such transforms
 
> > are going to be "very" specific to the IK chain of the particular objec
t 
> > you are working with. There is no point in making an array called 
> > "walk", which contains the needed transforms, instead of making it part
 
> > of the object, because logically it can't be applied to any "other" 
> > objects.
> 
> Errr, well, have you used Hash Animation Master? As long as you name the
 
> bones the same there, you can apply the "walk" to anything you want.
> 
> However, you missed my point, which was that if the array is separate 
> from the object, you can have multiple arrays and hence multiple sets of
 
> transformations that apply to the object at different times in the 
> animation.  If the character walks a while, then runs a while, do you 
> put the walk transformations or the run transformations in the object?
> If the array can be indexed by the object itself, then there's no 
> question in the code of the transformation being "off separate" 
> somewhere that's hard to find.
> 
But, nothing is stopping you from trading out the arrays, like you would 
with any other similar case. And yeah, I covered the issue with applying 
the "same" walk to anything you want. 1) it wouldn't really work, unless 
it had identical parts, and 2) for realistic animation of anything other 
than marching robots, its not applicable, since you never want two 
objects behaving 100% identically to each other.

Ok, lets get at a practical example. Lets say all you have is a sphere 
and torus. The torus is rotated a bit out of the plane of rotation. The 
initial design would look like (not checking the code, so I hope it 
comes out close. lol):

#define wobble = union{
  sphere {<0,0,0>, 1}
  torus {<0,0,0>, .5, 2> rotate <.1,0,0>
  texture{blah}
  rotate <0,clock,0>
  translate <56,43,12>
}
                    
This makes an object that, from the code perspective, looks like:

wobble
  \-sphere
    \-location
    \-size
  \-torus
    \-location
    \-size
    \-transforms
      \-[0] rotate <.1,0,0>
  \-texture
    \-...
  \-transforms
    [0] rotate <0, clock, 0>
    [1] translate <56,43,12>

This "continues" to be the way it works for 10 frames. Then you "keep" 
the rotation, but also change the angle of the torus (over 10 more 
frames).

toruschange[0] = "rotate <.1 * (20-10/10),0,0>"
toruschange[0] = "rotate <0,0,0>"
wobble.torus.transforms[0] = toruschange[0]

Then at frame 21 you "stop" both the rotation and the change to the 
torus, but send the object zipping down some 3D path:

z = clock //Lets say its now also 21.
main_trans[0] = "rotate <0,z,0>"
main_trans[1] = "translate GetLocation()"
wobble.torus.transforms[0] = toruschange[1]
wobble.transforms = main_trans

In this case z, unless you change it, will "remain" 21, so from then on 
you don't need to update anything in the object, and "GetLocation" 
returns a "path" that the object is going to follow, so that is 
automatically recalculated each frame, before the render happens.

You saving memory this way, because you **don't** have to change any 
transforms that you don't have to, while your way requires they all be 
stored, even the ones that don't change. Further, the "initial" state is 
"stored" in the object, so if instead you wanted wobble to do nothing 
but sit in one place through the entire animation, without ever changing 
its behavior, you don't ever have to do anything more than set use the 
SDL to tell it to use the clock value the determining how much to rotate 
it each frame.

Note, it might be useful to allow the "clock" to return both an integer 
of all "seconds" that have passed, as well as things like clock.seconds, 
clock.minutes, etc. Just for the sake of only having to do, "rotate <0, 
clock.seconds * 6, 0>", instead of something like "rotate <0, mod(clock 
/ 60) * 60, 0>". Mind, that isn't that bad, but a more direct way to get 
the number might be nice anyway, especially if you are incrementing the 
time by a large factor, like for time lapse or something.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470dec42@news.povray.org>, war### [at] tagpovrayorg says...
> Darren New <dne### [at] sanrrcom> wrote:
> > > It would make rendering slow as the whole array will need 
> > > to be computed for every ray that encounter the object, 
> 
> > Nonesense. Once the tracing starts, you compute the final transformatio
n 
> > matrix, just like you do now when there are multiple transforms.
> 
>   It's not a question of efficiency, it's a question of not hard-coding
> one specific solution where no such hard-coding is necessary at all.
> 
>   (Besides, it *is* a question of efficiency too: Those arrays will
> consume extra memory which is not necessary to be consumed. This may
> become an issue with millions of objects.)
> 
Your solution **still** requires extra arrays, or code, or **some** way 
to get the changing data "to" the object to transform it. If anything, 
as I try to explain in another post, your method is actually **more** of 
a memory hog. You keep claiming that you can just somehow "untransform" 
the matrix, or change it later, even when doing something like 
translate->rotate->translate irrevocably creates conditions where its no 
longer as simple as just adding one new rotation. Some how you have to 
both save memory "and" provide a way to change interdependent 
transforms, which, unless you are a fracking mathmatician, isn't going 
to be practical. any solution you come up with, at minimum, is going to 
require some transforms to be user changable, after the fact, and 
keeping **all** of them in an array, to be applied later, is **worse** 
that keeping all the of the initial states on the object, then just 
changing the one you actually need to.

I haven't seen any argument from you that does a thing to truly address 
that issue.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470ec586$1@news.povray.org>, dne### [at] sanrrcom says...
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >>> It would make rendering slow as the whole array will need 
> >>> to be computed for every ray that encounter the object, 
> > 
> >> Nonesense. Once the tracing starts, you compute the final transformati
on 
> >> matrix, just like you do now when there are multiple transforms.
> > 
> >   It's not a question of efficiency, it's a question of not hard-coding
> > one specific solution where no such hard-coding is necessary at all.
> 
> Sure. I'm not the one advocating that every object gets such an array. 
> :-) I'm just pointing out that some of the objections are mistaken. 
> Arrays you can index by objects and into which you can store anything 
> (including transformations) would seem to be the obvious way to go.
> 
Why? Its going to cost you more memory to store 20 transforms for an IK 
chain, and all changes needed for them, in separate arrays, than it will 
to store 20 transforms in the object, then apply only 3-4 changes from 
"your" array, which are needed to change the specific parts that are 
needed. One uses, lets say 20*5, just to pick an arbitrary number for 
the storage needed, + 4*5*number of changes. Yours requires 20*5*number 
of total changes you need. If the number of changes are say 10, then 
mine takes 20*5 + 4 * 5 * 10 = 300, yours takes 20*5*10 = 1,000. How th
e 
heck is that "better"? Mind you, this is a "simple" example. It only 
gets worse if it something that has 10 IK change points, and 90 objects. 
In that case its 90 * 5 * 10, or 4500 for you, and 90 * 5 + 10 * 5 * 10, 
or 950 for mine. Its only *equal* if every object has to have "every" 
transform changed between frames, and thus all of them replayed into the 
object. The more objects that are part of the IK design, the more insane 
your number gets, while mine only grows depending on the number of 
"specific" transforms you need to change during animation, plus the 
total number of original transforms.

Yes, it would be nice to have a solution that doesn't require any such 
thing to start with, and you can get by with that, to some extent, by 
having a function call to something that determines the next change, 
instead of a straight change. I have not however seen anything to 
convince me that "some" sort of solution similar to this isn't needed. 
At least not unless you throw out the entire old SDL and force everyone 
to use "your" solution to apply all the transforms all at once, every 
frame, which means abandoning the original SDL, since it can't currently 
work that way.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470df2c7$1@news.povray.org>, 
fab### [at] yourshoesskynetbe says...
> Warp a écrit :
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >> But this could be handled in SDL, no ?
> > 
> >   The main problem is that this "store all transformations in an array
> > inside the object" is a hard-coded solution which makes no sense. It
> > needlessly fixes this "problem" (which really isn't a problem at all,
> > which is something they just cannot seem to comprehend) with one single
> > hard-coded solution. If someone would like to use a different approach
> > then the internal array would be a completely useless waste of memory.
> > 
> >   Let's assume someone is implementing something where he really wants,
> > for whatever reason, to store all the individual transformations in a
> > data structure (instead of simply executing a series of commands which
> > will accumulate the transformations into a single transformation matrix
).
> > What happens if the data structure he wants to use is a list? What if h
e
> > wants to have *several* data structures containing alternative sets of
> > transformations? What if he wants the transformations in a binary tree?
> > He will have to implement these solutions in SDL, and the transformatio
n
> > array inside the object will be a useless waste of memory.
> 
> That's what I meant : implement the "transformation history" using SDL.
> 
> If the SDL is powerful enough, it could even be automatic : each time
> something tranforms an object, an "event" mechanism adds the transform
> to the history.
> 
Gah!! This is exactly what I am talking about. And everyone else is 
instead saying, "Gosh, this is silly, why not just store every single 
transform some place else, so it takes up even more memory, then apply 
them all over again anyway, not from the history, but from a bunch of 
arrays?" Feel like I am talking to a wall here.

> Objects could even have some kind of "extended data" that could be attach
ed
> to them, and be used as the user wishes. (it would help things like
> parent-chlid relations between objects)
> 
> >   If someone really wants to use an array to store individual transform
ations
> > then he can do so. However, most importantly, he is not *forced* to do 
so
> > if he doesn't want to.
> 
> Yep.
> 
> Fabien.
> 
Look, the only reason I am suggesting it is so that when you create an 
object the current "history" or "state" is accessible, so you can look 
at it, or change it. Sigh.. I have a feeling people are just so stuck on 
the idea of how they do things "now" that they just don't get why the 
solutions being proposed are either a) worse than mine, or b) make no 
sense in an SDL that doesn't work *exactly* like the way it does now.


-- 
void main () {
  If Schrödingers_cat is alive  
    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 <470### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
> > says...
> >> What I was saying is that we should distinguish between the 'first 
> >> creation' and the 'final creation'. Calling both simply 'creation' wil
l 
> >>   lead to confusion (as shown is this thread. Much of what you and 
> >> Patrck are writing does not make sense to me, because for me 'creation
' 
> >> is 'final creation').
> >>
> > How about "intermediary" creations then, just to confuse things more.
 
> > lol Technically, by your definition, the object is never "created" unti
l 
> > the frame in rendered, at least in any system like we are talking about
, 
> > where each "frame" is defined not by re-running the entire script, but
 
> > only via the command "in" the script.
> > 
> > In other words, in the current model we do this:
> > 
> > render("myfile")
> > 
> > in a true animation system, we do this:
> > 
> > 'Set up a bunch of objects.
> > ...
> > render
> > 'Change the objects some.
> > ...
> > render
> > 'Change them some more.
> > ...
> > render
> > 
> > The "render" step is explicit in the script, since it only happens 
> > "when" all the changes are made, not an external process that just runs
 
> > an SDL through it, and recalcs the data for everything as it does it,
 
> > based on the existing clock scheme, which is kind of limited. Mind you,
 
> > making that change, depending on how it was done, could break existing
 
> > SDL. Mind you, a command that "requests" the prior behavior could be 
> > used to solve that. 
> 
> You could also assume that a render command is implicit at the end of 
> parsing if none is given.
> 
Yes, I had considered that, but its better to have a compatibility flag, 
both so that someone doesn't try to run an old SDL, then wonder why it 
didn't work right, and so that someone using a *new* SDL could be warned 
that they forgot to actually render anything. Its kind of a toss up 
though.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 a écrit :

> Gah!! This is exactly what I am talking about. And everyone else is 
> instead saying, "Gosh, this is silly, why not just store every single 
> transform some place else, so it takes up even more memory, then apply 
> them all over again anyway, not from the history, but from a bunch of 
> arrays?" Feel like I am talking to a wall here.

You are talking to a Warp.

Fabien.

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> Why? Its going to cost you more memory to store 20 transforms for an IK 
> chain, and all changes needed for them, in separate arrays, than it will 
> to store 20 transforms in the object

  You don't get it, do you? Forcing a transformation array to exist in every
single object increases memory consumption compared to objects not having
such an array, and a separate SDL array being used only in objects which
need it.

  If you have 10000 objects in your scene, 10 of which are IK'ed, forcing
a transformation array to exist for every single one of the 10000 objects
(even if those arrays are empty or contain just one transformation) is
going to consume much more memory than if the array existed only for those
10 IK'ed objects.

  Do you think having an empty array in an object takes no memory?

  Anyways, no array is needed, not even for IK'ed objects. How do you think
the current POV-Ray manages without such arrays? And no, the answer is not
"by reparsing every object each time".

> then apply only 3-4 changes from 
> "your" array, which are needed to change the specific parts that are 
> needed. One uses, lets say 20*5, just to pick an arbitrary number for 
> the storage needed, + 4*5*number of changes. Yours requires 20*5*number 
> of total changes you need. If the number of changes are say 10, then 
> mine takes 20*5 + 4 * 5 * 10 = 300, yours takes 20*5*10 = 1,000.

  Those numbers don't make any sense.

> At least not unless you throw out the entire old SDL and force everyone 
> to use "your" solution to apply all the transforms all at once, every 
> frame, which means abandoning the original SDL, since it can't currently 
> work that way.

  What the heck are you talking about? Object-specific transformation arrays
are needed to preserve the current SDL?

  The more you write, the weirder it gets.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> Your solution **still** requires extra arrays, or code, or **some** way 
> to get the changing data "to" the object to transform it.

  Well, you have to define the objects somehow. You could as well
define them so that the transformations can be executed at each frame,
at *no additional cost*. The transformation code must exist in one form
or another.

> You keep claiming that you can just somehow "untransform" 
> the matrix

  Do you understand the concept of resetting a transformation matrix?
Or is that concept way too difficult for you to comprehend?

>, or change it later, even when doing something like 
> translate->rotate->translate irrevocably creates conditions where its no 
> longer as simple as just adding one new rotation.

  I don't think you even understand how transformation matrices work.
If you really think that an individual transformation couldn't be removed
from a transformation matrix even after several other transformations
have been applied to it, then you should *really* acquaint yourself with
transformation matrices and the math involved.

  In all these posts I haven't even been talking about removing/changing
one single transformation from the transformation matrix, but even that
is certainly possible to do to a transformation matrix, if you really
wanted to do so. (No, it's not possible to retrieve every individual
transformation which has been applied to a transformation matrix, but
if you already know which transformations has been applied to it, it is
possible to undo one of them. Anyways, that's not very relevant.)

> Some how you have to 
> both save memory "and" provide a way to change interdependent 
> transforms

  You don't understand this either, do you? The memory wasting comes in
your solution in that *every* object will have a useless array, wasting
memory, when none is needed.

  In other words, in your "solution" every object has a transformation
array *and* there exists SDL code which writes values to that array.
In the correct solution there's no such array and only the code exists.

  Do you understand now how there's less memory requirements in this way?

>, which, unless you are a fracking mathmatician, isn't going 
> to be practical.

  You don't need to be a mathematician to apply a series of transformations
to an object. It's just a question of syntax.

> any solution you come up with, at minimum, is going to 
> require some transforms to be user changable

  How does the current SDL handle transformations which change from one
frame to the other? Why should the new SDL be any different (except that
re-parsing the object itself can be skipped)?

> after the fact, and 
> keeping **all** of them in an array, to be applied later, is **worse** 
> that keeping all the of the initial states on the object, then just 
> changing the one you actually need to.

  Why is it worse?

  The only thing which is worse is your solution: You are hard-coding one
specific solution, and you are wasting memory by having a useless array
in each single object.

> I haven't seen any argument from you that does a thing to truly address 
> that issue.

  That's because you have a misunderstanding about how transformations work.

  Answer me this: Why the current POV-Ray doesn't need object-specific
transformation arrays?
  The answer is not "because it re-parses the objects at each frame".
That re-parsing could perfectly be skipped with the proper syntax changes.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> > If the SDL is powerful enough, it could even be automatic : each time
> > something tranforms an object, an "event" mechanism adds the transform
> > to the history.
> > 
> Gah!! This is exactly what I am talking about. And everyone else is 
> instead saying, "Gosh, this is silly, why not just store every single 
> transform some place else, so it takes up even more memory, then apply 
> them all over again anyway, not from the history, but from a bunch of 
> arrays?" Feel like I am talking to a wall here.

  What the heck do you need a "transformation history" for? You don't need
it currently, nor you need it in the future SDL either. Why would it be
any useful?

  The "transformation history" is in the SDL code you write. Why do you
need to store it somewhere else as well? That's just a completely useless
waste of memory.

> Look, the only reason I am suggesting it is so that when you create an 
> object the current "history" or "state" is accessible, so you can look 
> at it, or change it.

  Why do you need to "look at it" and "change it"? The transformations
are already in the SDL code you write. Just write them so that they
change appropriately at each frame. I just can't see what the heck is
the problem.

> Sigh.. I have a feeling people are just so stuck on 
> the idea of how they do things "now" that they just don't get why the 
> solutions being proposed are either a) worse than mine, or b) make no 
> sense in an SDL that doesn't work *exactly* like the way it does now.

  There's a reason why there are no "transformation arrays" in the current
SDL. The reason is that they are not needed. They would only be a completely
useless waste of space.

  And once again, you would be hard-coding one specific solution. That is
not the way to go. Hard-coding solutions is bad programming.

-- 
                                                          - Warp

Post a reply to this message