> Possible 4.0 way:
> 
> #local A = sphere {
>   translate y*1
>   rotate z*10
>   rotate x*20
>   scale <23,44,33>
> }
> 
> // an instance of a
> A.transform[0] = <0,1,0>
> object { A }
> 
> // another instance of a
> A.transform[0] = <0,2,0>
> object { A }
> 

The real OOP way would be:

Sphere A = sphere {
   translate y*1
   rotate z*10
   rotate x*20
   scale <23,44,33>
}

// an instance of a
A.transform[0] = <0,1,0>;
scene.addObject(A);

// another instance of a
A.transform[0] = <0,2,0>
scene.addObject(A);

addObject could also apply to CSG objects :) I think it's nicer to do this:

Union all = union{};
/* shinyThings is an array */
foreach(obj in shinyThings) {
     all.addObject(obj);
}

Than using POV-Ray's current "power" to put loops anywhere:
union {
     #foreach(obj in shinyThings)
         object { obj }
     #end
}

This is just like allowing macros anywhere: it blocks from doing many 
performance improvements. Evil stuff like this is currently possible:
#declare I=0;
#while (I<10)
union {
#declare I=I+1;
#end

whatever

#declare I=0;
#while (I<10)
}
#declare I=I+1;
#end

Just as bad as #macro abuse.

Post a reply to this message

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

Post a reply to this message

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

  Being able to *read* object data would at least be very useful, for
example to export the scene to some file format.

  Modifying the object could be useful at least with meshes. If support
for modifying meshes is added, why limit it there?

-- 
                                                          - Warp

Post a reply to this message

In article <4705eeb7$1@news.povray.org>, 
fab### [at] yourshoesskynetbe says...

> 
> > 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. POV4 should be easy to understand in it's most basic declarative
 
> > form. Which in my opinion means that objects as virtual representations
 
> > of things visible in your scene will have a different status and 
> > different syntax than all other 'objects'. Borrowing standard OOP 
> > language may be rather confusing in that respect.
> 
> Sure, there's something to find to avoid that kind of cumbersome syntax.
> 
> I don't tkink anyone around here would like to make an object's definitio
n
> so complicated.  There should be some kind of shortcuts, looking like
> current SDL.
> 
> Fabien.
> 
What we need is something "between" the extremes. Something that allows 
you to look at the sub-levels of an object in the parts of the SDL that 
handle execution and looping, etc., which still keeping the "creation" 
of the object reasonably distinct.

Lets put it another way. In stuff like VB and others you can do 
something like:

typedef fred
  jim as integer
  nosh as string * 2
endtype

dim gg as fred

Then when you *used* that, you gain the ability to do:

gg.jim = 5

Same thing here, in theory. The initial creation of an object doesn't 
need to fundamentally change at all, just how the "code" level of the 
SDL "sees" the object once it exists. 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?

Please, some one explain to me why this is supposed to be a horrible 
idea, or requires some silly, "new object s;", BS to do anything. At 
worst it wouldn't make sense to use it to do anything but make copies of 
existing objects, at best, its redundant for even that, since its much 
easier to use another declare to produce a new name for it. Point being, 
some thought may been to go into how to handle multiple objects in 
enumerations/arrays, such as when generating them through a trace, so 
that you have the same level of access to specific objects. Such as 
liking the position of 49 of 50 trees that get "planted" by it, but 
needing to make some minor change to the 50th. You could do that "in" 
the trace loop, or you could do it "after", by just referencing that 
specific tree in an array. Both would work, but in some cases the later 
"might" be more useful, if for no other reason than clearly setting the 
statement that makes the change some place other than in your loop, you 
could make it more "visible" to someone looking for such adjustments. 
Puting the code to make minor adjustments in the middle of the same mess 
that generates what you are adjusting could obfuscate "both" the changes 
and the code doing the generation, if you have to make a number of such 
changes.

And yeah, I know, there are bound to be lots of examples of how you 
could do it some other way. Ok, here is something, for this example. You 
have something that you want, in an animation, to zip back and forth 
between "random" trees in your trace. You do a) keep a list of the 
locations for every tree, so you can pick random ones from "that", or 
keep an array of the trees, so all you need to do is look at the 
location of tree 14, 3, 7, then 12, etc., from the trees themselves? 
Again, you could do it either way, but one of those is going to a) slow 
the parse a bit more, and b) take more memory to store redundant 
information.

Anyway...

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

> 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