 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CBBF97.2956477D@pacbell.net>, lin### [at] povray org
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
|
|
| |
| |
|
|
|
|
| |
|
|
