> The only possible issue I can see 
> is with a few things like rotate/scale, etc., where you might need to 
> use an enumeration to keep track of which one you are working with. But 
> that's not a huge problem. Lets say you have:
> 
> #declare body = object {... arm{rotate blah 'some other stuff' rotate 
> blah2} ...}}
> 
> And you want to adjust the "first" rotation.
> 
> body.arm.rotate(0)="<5,0,0>"
> 
> Wow! So hard... And the *initial* creation of the object didn't change 
> on tiny bit, its still standard SDL, you just now have more control over 
> each individual aspect of *that* object. And its not likely to be that 
> complicated to tell the difference between 'body.arm.rotate(0)
> ="<5,0,0>"' and say 'body.arm.texture(0).rotate(0)="<5,0,0>"', right?
> 

I don't know why somebody would need to change individual 
transformations. In addition, it could be cumbersome to refer to 
transformations by their numerical index Just to let you know: POV-Ray 
(currently) doesn't keep individual transformation statements. Every 
transformation you do changes the transform matrix of the object, so you 
can only do further transformations on the existing matrix. Only way to 
edit a previous transform would be to "undo" all that followed, re-do 
the changed transform with new parameters, and re-do all that followed.

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.

I think we would be fine with body.arm.rotate(5,0,0) which affects the 
current transformation matrix just like current POV does, without having 
to keep every individual change that has been done.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:

> Doing things without 3rd party apps is not a matter of looking smart.
> It's a matter of convenience when it can be done.
>
> Let's stay with the example of subdivision surfaces (or any other
> automated process for meshes).
>
> I model something in Wings3D.  Then I export it to POV-Ray.  Suddenly,
> I think, oh, I would need one more subdivision level for my object
> to look smooth !  If it's done within POV-Ray, there's just a parameter
> to change.  If not (as currently), I have to go back to Wings, do the
> subdivision, and re-export !

I think your vertex displacement example makes more sense. It's pretty
obvious in Wings (or any other tool where you have interactive realtime
preview capabilities) how smooth a mesh is (or isn't) after a subdivision.
The main advantage of render-time subdivision is reduced use of disk space
and less parsing.

To provide a counter-example, how about mesh decimation? It's easy to
imagine a mesh where the decimation works well on one part of the mesh but
doesn't do so well in a section of it. It could take many re-renders in POV
(involving a complete adjust-parse-render cycle, nothing like realtime)
before I find parameters for which the decimated mesh looks good. This is
already enough of a pain with renderer-specific features it can't really be
avoided for, like radiosity. When I have access to tools with realtime
preview capability for meshes, it makes much less sense to involve POV for
many mesh operations, in my view.

Making waves on the surface of a mesh ocean during an animation? Thumbs up
to this idea. For *all* mesh manipulation, given the external tool's much
faster preview, 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.

Tom

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> > I am digging a solution with Java as an intermediate langage.
>
>   Using the Java bytecode as the bytecode used in POV-Ray could be an
> idea, but I'm not sure it's the only or the best possible existing
> bytecode format and engine.
>
> --
>                                                           - Warp

For sure. But it is the one that came to my mind. It is just a vague scheme
and general principle. Whatever solution we choose, there will be a quite
long way from the idea to the first 'official' benchmark scene in POV4
syntax. For now,I must cook it a little more and make a more elaborate
example.

BTW, I am quite a good chef, and concerning (french) cuisine, I have good
intuitions and I like to improvise. I never use recipes, I reinvent all the
time, but often use good ol' principles that match the human taste. I also
often search for new ways ...

I'll try to add more POV ingredients into the pans. I remind you that a
dinner has success also because of the quality of the guests. And there are
quality people around here!



    Bruno

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

Post a reply to this message

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
> In my scheme, this code would rather be the Java generated intermediate
> code.

In my Scheme, this code would be sweet. ;)

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Personally, I am not against something entirely new. I seldom reuse POV code,
> anyway, and more flexibility is so attracting.

People with huge custom libraries would certainly disagree.

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> 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