In article <47083c29$1@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> sphere.translate[0]="<5,0,0>"
> > 
> >> I think it's a bad idea to allow changing individual transformation 
> >> statements after the object has been created.
> > 
> >   There's no such a thing as a "translate" element in a sphere (or in
> > any other object for that matter). Thus it would make no sense to have
> > such an element in the sphere object of the new SDL either.
> > 
> >   What should exist is a *function* (member or not) which applies the
> > translation to the sphere (which is a different thing). Calling this
> > function will, naturally apply the subsequent translations properly
> > (as well as other transformations).
> > 
> >   (In general all transformations are internally collected into a
> > 4x4 transformation matrix, except when the transformation can be
> > optimized away by eg. transforming the center point of the sphere
> > only. However, there exists no "translate" member variable in the
> > sphere object or any other object.)
> > 
> 
> Yep, that was my point. Transforming the object further should *of 
> course* be allowed (complex CSG would become fairly impossible without 
> that!), but having all individual transformation "items" stored in an 
> array and being modifiable seems like a bad idea.
> 
> That was what Patrick Elliot said, and I was replying to:
>  > And you want to adjust the "first" rotation.
>  >
>  > body.arm.rotate(0)="<5,0,0>"
>  >
> 
Hmm. Ok. That case I hadn't considered. I was thinking in terms of ease 
of identifying the transformation, not in terms of how they interact. 
Its messier to do something like:

body.arm.transform(0)="<5,0,0>"

since you would **have to** know that the "first" transform was the 
rotate, not something else. Short of including, as part of the internal 
data, some concept as to the "order" of the overall operations, so that 
changing the transform would not effect order. Think of it kind of like 
dynamic parsing. Instead of recreating the object in every single frame 
of an animation, you create it once, then *only* adjust those textures, 
transforms, etc. that are *needed* to change, without having to restate 
it all in SDL. Now, you can't do that right now. 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. However, you *must* be 
able to change it, of you want it to do what its supposed to, because 
its *not* the final transform that is being effected, but the one that 
happens prior to the final change. This is especially true if dealing 
with something that has, for example, a complex IK chain system. 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. 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. 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

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? The only other way to do it is by 
forcing someone to "only" allow certain types of transforms, like 
"rotate", "rotate at object coordinate (such as one of its corners, or 
slightly off of center" and "rotate at origin". In other words, you 
either maintain an internal concept of which elements define the object 
and allow those to be changed "independently" by object references, 
**or** you limit the actual transforms to ones that specify distinct 
behaviors, and force someone to use only the one they need, instead of 
letting them make changes to the individual elements defined in the 
original object.

Mind you, there is "one" alternative. Reparse only the bits you need. 
I.e., what the user sees is:

sphere
  |-translate()
  | |-(0) translate blah
  | |-(1) translate blah
  |-texture()
    |-(0) texture data

What the engine sees is:

sphere
  |-translate blah
  |-texture
  | |-data for that
  |-translate blah

So, the next frame, it "reparses" the "engine" version, in its original 
order and associations, to get the new sphere for that frame.

This is sort of what you would have to do, no matter "how" you stored 
things internally, unless, as I said, you allowed "creation" of an 
object using the original SDL syntax, but then required the "script" 
portion to use the more limited set of "allowed" actions, as with the 
rotate example above.

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. If you avoid doing that, then 
you are still stuck either somehow selectively re-making, based on key 
changes, the internal representation, by basically reparsing it in some 
fashion anyway, or you have to limit what "is" allowed. You can't do 
what is needed with the SDL as it exists, without basically doing the 
same thing anyway, and if you are going to "store" those representations 
and the order they occur, there is no reason to not provide an means to 
look at or even change *what* is stored in those elements. The engine 
"still" has to figure out what those changes "mean" in the next frame, 
in terms of the final result of how the object is effected.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

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

Post a reply to this message

In article <4709033b@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> Another is "changing a 
> >> previously-defined translate" (that's not currently possible in SDL, a
nd 
> >> it's a bad idea anyway).
> > 
> >   Somehow I feel you are a bit talking about apples and oranges here.
> > 
> >   Of course there's no way of "changing a previously defined translate"
> > because there's no such thing as a "previously defined translate". As I
> > said in the other post, a translation is not a property of the object,
> > it's an operation applied to the object (in other words, in object-orie
nted
> > terms, a translation is not a member variable of the object, it's a mem
ber
> > function). You either apply it (so that it has some effect) or you don'
t.
> > You can't go "back in time" and apply it in a different way once you ha
ve
> > applied it already.
> > 
> >   (Technically speaking you can later apply a new set of transformation
s
> > which cancel out the earlier translation, so the effect is the same as 
if
> > the earlier translation had not been performed at all, but this is a
> > rather different thing at a basic conceptual level.)
> > 
> >   I can't really see what is the problem people are seeing here. I don'
t
> > see any problem in objects in the new SDL having transformation functio
ns
> > which work in the same way as in the current SDL.
> > 
> 
> I was just commenting on Patrick's examples which showed changing 
> individual transformations, stored in some sort of array. So we are 
> agreeing. The way transformations should work is the way they currently d
o.
> 
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*? I would be 100% fine with an explanation for how to 
keep things as they are, or provide those transforms in a way that still 
allows handling the objects in a way that lets you make adjustments 
between frames, without having the reparse the entire file (which can 
sometimes take up 100 times as much time as producing the final image). 
I just don't see how you do that. The existing system parses the objects 
into a *static* internal layout, which you can't change anything on. Any 
changes have to be done "during" the parsing. Once the object exists, 
the only thing you can do is dump it from memory, and start over, by 
reparsing the entire thing again, with new data. That you can calculate 
what that data is in the SDL, doesn't change the basic nature of what 
you end up with. And that is **not** something useful, or practical, for 
anything but single frames.

So, what is the answer? Just figure that speed for the parser is 
impossible to solve, so who gives a frack, lets just leave it slow and 
reparse 100% of the file every frame? Or do we get our heads out of the 
sand and either realize that there is no solution that works in the 
"existing" framework, which can allow this, or that, if we do find a 
way, we need to provide a sane and flexible way to solve it, not some 
method that basically does nothing but impose the "same" problems on the 
new system as we have already? It just doesn't make sense to me to have 
transforms work the same as now, when the reason they are a problem 
*now* isn't going to change if you plan to speed up parsing, or improve 
the ability to animate through the SDL.

I am even more bloody confused by the fact that I stated a clear 
alternative. Allow the internal representation work **exactly** as it 
does now, at least in terms of how such objects are handled in each 
frame, but parsing it from a *binary* representation, not the original 
text. Create the original using text, sure, but keep it internally as 
binary, so you can change it between frames, without the cost of having 
to reparse the entire damn file. Then **allow** someone that wants to 
access, through a more object oriented system, to change anything they 
like in that "binary" copy. Don't reparse 10,000 lines of code if the 
**only** thing you need to do is change one bloody transform in an 
already parsed object.

And more to the point, please, give me some good idea how the hell you 
allow that, in any way that doesn't require a 10,000 line reparse, 
without resorting to something at least "similar" to what I suggested?

Sorry for being a bit snippy, but bloody hell, why are we even 
discussing how the SDL works and what problems it currently has, (which 
can make it so damn slow in some cases), if all we are going to do is 
go, "Ah, well... I don't like how that might change the syntax, so lets 
just pretend keeping things as is isn't going to be (or perpetuate) any 
kind of problems/limitations."

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

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

Post a reply to this message

In article <4709033b@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> Another is "changing a 
> >> previously-defined translate" (that's not currently possible in SDL, a
nd 
> >> it's a bad idea anyway).
> > 
> >   Somehow I feel you are a bit talking about apples and oranges here.
> > 
> >   Of course there's no way of "changing a previously defined translate"
> > because there's no such thing as a "previously defined translate". As I
> > said in the other post, a translation is not a property of the object,
> > it's an operation applied to the object (in other words, in object-orie
nted
> > terms, a translation is not a member variable of the object, it's a mem
ber
> > function). You either apply it (so that it has some effect) or you don'
t.
> > You can't go "back in time" and apply it in a different way once you ha
ve
> > applied it already.
> > 
> >   (Technically speaking you can later apply a new set of transformation
s
> > which cancel out the earlier translation, so the effect is the same as 
if
> > the earlier translation had not been performed at all, but this is a
> > rather different thing at a basic conceptual level.)
> > 
> >   I can't really see what is the problem people are seeing here. I don'
t
> > see any problem in objects in the new SDL having transformation functio
ns
> > which work in the same way as in the current SDL.
> > 
> 
> I was just commenting on Patrick's examples which showed changing 
> individual transformations, stored in some sort of array. So we are 
> agreeing. The way transformations should work is the way they currently d
o.
> 
Sigh. Ok, you might not have read the post I made later. Seems it got 
caught in the damn outbox of the usenet client I use, which won't bloody 
send until after it "rechecks" all the groups on a server. Sometimes I 
hate this program, but given I have yet to find one that acts close to 
the same and didn't have even more irritating issues...

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

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

Post a reply to this message

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?



Bruno

Post a reply to this message

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.

-- 
                                                          - Warp

Post a reply to this message

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.

-- 
                                                          - Warp

Post a reply to this message

Bruno Cabasson wrote:
> Concerning the animation problem, I see things as follows:
> 
> Solution 1:
> -----------
> The nth frame I(n) of an animation is a function of time only. Its
> description depends on the sole time parameter. Then you can conceptually
> write:
> 
> I(n) = F(tn), with F being the function that describes the scene at time tn.
> 
> This is POV's point of view, through the 'clock' variable and reparsing the
> whole scene (except radiosity and photon maps if so specified).
> 
> This solution requires only the description of the F(t) function.
> 
> Solution 2:
> -----------
> The nth frame I(n) is made by delta wrt first frame. Its description relies
> on the description of first frame at t0 and a delta function that depends
> on the time parameter. Then you can conceptually write:
> 
> I(n) = I(0) + D(tn), with D being the function that describes the variation
> of the scene between tn and t0.
> 
> This solution requires the decription of I(0) and the D(t) function.
> 
> Solution 3:
> -----------
> The nth frame I(n) is made by delta wrt previous frame. Its description
> relies on that of the previous frame I(n-1) and a delta function that
> depends on the two instants tn and tn-1. Then you can conceptually write:
> 
> I(n) = G(I(n-1)) = I(n) + d(tn, tn-1), with d being the function that
> describes the variation of the scene between tn and tn-1.
> 
> This solution requires the description of I(0) and d(t1, t2) function.
> 
> 
> Each of these solution is a different approach with pros and cons and
> implies related features and syntax.
> 
> Concerning POV4, which of these is preferable?
> 
none or all

Post a reply to this message

In article <4709fb43@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > If you have something like:
> 
> > #declare yy = clock
> > sphere {...
> >   translate <yy,35,61>
> >   texture { some_complex_texture translate 100*x}
> >   translate y*2}
> 
> > Then you **must** reparse the object every single time, because once th
e 
> > object exists internally, it can't be changed.
> 
>   Wrong.
> 
>   The object has its own transformation matrix and the texture its own.
> All transformations applied to the object go to its transformation matrix
,
> and all transformations applied to the texture (be it directly in the
> texture block or indirectly in the object block) go to the transformation
> matrix of the texture.
>   It would be perfectly possible to alter these two transformation matric
es
> afterwards. It's simply a question of which transformations are applied t
o
> the object only, which ones to the texture only and which ones to both.
> 
> > The 
> > transforms you need to be able to change are "not" sitting conveniently
 
> > as the last thing in the object, they are buried deep within the 
> > structure.
> 
>   You seem to have this concept that the transformations are somehow
> stored in the definition of the object, and that this order must be
> preserved.
> 
>   The individual transformations are not stored anywhere. Each transforma
tion
> is simply a command (a kind of "function call" if you like) which modifie
s
> the internal transformation matrix of the object.
> 
>   It would be perfectly possible, after the object has been created (with
> the transformations and all), to reset its transformation matrix and then
> apply the same transformations to it, resulting in the exact same end
> result. The only distinction you have to make is which transformations
> go to the object, which ones to the texture and which ones to both.
> 
> > If we want to be able to animate, without a reparse, we need 
> > an internal representation that allows "each" transform, texture, 
> > object, etc. to exist as accessible elements, not as static 
> > declarations.
> 
>   No we don't.
> 
> > In other words, you need to make it "look" like:
> 
> > yy = yy + 1
> > mysphere.translate(0)=yy,35,61
> 
> > Even as the engine keeps track of "how" those things connect:
> 
> > start->translate(0)->texture(0)->translate(1)->end
> 
>   The engine doesn't need to keep track of that. You should acquaint
> yourself with transformation matrices and how they work.
> 
> > How else do you both allow animation, without a reparse, but also 
> > maintain the capacity to place as many transforms, or other elements,
 
> > into the object as you can now?
> 
>   You can write a thousands individual transformations into an object,
> yet none of them will be (individually) stored anywhere. They are all
> applied to one single 4x4 transformation matrix. POV-Ray doesn't need
> to keep track of the individual transformations nor store them anywhere.
> 
>   The only thing you need to specify is whether a certain transformation
> is applied to the object, to the texture, or both.
> 
> > See what I am getting at? If you want to maintain the "existing" SDL,
 
> > you have to allow for this, or suffer the current consequence of having
 
> > to reparse the "entire" SDL every frame.
> 
>   That's just not true. The only thing you have to allow in the new SDL
> is to be able to apply transformations to the object only, the texture
> only or both at the same time. This is very trivial to do.
>   It's perfectly possible to transform the object but not the texture
> even after the texture has been specified.
> 
> 
Sigh.. You are I think making an assumption that, when you do want to 
change something, you would only want to change "one" transform. But, 
maybe you have a dozen, each with does something specific to positioning 
the object, each of which is "also" effected by all of the prior 
transforms. Tell me, with a real example, not just some assertion that I 
am imagining a problem, how you do that. Yes, you can use some commands 
that can revert the object to a known state, like at the origin, then 
transform it, but that is useless if the transform you need is relative 
to some arbitrary point, which is the result of 3-4 other prior 
transforms. How do you, if you are doing say 7 translates, for some odd 
reason, revert back to the 3rd, change the 4th, then reapply the last 3? 
You can't, without drastically altering how you handled those transforms 
in the first place, and reducing them to a bare minimum number needed to 
do the task. Sure, it might be possible, but it still breaks, as near as 
I can tell, when you try to provide a post-creation transform on the 
object, to modify the prior result. Show me that I am wrong, don't just 
tell me I am.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

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

Post a reply to this message

In article <4709fc49@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > And I don't think you have *at all* addressed what I was getting at. Ho
w 
> > do you do something like IK, without either a) allowing an object like
 
> > reference system *which keeps track of* which order the transforms took
 
> > place in, such that if you move something, then rotate it, you don't 
> > want to later just rotate it, and assume its going to produce the same
 
> > result, or b) limiting the types of transforms that *are* possible to a
n 
> > already parsed object, or c) reparsing every damn thing in the script,
 
> > so you can recalculate just what the heck the object is described doing
 
> > *in that frame*?
> 
>   You don't need to reparse the entire object if you simply want to apply
> some new transformations to it. What you do is to reset its transformatio
n
> matrix and apply the new transformations to it. That's it.
> 
>   If what you are doing requires remembering and applying a set of
> transformations in order, you can simply create an array or whatever
> with these transformations, or whatever you like. However, that's
> completely irrelevant from the point of view of the object itself.
> 
>   The only thing you have to be able to specify is whether a transformati
on
> is applied to the object only, the texture only, or both.
> 
>   You don't seem to understand how transformations work.
> 
I know damn well how they work. And you don't solve the problem by 
reverting things. How do you revert **only** to the Nth transform so 
that you change only that one? You are assuming, I think wrongly, that 
no combination of transforms can produce a situation where the result 
cannot be reset, then some arbitrary transform reapplied to make the one 
change needed. Worse, your assertion that all you need to do, if it is a 
problem, is keep every transform in some sort of array, then reapply 
them from that, is... What they frack do you think I have been saying? 
The only difference between your array and mine is that I separate 
"types" of transforms so you don't have to remember if the second 
translate is the 6th transform in the array, not the 5th. The point is 
to still track those transforms in an array of some type, so they can be 
reapplied, *if* you have to manage them that way. Your, "just make some 
separate transform array", just obfuscates what is going on, by 
separating the transforms from the object they effect, when they should, 
logically be considered "part" of the final object (especially if its a 
compound object and things like "how" the texture is applied is changed 
dependent on the position of those sub-objects in some way, as a result 
of those transforms).

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

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

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

Post a reply to this message

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

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

Post a reply to this message