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

Has anyone ever thought of using a straight C++ interface for POV?
It seems the language is slowly growing that way anyway but its all getting
a bit messy with more and more switches etc.
My thought is that you could define a set of standard C++ objects
corresponding to the objects POV understands. Each has a set of operations
such as object.rotate(x,y,z) and object.interior.ior(1.5)... At some point
in the code there's a call to "object.store" to download the resulting
primitives in some form the renderer understands.
Compile this in a shareware compiler and run it, then a separate renderer
can then act on the primitives generated.
Is this all too geeky?

My first posting - be gentle
Matt Webster

Post a reply to this message

In article <39f89df8@news.povray.org>, "Matthew Webster" 
<mat### [at] nospamvirginnet> wrote:

> Has anyone ever thought of using a straight C++ interface for POV?

I think a language designed for scene description would be a better 
idea. Something similar in basic syntax to C/C++/ObjC/Java, but 
simplified and modified to make scene description part of the language. 
My "CSDL" project is an example of what I am talking about...(CSDL == 
C-like Scene Description Language)


> It seems the language is slowly growing that way anyway but its all 
> getting a bit messy with more and more switches etc.

Um, it doesn't seem very C++-like to me...and what do you mean by 
switches? I don't use the #switch command very often at all...and I 
don't see what it has to do with making POV-Script more object-oriented 
or using C++.


> My thought is that you could define a set of standard C++ objects 
> corresponding to the objects POV understands. Each has a set of 
> operations such as object.rotate(x,y,z) and 
> object.interior.ior(1.5)... At some point in the code there's a call 
> to "object.store" to download the resulting primitives in some form 
> the renderer understands.
> Compile this in a shareware compiler and run it, then a separate renderer
> can then act on the primitives generated.
> Is this all too geeky?

A few things that make it a bad idea to use C++ as the POV language: 
1: Ease of use. Everyone would have to forget POV-Script and learn C++. 
Some people simply don't like C++, others don't have time, talent, or 
will to learn and use it. And even once you learn it and use it, it just 
isn't the best tool for doing many scenes.
2: Everyone would need a C++ compiler. Unless the POV-Team writes one 
for each platform and includes it with POV, they will have to go find 
some free or shareware one, figure out how to install and use it with 
what documentation they can find, and cope with differences between 
compilers.
3: Platform/development environment differences. POV always runs 
POV-Script the same way, compilers(especially free/cheap ones) often 
have odd little "issues". And then there are differences in the 
libraries...again, unless the POV-Team writes one for each platform and 
includes it with POV, these will be big problems.
4: Security. Using C++ means a POV-Script would be able to do 
*anything*. For some applications this is simply unacceptable.

However, a "POV-Library" that can emit POV-Script code would still be 
very useful for other things: utilities, complex simulations or 
calculations, etc. It just wouldn't be a good idea to use C++ as the 
main scene description language.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Matthew Webster <mat### [at] nospamvirginnet> wrote:
: Has anyone ever thought of using a straight C++ interface for POV?

  Yes. Someone has made this kind of library for C++ (I think it supported
POV 3.0 syntax when reading from a pov-file).

: such as object.rotate(x,y,z) and object.interior.ior(1.5)...

  Ugh!
  Make that: object.interior().ior(1.5); (although it may be done even better).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

It can be done when POV will be divided into two parts:
raytracer itself and parser modules. Raytracer should then
have some interface, which will be some shared library, you 
can use this library in your programs then (technically,
license is another point of discussion).

Disnel

Matthew Webster wrote:
> 
> Has anyone ever thought of using a straight C++ interface for POV?
> It seems the language is slowly growing that way anyway but its all getting
> a bit messy with more and more switches etc.
> My thought is that you could define a set of standard C++ objects
> corresponding to the objects POV understands. Each has a set of operations
> such as object.rotate(x,y,z) and object.interior.ior(1.5)... At some point
> in the code there's a call to "object.store" to download the resulting
> primitives in some form the renderer understands.
> Compile this in a shareware compiler and run it, then a separate renderer
> can then act on the primitives generated.
> Is this all too geeky?
> 
> My first posting - be gentle
> Matt Webster

Post a reply to this message

> > Has anyone ever thought of using a straight C++ interface for POV?

	Yes, and apart from being forbidden by the POV license,
	there is a great deal invested here by people in their
	POV script.

> However, a "POV-Library" that can emit POV-Script code would still be
> very useful for other things: utilities, complex simulations or
> calculations, etc. It just wouldn't be a good idea to use C++ as the
> main scene description language.

	Yes indeed, and it could form a component of POV 4.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <3A03B95C.D5C34F86@nigels.com>, nig### [at] nigelscom wrote:

> > However, a "POV-Library" that can emit POV-Script code would still be
> > very useful for other things: utilities, complex simulations or
> > calculations, etc. It just wouldn't be a good idea to use C++ as the
> > main scene description language.
> 
> 	Yes indeed, and it could form a component of POV 4.

How? What I am talking about is a framework for manipulating objects in 
C++ and outputing .pov files...nothing to do with POV-Ray itself. There 
is no reason it couldn't be done now and used with POV-Ray 3.1...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> >       Yes indeed, and it could form a component of POV 4.
> 
> How? What I am talking about is a framework for manipulating objects in
> C++ and outputing .pov files...nothing to do with POV-Ray itself. There
> is no reason it couldn't be done now and used with POV-Ray 3.1...

	Of course it would be useful for 3.1, but by the time you've
	done all the POV glue in C++, you're left with two things:
	The parser, and the raytracing code.  And really, it's
	only the parser (and control of it) that differentiates
	POV.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <3A077C3D.C5606AE0@nigels.com>, nig### [at] nigelscom wrote:

> 	Of course it would be useful for 3.1, but by the time you've
> 	done all the POV glue in C++, you're left with two things:
> 	The parser, and the raytracing code. 

Oh, you are talking about releasing the parser code separately from the 
POV core? I was talking about a library for creating .pov files, not 
reading them. I plan on starting such a project, someday...


> And really, it's only the parser (and control of it) that 
> differentiates POV.

A lot of people (including me) would disagree with you...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> A lot of people (including me) would disagree with you...

Only you, apparently.  :-)

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message