>  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


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