> Nicolas Alvarez wrote:
> 
>>>
>> You missed my point (because I didn't make it so clear :P). How would 
>> you handle that *and* allow syntax like this?
>>
>> 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.
> 
> why? In the current SDL objects can still be moved after creation. They 
> can not after rendering begins, but you have a point, if a shader has 
> access to all underlying data structures, it could move any object while 
> rendering. That would break any attempt to subdivide the task over 
> processors. We need to make sure that all properties are locked during 
> rendering. Or are there properties that could be changed?

One thing is moving an object after creation. Another is "changing a 
previously-defined translate" (that's not currently possible in SDL, and 
it's a bad idea anyway). See my reply to Warp.

Post a reply to this message

Nicolas Alvarez wrote:

>> 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>"
>  >
As warp said, at the moment the individual transformations are not 
stored and there is absolutely no reason in POV4 to do so.
And even if there would be an array of transformations, the textures 
(which is your main problem, I think) would get there own array and 
would not get influenced by such after the fact changes.

BTW in POV there is indeed an interaction of transformations and 
textures that comes from the fact that our textures are 3-dimensional.
I have not much experience with other 3D software but it may be one of 
the things that set POV apart from others. I think that in the context 
of POV4 we should think about how 3D textures influence our scenes and 
how they influence our programming language.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Another is "changing a 
> previously-defined translate" (that's not currently possible in SDL, and 
> 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-oriented
terms, a translation is not a member variable of the object, it's a member
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 have
applied it already.

  (Technically speaking you can later apply a new set of transformations
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 functions
which work in the same way as in the current SDL.

-- 
                                                          - Warp

Post a reply to this message

> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Another is "changing a 
>> previously-defined translate" (that's not currently possible in SDL, and 
>> 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-oriented
> terms, a translation is not a member variable of the object, it's a member
> 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 have
> applied it already.
> 
>   (Technically speaking you can later apply a new set of transformations
> 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 functions
> 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 do.

Post a reply to this message

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