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

In article <3A1### [at] nigelscom>, nig### [at] nigelscom wrote:

> > A lot of people (including me) would disagree with you...
> 
> Only you, apparently.  :-)

Why? Because nobody piped up with "me too" posts in a mostly 
programmers-only group?
I will post a message in povray.general, that way we will see what 
people think.

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

On Wed, 15 Nov 2000 22:20:03 +1100, Nigel Stewart wrote:
>
>> A lot of people (including me) would disagree with you...
>
>Only you, apparently.  :-)

No, we just didn't know there was a vote.

IMHO, the parser is a necessary evil, and well implemented, but the 
rendering engine is solid and well-done as well and would be useful even
without the fine parser.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message