> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> 
>> Also, how would you handle this?
>> sphere {
>>     <1,2,3>, 0.5
>>     translate <12,35,61>
>>     texture { some_complex_texture }
>>     translate y*2
>> }
>> The first translate doesn't affect the texture, the second does.
>>
> 
> Just like POV does (correct me if I am wrong): when translate is encountered
> it translates the whole object. At the time of first translate, no texture
> is specified yet (=null, I suppose). At the time of the second the sphere's
> 'texture' field is non-null, thus transformed with the object. The final
> state is that de texture has been translated twice.
> 
> In new SDL, it would be the same: the translate() method (or whatever it
> will be) of an object (or its derived) will apply on whatever there is
> inside the current object. You could have also written
> 
>  sphere {
>      <1,2,3>, 0.5
>      translate <12,35,61>
>      texture { some_complex_texture translate 100*x}
>      translate y*2
>  }
> 
> with 3 translations for the texture.
> 
> Bruno
> 
> 
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.

Post a reply to this message

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

-- 
                                                          - Warp

Post a reply to this message

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?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >
> >> Also, how would you handle this?
> >> sphere {
> >>     <1,2,3>, 0.5
> >>     translate <12,35,61>
> >>     texture { some_complex_texture }
> >>     translate y*2
> >> }
> >> The first translate doesn't affect the texture, the second does.
> >>
> >
> > Just like POV does (correct me if I am wrong): when translate is encountered
> > it translates the whole object. At the time of first translate, no texture
> > is specified yet (=null, I suppose). At the time of the second the sphere's
> > 'texture' field is non-null, thus transformed with the object. The final
> > state is that de texture has been translated twice.
> >
> > In new SDL, it would be the same: the translate() method (or whatever it
> > will be) of an object (or its derived) will apply on whatever there is
> > inside the current object. You could have also written
> >
> >  sphere {
> >      <1,2,3>, 0.5
> >      translate <12,35,61>
> >      texture { some_complex_texture translate 100*x}
> >      translate y*2
> >  }
> >
> > with 3 translations for the texture.
> >
> > Bruno
> >
> >
> 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.

Maybe it's me who did not understand well ;o)

However, my vision of things is that the MyObjectType { } block could be a
notational/convenience shortcut, as close to current syntax as possible (at
least obeing the same notational principles), for a 'constructor' in the
sense of 'creating a new object of a specific king with specific
characteristics you valuate'.

What we could decided right now by people here, is: would it be possible to
change charateristics of an object AFTER its creation, displacing it,
changing its texture, or performing specific operations (some basic
mesh-editng ...?)?

We caould have something like:

YES --> Form 1:
my_stool = Stool
{
    <stool class properties, that were not defaulted in class definition>
    < or overridden properties>
}
..../...
my_stool.to_mesh();
my_stool.some_mesh_editing_feature();
my_stool.smooth(); // It's a mesh now

NO --> Form 2:
my_stool = Stool
{
    <stool class properties, that were not defaulted in class definition>
    < or overridden properties>
    to_mesh();

    // It's a mesh now, so, it inhertits mesh methods
    some_mesh_editing_feature();
    smooth();
}

The second form would allow method calls within the creation block, and the
syntax would be more likely not to allow any further modification outside
this block(= after creation). Thinking of that while typing these lines, I
prefer Form 2.

Remark: a new syntax (or whatsoever) cannot be mature at first try. We will
have to make several rounds before the new syntax is considered as
'usable'. My experience is that nothing is really OK before version 3.
Version 1 is a first attempt to have 'all together', version 2 often
implies changes in the approach and many modifications corrections making
the system 'work', version 3 is the one that makes 'all together' AND
'working' AND 'quite fine'.

Bruno

Post a reply to this message

Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> What we could decided right now by people here, is: would it be possible to
> change charateristics of an object AFTER its creation, displacing it,
> changing its texture, or performing specific operations (some basic
> mesh-editng ...?)?

  I don't see why not.

  This is *especially* true with transformations, given that transforming
an object is an operation done to the object (which is collected into a
single transformation matrix), not a property of the object.

-- 
                                                          - Warp

Post a reply to this message

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

Post a reply to this message

> 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