 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy <wtr### [at] calpoly edu> wrote:
> Shay wrote:
> > How about:
> >
> > #local MyOb = difference {
> > sphere { 0, 1 translate y*2 rotate z*45 translate <2,3,4> }
> > object { Some Other Object }
> > }
> >
> > MyOb.subtrahend.transforms[1].addrotate(<0, 0, 15>);
> > MyOb.subtrahend.transforms[0] *= <1,0,0,0,0,1,0,0,0,0,0,1,0,5,0,1>
>
> Quick question for the group:
>
> Does anyone see any value in being able to use OO syntax to transform an
> object *after* it's declaration, in the general way shown in Shay's
> example? (I would like to hope that we could come up with a cleaner
> syntax than that.)
This is something I'd always like to do:
// a 3-legged 1-unit sized stool at origin.
#local stool = Stool { 0, 3 texture { textures.oak rotate 30 } }
stool.scale( .3, 1.4, .3 );
stool.place_on( floor );
stool.away( 3, nw_wall );
#local sph = sphere { 0, 1 pigment { rgb x } }
sph.place_on( stool );
Relative positioning of objects in the scene should benefit imensely from
not having to explicitely keep track of their positions by means of local
variables or half-assed positioning macros. I've placed a sphere upon a
stool on the floor, without ever having to pass their sizes or positions.
Yes, there's trace and some positioning macros that allow us to do something
like that today in the "half-assed" routines we have in our personal
toolsets, but that's nothing compared to having current position and
transform state inside the objects themselves as properties, rather than
needing to declare variables for that purpose.
For instance, the stool is inittially at the origin and then I place it on
the floor, which might be anywhere in the y scale. If I had a macro to
determine the actual position of an object, given the identifier stool, all
it would get would be 0, the original location.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote in message <470### [at] hotmailcom>:
> new Sphere s;
> s.Position=[1,1,10];
> s.Radius=.7;
> s.Texture.Pigment=[0,1,0];
> s.Scale(1,2,1);
> s.Rotate(30,0,0);
>
> That is all very clear coding, but *not* what most of the group here
> wants.
This code is a little bit verbose, but not much. Consider the current SDL
equivalent:
#declare s = sphere {
<1,1,10>, .7
texture { pigment { rgb <0,1,0> } }
scale <1,2,1>
rotate <30,0,0>
}
Roughly the same number of lines and characters, and the same
self-documented readability.
I think that "most of the group here" wants the second only because they
already have the habit of knowing it, not because it has inherent qualities.
Which is a point to take into consideration, of course.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote in message <47068487$1@news.povray.org>:
> Yes, especially on objects collections. Say you have a set of 100
> spheres. Initially, they are small and red. You want 60 of them
> to become big, and 60 of them to become blue, but only 10 will
> be blue AND big.
Then you have to link POV-Ray 4 with libmath-2, because with the current
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>... POV's attachment to triangles rather than quads, and the
> fact that once it goes in to SDL (even future SDL) it's never coming out
> again? I don't see the advantage.
No doubt NURBs will end up in 4.0 in some fashion since
they are requested quite often.
I would think that the syntax of 4.0 must retain most of
the look and feel of current SDL. This is part of why I
think that breaking up the scenes into sections like
environment{} pre_process{} ... scene ... post_process{}
would make sense. That way certain advanced features
would be easily located.
Imagine being able to overload object definitions...
environment {
overload {
box{A,B}
//wireframe objects
cylinder {A,<A.x,A.y,B.z>,0.05} ... etc
}
}
in order to change all the regular boxes in your scene into
wireframe. This is aspect oriented, which is a good fit
for Pov, IMO.
Object oriented would mean the attachment of methods...
for non-programmers that means functions, which in the
case of Pov probably would end up being to manipulate
graphic objects. That might end up with something like...
box {A,B
modify {wireframe(diameter)}
}
Where wireframe is a method for box. The problem with
this is that wireframe is probably going to be defined
somewhere in C++ instead of in SDL. The functions would
be handy, but limited by your ability to program and
compile, most artists will avoid that I think.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
