Hi!

I moved this here from povray.off-topic, since it was getting more and
more on-topic (and also being related to the much discussed "The
Language of POV-Ray" thread).

Chris Huff made the suggestion of creating some sort of POV-CSDL ("C
like Scene Description Language") in the thread "Programming in
Highshool" in off-topic. That would be a language based on C or C++ to
be used to create POV-scenes. The scene would then be run through a sort
of "compiler" to create a "real" POV-Script from it.
The idea was, that only the "programmers" among us would want to write
CSDL scripts (for example for complex includes/plug-ins) and that normal
users could simply include the produced "normal" POV-Script into their
scenes, not having to worry about the CSDL at all - they could simply
ignore that part.
A CSDL plug-in would thus be published as two sources: A CSDL source and
a POV-Script source. "Programmers" could use the CSDL source to modify
the plugin to their own needs, and "Users" could use the POV-Script
(compiled from the CSDL) to use the plug-in in their scenes.
Sounds like a good compromise to me, having all the arguments from "The
Language of POV-Ray" in mind.

However, I think the approach can be made a lot easier, by not creating
a new language that would need a parser and compiler, but by simply
creating a binding in an already existing language. In the original
thread someone pointed out the efforts to create a Perl binding.
Personally I don't like Perl ;) but this whole thing reminded me of a
topic I brought up a while ago: A Java binding of POV.

Back then I realized that this would be a fully academic exercise, since
it was clear that no-one would actually program scenes in a POV-Java
binding.
But under the new light of using the binding to create
"high-level-language" plugins, that can still be used by "normal" users
without the need to know anything about the binding, this approach
sounds again interesting (at least to me :)

Here is how it would work:

A number of packages (class libraries) would be written in Java to
support the POV-objects. A "programmer" could then use these packages to
program POV scripts (with focus on plugins, not on full scenes) directly
in Java, in a manner intuitive to programmers.
The resulting Java program would, if compiled and run, create a standard
POV-Script plugin which could be included into any POV-Scene, and which
would contain any macro and object created in the Java-Script.
The programmer could publish both the Java code (to make his plugin
modifiable by other programmers) and the resulting POV-Scene (to make
the plugin usable by "normal" users) (usually both would be published
together).

The advantage over the CSDL approach would (in my eyes) be that no "new"
language is needed. Why create a parser and compiler, if it is already
there, for example in the Java parser, compiler and runtime environment?

Chris, what do you think?

Others?

Johannes.

Post a reply to this message

Well, I personally don't like Java.
  A C++-binding would be more pleasant to me.

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

Post a reply to this message

Nieminen Juha wrote:
> 
>   Well, I personally don't like Java.
>   A C++-binding would be more pleasant to me.

It would have to be in Qbasic or I wouldn't use it.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

"Nieminen Juha" <war### [at] sarakerttunencstutfi> wrote in message
news:38cba355@news.povray.org...
>   Well, I personally don't like Java.
>   A C++-binding would be more pleasant to me.
>

    Just from a non-programmers point of view, I see as many C++ users as
Java around here, and from what I have been told is that Java can be seen as
a preparatory language for C++.

    Therefore, the Java guys should be able to use C++ with a little extra
work, and then both could have the advanced functionality of C++...

    Just repeating what I have heard.

Post a reply to this message

I have thought about that too. (ISO) C++ would certainly be more
platform independent than Java, especially since what we want is source
code level independency, not binary level independency (which is Java's
strong feature).

Johannes.

"Nieminen Juha" <war### [at] sarakerttunencstutfi> wrote in message
news:38cba355@news.povray.org...
>   Well, I personally don't like Java.
>   A C++-binding would be more pleasant to me.
>
> --
>
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*-
Warp -*/

Post a reply to this message

Johannes Hubert wrote:

>Back then I realized that this would be a fully academic exercise, since
>it was clear that no-one would actually program scenes in a POV-Java
>binding.
>

What is a binding?

Will it make it possible for a Java (or Perl) program to interact with a 
scene during parsing? Kind of a macro being executed outside POV and its 
result being used in the scene again (without writing/reading a file). 

#binding {
  perl,            //language
  "GrowTree.pl"    //file
  Age              //Data needed by GrowTree.pl
  Shadowside
  Oak
}

>The resulting Java program would, if compiled and run, create a standard
>POV-Script plugin which could be included into any POV-Scene, and which
>would contain any macro and object created in the Java-Script.

This sounds more like a program that can output a POV-file but not interact 
with POV.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

ingo wrote:

> >The resulting Java program would, if compiled and run, create a standard
> >POV-Script plugin which could be included into any POV-Scene, and which
> >would contain any macro and object created in the Java-Script.
> 
> This sounds more like a program that can output a POV-file but not interact
> with POV.

I think the idea here is to create a text based modelling/programming
environment that uses high level programming features and will output
a standard POV-Ray scene file when done. The resulting scene file will
comply with current versions of POV-Ray syntax and proceedures. I am
assuming that when the high level progamming code is parsed/compiled
it will be automagically translated into native Pov syntax easing the
development of complex include files and what not but I am still unclear
about how this will be accomplished.


-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38cb8f8b@news.povray.org>, "Johannes Hubert" 
<jht### [at] mailacom> wrote:

> The idea was, that only the "programmers" among us would want to write
> CSDL scripts (for example for complex includes/plug-ins) and that normal
> users could simply include the produced "normal" POV-Script into their
> scenes, not having to worry about the CSDL at all - they could simply
> ignore that part.
> A CSDL plug-in would thus be published as two sources: A CSDL source and
> a POV-Script source. "Programmers" could use the CSDL source to modify
> the plugin to their own needs, and "Users" could use the POV-Script
> (compiled from the CSDL) to use the plug-in in their scenes.
> Sounds like a good compromise to me, having all the arguments from "The
> Language of POV-Ray" in mind.

This is a good description of what I had in mind, except that it 
wouldn't be exclusively for plugin development, and I am hoping the 
non-programmers would also want to develop scenes in it.


> A number of packages (class libraries) would be written in Java to
> support the POV-objects. A "programmer" could then use these packages to
> program POV scripts (with focus on plugins, not on full scenes) directly
> in Java, in a manner intuitive to programmers.
> The resulting Java program would, if compiled and run, create a standard
> POV-Script plugin which could be included into any POV-Scene, and which
> would contain any macro and object created in the Java-Script.
> The programmer could publish both the Java code (to make his plugin
> modifiable by other programmers) and the resulting POV-Scene (to make
> the plugin usable by "normal" users) (usually both would be published
> together).
> 
> The advantage over the CSDL approach would (in my eyes) be that no "new"
> language is needed. Why create a parser and compiler, if it is already
> there, for example in the Java parser, compiler and runtime environment?

The Java language isn't designed for scene description. CSDL could be 
used for scene description as well as plugin development, and would have 
the advantage of being designed for the purpose of describing objects in 
3D space. People who want to make scenes but want a cleaner, more 
flexible language than POV-Script could use CSDL.
ANSI/ISO C++ could be better, since it is more platform independant and 
has things like operator overloading which would make things like vector 
manipulation easier, but then people who don't know C++ would have to 
learn it. And the fact that it would require a C++ compiler would drive 
many away, more people would be willing to use a pre-compiled utility, 
especially if it includes an editor and a way to access POV on their 
platform.

Also, CSDL would be a much simpler language than C++/Java, probably 
without things like class types(you could attach variables and functions 
to specific objects, and make copies of those objects, though.). It 
would be object-oriented, but in a different way from C++ or Java, it 
would be oriented toward specific objects and their "children" instead 
of kinds of objects. It's variables, functions, expressions, loops and 
conditionals would use a C-like syntax, but some of the C types would be 
eliminated, pointers would behave themselves, and there would be 
additional types like object, vector, pigment, texture... It would be 
more strongly typed than POV-Script, but you could still do things like 
make a pigment into a texture and a float or int into a vector. 
Component parts of objects(like transform, texture, other flags and 
properties) would be accessible with dot notation.(I think the -> 
notation for pointers to objects should probably be left out)

It wouldn't be an extended C/C++/Java with additions for making scenes, 
it would be a new, cleanly designed language based on those languages, 
without all the "dirt" that POV-Script has accumulated over time, and 
designed with the purpose of describing scenes and developing plugins.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CBA3C0.3254B378@pacbell.net>, lin### [at] povrayorg 
wrote:

> It would have to be in Qbasic or I wouldn't use it.

Would you use it even if it *was* in Qbasic? :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38CBA3C0.3254B378@pacbell.net>, lin### [at] povrayorg
> wrote:
> 
> > It would have to be in Qbasic or I wouldn't use it.
> 
> Would you use it even if it *was* in Qbasic? :-)

Maybe. I have some POV-Ray object building files in .bas format that
I have never taken the time to figure out how to convert to .pov
syntax. If something could parse and convert them for me I would use
it.

A thought... Some of these files query the user for parameters during
the program run time. If added to Pov it sure would reduce the number
of predeclared variables needed in the scene.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message