 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] sarakerttunen cstutfi> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CBC8F6.8B481E2A@pacbell.net>, lin### [at] povrayorg
wrote:
> 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.
Are you talking about some kind of "query_user()" function that would
pop up a dialog or a console input for the person rendering the file to
enter values? Something like:
#declare Name = query_user("Please enter your name: ");
I don't think that would be a good idea. What if it pops up after 15
minutes of parsing, and you left the computer going over the weekend
expecting to have an animation finished when you got back? You would get
back to your computer, only to discover it has been waiting for you to
enter a value for the whole weekend.
Besides, it could be a real pain to set those for every single little
test render.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> 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).
See item two below but the rest is worthy of note as well
From Chris Young's announcement:
...I'll just say that we came very close to deciding to go ahead and
implement a binary format despite the difficult technical problems
and limited usefulness. As we began to discuss the details however,
we soon concluded that the benefits were not worth the effort. The
POV-Ray language in most respects isn't really that hard to parse
in its current form. Two issues make it complicated. POV-Ray 3.1
language isn't hard to parse but the 3.0, 2.0 and 1.0 languages are
difficult to parse simultaneously. Also directives such as #if, #while,
#declare, #macro etc. can appear almost anywhere and THAT is hard to deal
with. We decided on the following items which we will work on as time and
manpower permit:
1) I will be writing an official technical document that describes the
POV-Ray language from a parser-writer's point of view. It will include a
grammar specification using the syntax notation in our reference docs. It
should be helpful to anyone who wants to implement their own parser.
2) We will eventually write a separate utility or an optional feature in
POV-Ray itself to translate (as much as possible) a version 1.0, 2.x or 3.0
scene into 3.1 scene and to possibly unroll loops, resolve conditionals and
expand macros. This will allow you to create a much more easy-to-parse
scene.
3) We will continue to look for ways to make parsing faster and easier and
will look for other methods to assist utility authors needs in regards to
the language.
--
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 <8EF5AE4F2seed7@204.213.191.228>, ing### [at] homenl (ingo)
wrote:
> 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
> }
I think the obvious security problems with this would keep it from being
included in the official version.
> >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.
My idea is a program that in it's most basic form would take an input
CSDL file and some parameters, and output a POV file(or several POV
files). It could be extended for each platform to allow it to interact
directly with POV, for example, having a GUI editor with a render
command which automatically translates and renders a scene. But the
basic version would be written in ANSI/ISO C++ and would be directly
portable to any platform with a compiler for that language.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz <jon### [at] geocitiescom> wrote:
: 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.
The fact that it has ugly things doesn't mean you have to use them.
When I try to code with Java I feel more like I am being limited and that
handy features that I would like to use to make my work easier have been
taken out, thus making my life harder. Many times some handy shortcuts in C++
(like typedef, enum, etc) have been left out of Java, and altough you can
do the same thing with other ways, it's usually a lot of extra work (for
example defining lots of const variables with their initial values instead
of just typing their names into an enum). They are often little things, but
annoying nevertheless.
Here are some annoyances about Java I have found that usually forces you
to make _BAD_ code:
- The enum type has been left out:
This means that you have to define a series of values by declaring constant
variables with their respective initial values. If you want to add a new
name in the middle, you have to change the numeration of the rest of the
names.
The order of the numeration can be important, for example when sorting or
if the names are someway hierarchically defined.
- The typedef declaration has been left out:
Which means that you must use the specific data type when making the code,
instead of using an 'alias' type. This means that if you want to _change_
that data type later, you have to do it in _tons_ of places instead of
just in one place.
Of course the most correct way is to use only class-types, which can be
modified later without needing to modify the code. However, since there's
no operator overloading, you will need to make a lot extra work to make
your code if you just want to use integers or similar. See also:
- No operator overloading:
Since you can't overload operators, you have to make all method calls
explicitly. This may be a good thing in the sense that you really see
what's happening. However this makes the code very unreadable.
Just suppose this case:
You have defined your own Complex-class type which handles complex
types. In C++ you could do something like:
Complex i(2,3),j(4,5);
i = (i*j) + (i/j)*3 + j/2;
In Java, since we don't have operator overloading, all that has to be
done with method calls, like this:
Complex i(2,3),j(4,5);
i.set(Complex.sum(Complex.sum(Complex.mul(i, j),
Complex.mul(Complex.div(i, j), 3)), Complex.div(j, 2)));
Which one is more readable? Which one is easier to debug?
It also makes copying one class instance into another more difficult
(specially if the class has many variables).
- There is multiple inheritance of interfaces, but not multiple inheritance
of classes:
I just ask why? Why you are allowed to inherite multiple interfaces but
not multiple classes?
Why is this bad? It's bad because if you want to inherit your class from
several interfaces (allowed in java for some reason), you will have to
implement all of their methods! If you want to inherit a certain interface
to several different classes, you will have to implement those same
methods in all of them, even if they were identical!
This means that you are copying the same code to several places, which
is a BAD THING.
At least in C++ you can specify default implementations for all methods
that are not likely to be changed in inherited classes. In Java you can't
do this if you want to inherit more than one interface.
Someone may argue that don't use multiple inheritance then. I would just
ask that why is it then possible in Java in the first place? If multiple
inheritance is such a bad thing, why is it included in Java then? And
included in a way that forces you to make bad code if you want to use it.
- Pointers has been removed.
Ok, this is a good thing if it were true. It isn't. I would say that
_everything_ in java is handled with pointers (except integer and other
basic types). Their use is limited, which is a good thing, and they are
named references. The syntax has been designed so that it hides those
references behind it.
I'm not saying that C++ is better in this way, but in my opinion this
deliberated hiding of references in the syntax makes code more prone to
confusions (at least for me).
Consider these two examples:
void F(int x)
{ x = 5;
}
void F(complex x)
{ x.set(5);
}
The syntax of the function definitions are quite the same. There's nothing
that indicates that the first function DOES NOT modify the original
variable given as parameter to the function, while the second function
DOES modify the original value.
You just have to know that it works this way.
Yes, I know C++ is full of similar things, but I'm not saying that C++
is better in this way. In this specific case it might be a little better,
in my opinion.
- No templates:
You have to make separate functions to handle classes and basic types.
You can't make generic functions that work with everything (eg. swap).
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoocom> wrote:
: Also, CSDL would be a much simpler language than C++/Java, probably
: without things like class types
Why is this obsession about "if there's an extra feature, everyone must
learn it and use it"?
If there is a feature, you DON'T HAVE TO USE IT if you don't want to.
However it's good it is there in case someone more advanced wants to use
it and take whole advantage of the language.
I'm just wondering about this obsession. "For-loops in povray would just
make the syntax more complicated", "+= operators would just save some
characters", "do-until-loops are not needed since we have while-loops",
"classes will make CSDL too complicated", and so on and so on.
It's like adding a new feature to the syntax would require everyone to
learn it.
Perhaps a set of C++-libraries to make easier to create pov-files would be
good.
--
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:
> I'm just wondering about this obsession. "For-loops in povray would just
> make the syntax more complicated", "+= operators would just save some
> characters", "do-until-loops are not needed since we have while-loops",
> "classes will make CSDL too complicated", and so on and so on.
> It's like adding a new feature to the syntax would require everyone to
> learn it.
Wrong thread but...
I think the program could do with less programming related features and
should concentrate more on object oriented features like more patterns,
more object types, and more and better special effects. If you had these
already present in the program you wouldn't need all of the special
programming related features to try to get the program to do what you
want it to. After all POV-Ray is about making pretty pictures and is
not a play toy for programmers. Before firing off a heated response
think about what I have said.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: After all POV-Ray is about making pretty pictures and is
: not a play toy for programmers.
Too often I think about povray as a mathematical visualization tool instead
of a renderer which is used to make artistic images.
Sorry :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>> #binding {
>> perl, //language
>> "GrowTree.pl" //file
>
>I think the obvious security problems with this would keep it from being
>included in the official version.
If the script/program is not a binary but a human readable file, I see no
more problems with it than with the POV language.
>My idea is a program that in it's most basic form would take an input
>CSDL file and some parameters, and output a POV file(or several POV
>files).
Although it's only output is a mesh, have you ever looked at Steve's Object
Builder? http://www.carr.lib.md.us/~stevensl/
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CBE442.C4C2F034@pacbell.net>, lin### [at] povrayorg
wrote:
> After all POV-Ray is about making pretty pictures and is not a play
> toy for programmers.
Actually, I think it *is* a play toy for programmers. Think about it:
written by unpaid people in their spare time as recreation, source code
freely available, all the patches that have been written...
It is also a play toy for 3D graphics amateurs, a math visualization
tool, a simple simulator(which could be made a much better simulator
with those "programming" additions you are so against), and many other
things.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38cbe304@news.povray.org>, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:
> "classes will make CSDL too complicated", and so on and so on.
Actually, I just don't think they are needed. In the syntax I am working
on, there would be an "object" type, which could be a sphere, box,
cylinder, or whatever. This "object" could also have attached variables
and functions. Copies of this object would get copies of the variables
and access to the same functions, similar to inheritance, and you could
add overriding functions to the copies. You could get something close to
a class by using a "union" to hold the variables and functions. The main
difference is that actual objects are manipulated instead of types, a
separate "class" type doesn't seem necessary.
It is still object-oriented, but in a different way that makes Java and
C++ look more like "object-type oriented".
> Perhaps a set of C++-libraries to make easier to create pov-files would
> be good.
A set of C++ classes which are freely available would be very useful in
developing many utilities. I have a 3d vector class which I might
donate...but this doesn't fill the same purpose CSDL would.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm just wondering about this obsession. "For-loops in povray would just
>make the syntax more complicated", "+= operators would just save some
>characters", "do-until-loops are not needed since we have while-loops",
>"classes will make CSDL too complicated", and so on and so on.
That is *exactly* the kind of reaction I got when I suggested those things a
year ago. I don't care if other people don't like it. Don't like, don't use
it. I know I will. The one I would like a lot is
I++;
instead of... um, let me rephrase that... in addition to
I = I + 1;
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>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.
Oh, now I get it. I like it. I would also like to code with this new
language. I thought you were going to somehow write your POV scenes in a
pre-existing language. I was trying to figure out how you'd do that. It
would be something in the direction of MEL (Maya) or MAX-script (3DSM). I
like it, I like it. Hop to it!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> After all POV-Ray is about making pretty pictures and is
> not a play toy for programmers. Before firing off a heated response
> think about what I have said.
>
Actually, it's both :^)
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <8EF5C9340seed7@204.213.191.228>, ing### [at] homenl (ingo)
wrote:
> If the script/program is not a binary but a human readable file, I see no
> more problems with it than with the POV language.
Maybe...
> >My idea is a program that in it's most basic form would take an input
> >CSDL file and some parameters, and output a POV file(or several POV
> >files).
>
> Although it's only output is a mesh, have you ever looked at Steve's
> Object Builder? http://www.carr.lib.md.us/~stevensl/
I remember seeing that web page...I don't like Perl though, at least not
for this. It seems even harder to read than POV-Script, and not designed
for the purpose of describing scenes. Even some of the "easy to read"
examples on the Perl web page look hard to understand. But Steve's
Object Builder does fill some of the same needs CSDL would.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> Actually, I think it *is* a play toy for programmers. Think about it...
>
Now I have to disagree with you. See for instance:
http://www.irtc.org/ftp/pub/stills/2000-02-29/abandbld.jpg
And quoted from the povdoc:
1.1 Program Description
The Persistence of Vision™ Ray-Tracer creates three-dimensional,
photo-realistic images using a rendering technique called ray-tracing. It
reads in a text file ...
My point is that there are people getting very good results in this
direction.
Regards, Alberto.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38cbf689@news.povray.org>, "TonyB"
<ben### [at] panamac-comnet> wrote:
> That is *exactly* the kind of reaction I got when I suggested those
> things a year ago. I don't care if other people don't like it. Don't
> like, don't use it. I know I will. The one I would like a lot is
>
> I++;
>
> instead of... um, let me rephrase that... in addition to
>
> I = I + 1;
I think the only way to do that and also allow prefix and postfix uses
of the ++ and -- operator would be to totally change the syntax of POV
variables. Otherwise, you would end up with ugly little inconsistancies
all over the place.
However, I think they would probably fit in quite well with CSDL...
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CBCC8D.CA8FB7CB@pacbell.net>, lin### [at] povrayorg
wrote:
> See item two below but the rest is worthy of note as well
> 2) We will eventually write a separate utility or an optional feature
> in POV-Ray itself to translate (as much as possible) a version 1.0,
> 2.x or 3.0 scene into 3.1 scene and to possibly unroll loops, resolve
> conditionals and expand macros. This will allow you to create a much
> more easy-to-parse scene.
Yes, the CSDL translator would be very similar to this, although it
wouldn't use older versions of POV for input, but a new language. It
could probably be made to parse much faster than POV, because it would
be dedicated to one job(translation) and wouldn't have to support older
versions of the language, and would be designed from the start as a
programming language(instead of having those capabilities added on
later).
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CBF99D.9183AE4E@usb.ve>, jac### [at] usbve wrote:
> > Actually, I think it *is* a play toy for programmers. Think about it...
> >
>
> Now I have to disagree with you.
> ...
> My point is that there are people getting very good results in this
> direction.
Note that I also said: "It is also a play toy for 3D graphics
amateurs..."
When I said "amateurs", I was referring to people who are working with
it in their free time. As in:
"amateur 1. one that has a marked fondness, liking or taste. 2. one that
engages in a particular pursuit, study or science as a pastime rather
than as a profession"
-- From Webster's 3rd unabridged
Also note that I said it had many other uses.
It *is* a play toy for programmers. That isn't the only thing it is, but
it is one of them, and perhaps the main thing it started out as.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris: Have you thought about adding CSDL directly into a patched
version of POV-Ray?
Like some sort of preprocessor.
A POV-Script could for example look like this:
#include "colors.inc"
#include "textures.inc"
camera {
// whatever...
}
background { color MidnightBlue }
plane {
// whatever...
}
// etc.
#begin_csdl
// CSDL code
// (in a yet to be defined syntax)
// goes here...
#end_csdl
sphere {
// whatever
}
#begin_csdl
// some more
// CSDL code here...
#end_csdl
box {
// whatever
}
// etc.
The pached version would then first scan the script for "#begin_csdl ...
#end_csdl" blocks (in all include-files too) and would "translate" them
to real POV-script and replace the blocks with their corresponding
POV-script code. The resulting script would then be handed to the
standard POV-parser, who would never even see (or know about) the CSDL
code.
Users that don't want to use the CSDL code don't have to. And usage of a
plugin written in CSDL would be nothing more than an "#include"
statement, where the whole "#begin_csdl" etc. would be in the include
file.
One small problem: Parsing will be slower, since first the CSDL code
needs to be parsed and translated, before finally POV-ray has to parse
the result.
However, a caching scheme to re-use the translation of previously parsed
and unchanged CSDL blocks could certainly be implemented.
Johannes
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38cc170a@news.povray.org>, "Johannes Hubert"
<jht### [at] mailacom> wrote:
> Chris: Have you thought about adding CSDL directly into a patched
> version of POV-Ray?
>
> Like some sort of preprocessor.
> ...
> The pached version would then first scan the script for "#begin_csdl ...
> #end_csdl" blocks (in all include-files too) and would "translate" them
> to real POV-script and replace the blocks with their corresponding
> POV-script code. The resulting script would then be handed to the
> standard POV-parser, who would never even see (or know about) the CSDL
> code.
>
> Users that don't want to use the CSDL code don't have to. And usage of a
> plugin written in CSDL would be nothing more than an "#include"
> statement, where the whole "#begin_csdl" etc. would be in the include
> file.
>
> One small problem: Parsing will be slower, since first the CSDL code
> needs to be parsed and translated, before finally POV-ray has to parse
> the result.
> However, a caching scheme to re-use the translation of previously parsed
> and unchanged CSDL blocks could certainly be implemented.
Hmm. The first problem: I am writing this in C++, POV is written in C.
The second one: I don't know enough about the parser to attempt anything
like this. It is a good idea for blending the two together, though.
Maybe someone else can do it, or maybe I can do it when POV is rewritten
in C++.
And of course, as you mentioned, parsing would be slower, even slower
than ordinary POV code. One of the biggest advantages of a separate
translator would be that the translator program could be significantly
faster than the POV-Script parser, and could output code that would
parse faster than it's human-written POV-Script equivalent(it could do
this by unrolling loops, etc). A way to avoid re-translating by caching
translated versions might be possible, but it is way beyond my
capabilities.
I am working on a definition of a possible syntax, I will probably
eventually post it in povray.off-topic to keep from wasting server
space(because there will probably be several revisions).
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99->
> Hmm. The first problem: I am writing this in C++, POV is written in C.
Blending C++ and C is not too hard...
> The second one: I don't know enough about the parser to attempt
anything
> like this.
No, what I mean is this: Don't interfere with the POV-parser at all,
just at the very first function call, where the POV-parser is initially
called:
Here, insert a call to your own parser code which pre-translates the
code it reads from the input file *before* passing it to the standard
POV-parser.
For this, you can leave the POV-parser totally alone.
This is also why I mean that blending C and C++ isn't too hard: Between
your code and the rest of the POV code there would be only one single
function call to a global function in your module, which is passed the
current script as a parameter, and which returns the same script, but
with all CSDL blocks replaced by their POV equivalents.
> And of course, as you mentioned, parsing would be slower, even slower
> than ordinary POV code. One of the biggest advantages of a separate
> translator would be that the translator program could be significantly
> faster than the POV-Script parser, and could output code that would
> parse faster than it's human-written POV-Script equivalent(it could do
> this by unrolling loops, etc).
All this can still happen. Meaning: Your "preparser" can still be faster
than the POV-parser (if you achieve that), and the code it outputs can
still be faster for POV to parse than human written (and readable) code
(for the same objects) would be.
It is slower only because the CSDL code has to be parsed each time you
run the script through the patched POV. If using a separate tool, then
the CSDL code is parsed and translated only once, when you run the tool,
and is then saved into a POV-INC file which can be used many times by an
unpatched POV without the need to CSDL-parse it again (of course it
would still go through the standard POV parse).
If the CSDL parser was integrated into POV (as a step before the
standard parser) it would need to CSDL-parse the script each time - this
is the disadvantage I meant.
Probably the best step is to do a separate tool like you are planning
now, and see how it gets accepted. If people like it, integrating it
into a POV patch (the mega-patch?) would be a great idea, I think.
> I am working on a definition of a possible syntax, I will probably
> eventually post it in povray.off-topic to keep from wasting server
> space(because there will probably be several revisions).
This is an interesting project. I would be happy to offer any help I can
give (both in the language design and/or programming).
Greetings,
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> After all POV-Ray is about making pretty pictures and is
> not a play toy for programmers. Before firing off a heated response
> think about what I have said.
>
The two are not mutually exclusive, you know. I often do programmatically
generated scenes (mainly because the random number generator has more
inspiration than I do :)
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
>
> Why is this obsession about "if there's an extra feature, everyone must
> learn it and use it"?
> If there is a feature, you DON'T HAVE TO USE IT if you don't want to.
> However it's good it is there in case someone more advanced wants to use
> it and take whole advantage of the language.
>
I have no problem with extra features - provided there is someone willing to
implement them properly and in a thought-out manner.
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> Jon A. Cruz <jon### [at] geocitiescom> wrote:
> : 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.
>
> The fact that it has ugly things doesn't mean you have to use them.
>
> When I try to code with Java I feel more like I am being limited and that
> handy features that I would like to use to make my work easier have been
> taken out, thus making my life harder. Many times some handy shortcuts in C++
> (like typedef, enum, etc) have been left out of Java, and altough you can
> do the same thing with other ways, it's usually a lot of extra work (for
> example defining lots of const variables with their initial values instead
> of just typing their names into an enum). They are often little things, but
> annoying nevertheless.
>
> Here are some annoyances about Java I have found that usually forces you
> to make _BAD_ code:
Guess what? Those are many things that I specifically like about Java, and think
they help you to write good code:
> - The enum type has been left out:
> This means that you have to define a series of values by declaring constant
> variables with their respective initial values. If you want to add a new
> name in the middle, you have to change the numeration of the rest of the
> names.
> The order of the numeration can be important, for example when sorting or
> if the names are someway hierarchically defined.
This one is maybe so-so. I've seen it used well, but then again I've seen it
abused. From a C++ viewpoint it's a minus, but from different design views you
don't miss it. But it is maybe a point of style.
> - The typedef declaration has been left out:
> Which means that you must use the specific data type when making the code,
> instead of using an 'alias' type. This means that if you want to _change_
> that data type later, you have to do it in _tons_ of places instead of
> just in one place.
> Of course the most correct way is to use only class-types, which can be
> modified later without needing to modify the code. However, since there's
> no operator overloading, you will need to make a lot extra work to make
> your code if you just want to use integers or similar. See also:
Well, if you know your C++ spec well ('you' in general, not 'you Warp', you'll
remember that a typedef in C++ is just a class with no methods (or something close
to that). So Java pretty much has it the same. It boils down to just missing a
macro processor.
Also, in Java you can specify an Interface or an abstract base class instead of a
typedef.
> - No operator overloading:
Good if used by a very decent expert programmer. Otherwise I've seen far more evil
done with operator overloading. Especially if someone comes in to do maintenance
on a large project later on. Overloaded operators make things a lot harder to read
if any of the original coders overloaded something that someone didn't expect.
> - There is multiple inheritance of interfaces, but not multiple inheritance
> of classes:
Bad. Can be very powerfull in the hands of an expert, but then far more damage can
be done by it's use.
> - Pointers has been removed.
> void F(int x)
> { x = 5;
> }
>
> void F(complex x)
> { x.set(5);
> }
>
> The syntax of the function definitions are quite the same. There's nothing
> that indicates that the first function DOES NOT modify the original
> variable given as parameter to the function, while the second function
> DOES modify the original value.
Actually, it's quite clear. In Java all primitives are passed by value. Thus, the
first example is quite clear that it can't change the thing that came in. From a
Java programming mindset, it's very simple. As opposed to C++ where these would do
two different things:
void F(int x)
{ x = 5;
}
void F(int &x)
{ x = 5;
}
void F(int *x)
{ *x = 5;
}
In that case the first should work just like in Java. Of course in C++ the first
two are both called the same, so then it gets a little harder to keep track of.
> - No templates:
Again, a very good thing.
Probably boils down to that you have to think in Java to use Java well, and think
in C++ to use C++ well.
Also, giving up some of that complex flexibility to get a thirty second compile
instead of a fifty minute compile is another thing I like. But to be fair that
fifty minute C++ compile was for MSVC COM stuff using ATL. Not all C++ is that
hard or inneficient to build.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PoD wrote:
> Ken wrote:
> >
> > After all POV-Ray is about making pretty pictures and is
> > not a play toy for programmers. Before firing off a heated response
> > think about what I have said.
> >
>
> Actually, it's both :^)
>
> PoD.
A floor wax _and_ a desert topping???
Cool.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, Chris I think now I understand your point.
Let me say that I would like to see the POV-CSDL in action in the way you
described it in
>...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)...
Regards, Alberto.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz <jon### [at] geocitiescom> wrote:
: Guess what? Those are many things that I specifically like about Java, and think
: they help you to write good code:
I still don't understand how.
:> - The enum type has been left out:
: This one is maybe so-so. I've seen it used well, but then again I've seen it
: abused.
This is the typical answer. A feature has been left out because it can be
abused.
It makes little sense to me. Everything can be abused. I myself have written
so awful java-code that it will probably make you puke. For example one
thing that I really abused were static public class variables. Making a
variable public is a BAD THING. Making it static, and thus more or less is
a WORSE THING. Making tens of them is the WORST THING.
However public static variables have not been removed from java. Why not?
If they remove something as handy as enums, why they didn't remove that?
Actually static public class variables are a lot more dangerous than enums.
In practice they are global variables.
It makes no sense to me.
: Overloaded operators make things a lot harder to read
Again a typical answer. I said "without operator overloading you have to
make explicit method calls, which can make the code very hard to read".
The fact that you can make an operator to do something that is not
expected is NOT a reason to drop it out. In the exact same way you could
make a method called Multiply(x,y) which calculates the substraction of the
two arguments. If you can abuse method names in this way, should we drop
out method names?
: Bad. Can be very powerfull in the hands of an expert, but then far more damage can
: be done by it's use.
Again the "let's limit what a professional programmer can do in order to
prevent beginners from doing something wrong" effect.
: Actually, it's quite clear. In Java all primitives are passed by value.
No, it's not clear. There's nothing in the syntax that helps you see
whether a variable is a reference or not. At least in C++ you immediately
see from the definition of a function that "this parameter is a value and
this parameter is a reference".
On the other hand, as I said in the previous article, _everything_ in java
are references, so once you get used to that it's not so big deal (the basic
types are passed by value, but you can see it from the type of the parameter).
: Java programming mindset, it's very simple. As opposed to C++ where these would do
: two different things:
: void F(int x)
: { x = 5;
: }
: void F(int &x)
: { x = 5;
: }
I don't understand what do you mean. It can be quite clearly seen (once
you know the syntax, of course) that the second one changes the original
value while the first one doesn't.
And by the way, the second one is impossible to do in java.
:> - No templates:
: Again, a very good thing.
Why? I said why it's a bad thing. You didn't say why it would be a good
thing.
I have heard all those typical answers hundreds of times. I would like to
understand them some time.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TonyB <ben### [at] panamac-comnet> wrote:
: That is *exactly* the kind of reaction I got when I suggested those things a
: year ago.
If I remember right, I was one of those fighting agains adding a for-loop
to povray.
Well, I have grown out of that stage... :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38cc2ddc$1@news.povray.org>, "Johannes Hubert"
<jht### [at] mailacom> wrote:
> No, what I mean is this: Don't interfere with the POV-parser at all,
> just at the very first function call, where the POV-parser is initially
> called:
> Here, insert a call to your own parser code which pre-translates the
> code it reads from the input file *before* passing it to the standard
> POV-parser.
> For this, you can leave the POV-parser totally alone.
> This is also why I mean that blending C and C++ isn't too hard: Between
> your code and the rest of the POV code there would be only one single
> function call to a global function in your module, which is passed the
> current script as a parameter, and which returns the same script, but
> with all CSDL blocks replaced by their POV equivalents.
Ah, I see what you mean now. My module would be called whenever a source
file is opened. It would probably be possible to cache the translated
files in case one is included multiple times(per parse, that is. I don't
think caching from render to render would be easy.), so it doesn't have
to be translated for every time it is included.
> Probably the best step is to do a separate tool like you are planning
> now, and see how it gets accepted. If people like it, integrating it
> into a POV patch (the mega-patch?) would be a great idea, I think.
Yes, that sounds like what I have been thinking of.
> This is an interesting project. I would be happy to offer any help I can
> give (both in the language design and/or programming).
I will post a "concept sketch" of the language design in a few minutes.
It is incomplete, but should give an idea of what I am thinking.
I have never written a parser before, so that might be a little
difficult(well, a simple keyword-value thing, but that doesn't really
count). But I guess I have to learn sometime... :-)
I do have a couple ideas about parsing the language, I think it would be
easiest to parse the scene into a data structure and then have the data
structure output the POV code for each scene element.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It is perfectly possible to link C object files and C++ object files as long
as they are defined in the right way.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38ccd3af@news.povray.org>, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:
> It is perfectly possible to link C object files and C++ object files as
> long as they are defined in the right way.
I know, but it would be easier to develop the translator as a separate
program. That way I could have faster compile times, a specialized
interface for testing various portions, and I could directly see the
output translation. Both writing and testing would be faster.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
Nieminen Juha wrote:
>
> 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 -*/
I agree, I' also would prefer a C++binding, because I hate Java (don't
ask why).
Yours Axel Baune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
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? :-)
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
No I don't think so.
Axel Baune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-4039AC.06380313032000@news.povray.org...
> I will post a "concept sketch" of the language design in a few
minutes.
> It is incomplete, but should give an idea of what I am thinking.
> I have never written a parser before, so that might be a little
> difficult(well, a simple keyword-value thing, but that doesn't really
> count). But I guess I have to learn sometime... :-)
> I do have a couple ideas about parsing the language, I think it would
be
> easiest to parse the scene into a data structure and then have the
data
> structure output the POV code for each scene element.
Just don't reinvent the wheel!
Parsing and compiling is a well researched subject in computer science.
I recommend that you take a look at lex/yacc for example
One of the standard books is: "The Theory and Practice of Compiler
Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
covers everything you need...
(you probably have it already :)
Johannes
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Hubert wrote:
> 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.
One thing I am slightly confused about is if you are using a complicated
scene description language to make a new scene and then convert it to
POV-Ray won't you still be limited to what POV-Ray can actually do
proceeduraly ?
If POV-Ray can already do it proceeduraly why not do it in native Pov
in the first place ?
--
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 <38cd0388$1@news.povray.org>, "Johannes Hubert"
<jht### [at] mailacom> wrote:
> Just don't reinvent the wheel!
What if I want to learn how to make wheels? And what if I can't find a
wheel that fits?
> Parsing and compiling is a well researched subject in computer science.
> I recommend that you take a look at lex/yacc for example
While those might be good for people who want rapid development, I am
not sure they would apply in my case. I do think there is a set of
Bison/Flex(or is it Flexx?) tools for CodeWarrior, but I have never used
that kind of thing.
> One of the standard books is: "The Theory and Practice of Compiler
> Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
> covers everything you need...
> (you probably have it already :)
Actually, I don't have it. All the books I have are a couple standard
"learn C++" books:
Teach Yourself C++ in 21 Days(got this when I took C++ at school)
Programming with C++
Rescued by C++
C++ Primer Plus(this one is actually my favorite, I rarely use the
others)
And a couple C and Java books, and one Pascal book(also from a class I
took at school).
I don't have any books on algorithms or programming theory. I don't have
much money to buy them either... :-(
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CD5D57.247F8422@pacbell.net>, lin### [at] povrayorg
wrote:
> One thing I am slightly confused about is if you are using a complicated
> scene description language to make a new scene and then convert it to
> POV-Ray won't you still be limited to what POV-Ray can actually do
> proceeduraly ?
>
> If POV-Ray can already do it proceeduraly why not do it in native Pov
> in the first place ?
POV can do these things(or fake them), but to do them while restricted
to the POV syntax would take a long time and be nearly impossible to
read and understand. You could write a scene in C-SDL and then convert
to POV, but you probably wouldn't want to read the POV file, while the
C-SDL code would be much simpler and easier to read/write. For
programmers, at least. :-)
Another thing that could be done instead of or in combination with is
doing most of the parsing work in the converter and outputing a bunch of
POV objects. This would be especially useful for tree/particle system
generators. The POV file would parse much faster than the equivalent
generator written in POV-Script. Of course, this couldn't be done for
most includes...
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-DBD0D6.16302013032000@news.povray.org...
> In article <38cd0388$1@news.povray.org>, "Johannes Hubert"
> <jht### [at] mailacom> wrote:
>
> > Just don't reinvent the wheel!
>
> What if I want to learn how to make wheels? And what if I can't find a
> wheel that fits?
Find a wheel that fits? Great!
Learn how to make wheels? Good idea! But best done by learning from
examples of the pros. If you can't get a book, search on the net, there
should be loads of stuff about parser and compiler writing out there.
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
