Ok, this is a favourite subject of mine, and also a (I hope) subject for
my Masters thesis, so I really can't keep myself from posting :)

As a POV user for almost 5 years now (and part-time comp. sci. student
<g>), I got the same idea during the development of my smoke effect
include file. I realized that very little information on the objects in
the scene is available from within POV, one example was that you
couldn't extract the current frame number during parsing and thus not
know if the current frame was the first frame - which is required since
the include uses file I/O. These kind of problems become obvious when
you write include files that needs to know certain things - they maybe
even have to alter existing objects (if that's what they're supposed to
to).

Areas where OO syntax would be useful is...well, everywhere...but let's
look at some examples. Let's say you want to make an include file that
takes care of physics modelling. Let's say you want it to make all
objects in the scene have real world gravity. You have no idea what
objects the user has in his/her scene, but you want all objects to
behave in a real world manner. Let's say there was a global array
variable called scene.objects[], and an integer value property
(scene.objects.count) of that array that held the number of objects in
the array. Then, this code could take care of the whole thing:

#declare i=0;
#while(i<scene.objects.count)
  scene.objects[i].translate(<0, -9.82*pow(clock,2) ,0>)  //well, sort
of...
  #declare i=i+1;
#end

This is just one example. You could access all objects and their
properties, as well as changing them if you wanted to. Let's say you
wanted to make a spotlight follow your camera, without having to
#declare two vector variables (not a big deal, but, anyway..). The
camera currently in use is of course accessible by scene.camera, or even
just camera, and since it (as all other POV objects) has a .location and
a .rotation attribute as well as it's own special attributes (.look_at
being one of them) you can easily describe this spotlight:

#declare MySpot=light_source{
  camera.location+<0,0.5,0>                //sets MySpot.location =
camera.location+<0,0.5,0>
  spotlight                                           //sets MySpot.type
= spotlight
   ..
  point_at camera.look_at                   //sets MySpot.point_at =
camera.look_at
}

Of course, you can now both read and write the attributes of your
object, which means you can check if MySpot.point_at equals
camera.look_at, you can change the radius of it (as well as all other
spotlights) in a loop:

#declare i=0;
#while(i<scene.objects.count)
  #if (scene.objects[i].type=spotlight)
    scene.objects[i].radius=20;
  #end
 #declare i=i+1;
#end

..as well as all other type of operations you could come up with.
Everything is now accessible, the only thing setting the limits is your
imagination.

Since there now is references and inheritance, you can now easily create
a "linked list"-type object:

#declare worm_part1=sphere{
 0, 0.5
 pigment{color rgb 1}
 ref{next}  // tells POV that this object has a reference, called "next"

}

// instead of copying the above code, let's create another object that
inherits from worm_part1:
#declare worm_part2=like worm_part1{     // IDENTIFIER = like ANCESTOR
 pigment{color rgb 0}  // leaves everything like worm_part1, except the
pigment.
}

// references can also be declared to "point" to a certain objects from
the start:
#declare worm_head=sphere{
 0, 0.5
 texture{some_texture}
 ref{next, worm_part1} // REFNAME [,OBJECT]
}

// Changing the reference of worm_part1:
#declare worm_part1.next=worm_part2;

// Let's create an explicit reference:
#declare temp_ref=ref{worm_head};

// All references are nil:ed from start (if no reference object is
given), so we now can do this:
#while(temp_ref<>nil)
 #declare temp_ref.location = temp_ref.location + <1,0,0>;
 #declare temp_ref=temp_ref.next;
#end

And of course, the new OO-POV is fully backwards compatible with the
non-OO language...so noone has to throw away their old scenes. Or learn
a new language - if you don't want to use the new features, of course.

Someone asked: "will it render/parse faster?". Answer: No - the language
itself does not affect render/parsing time. A complete C++ rewrite maybe
will, as it will allow for more efficient memory handling, but that does
not have to include a new syntax.

So...these are just some ideas, that still are very much on the
"ideas"-stage. I would really enjoy to do this as part of my masters
thesis research, the only problem is what scientific approach I should
have. (Possibly: creating a new method for developing an OO-language)
All ideas are welcome...


----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message