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

In article <38CBBF97.2956477D@pacbell.net>, lin### [at] povrayorg 
wrote:

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

That is what I am thinking of, except my idea is to use a separate 
parser/interpreter utility to convert to POV(this utility could 
incorporate an editor and a way to call POV to render the scene, 
although these would be platform dependant features), and I understand 
the Java binding idea as a set of programming tools that form a 
framework to develop complex includes in Java, you would plug your parts 
into the framework, run the program, and get a POV scene as output. I 
personally prefer the idea of a simplified, clean, flexible language 
designed for scene description.

The translator utility in it's most basic form would take a text CSDL 
file, read through the description language, and convert structures like 
for(), do{}while(), and while() loops to #while() loops, do "name 
mangling" to simulate the attaching of variables/function-macros to 
specific objects, simulate the behavior of pointers, expand += to = A + 
B, and so on. The output file would probably not be particularly easy to 
read, but the CSDL code would be much easier to understand than the 
equivalent POV-Script code written by a human.

There should probably also be an option to "pre-parse" sections of the 
code, expanding loops and recursive functions and outputting the 
results. That could greatly speed up parsing of the POV file, and the 
translator utility would likely do the job faster than the POV-Ray 
parser(which hasn't been designed for this type of thing from the start, 
and has to do other things like allocate memory and set up data 
structures).

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

Post a reply to this message

Bill DeWitt wrote:

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

OK.
Well, it seems you have been misinformed. C++ has some horribly ugly things
that are intentionally kept out of Java, while C++ had to keep back-wards
compatibility with C and also add new OO support.

Some have said that C is "just sugar coated assembly", and the feel is close.
C++ tends to be for more of that approach, while Java goes for a more
abstractly clean approach. So Java programmers and C++ programmers are working
in two different worlds, with two different views.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message