-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!

I don't know how far you are in the design process for 4.0, but assuming not 
very far at all, I just had an idea that you might like.

Rather then having some weird, limited, language with a lot of code to 
maintain, why not use some full-blown standard scripting language for scene 
description? We could have some API that the user would talk to in order to 
tell POV-Ray what stuff to put in the scene, just as we have language 
directives now.

This has several advantages:
1. The user gets a real scripting language that can do any kind of 
        calculations or functions or whatever, and can even integrate
        rendering with other tasks, automating something or other.
2. The user doesn't have to learn a new language, just a new API.
3. You get a high-quality interpeter for free. This would greatly reduce
        the size of POV-Ray, etc.

By choosing a language that has object-oriented features, you allow users
to do all kinds of fun stuff. At present, we have '.inc' files with
macros in them to do things. Put if they had classes in them, that
knew how to do things, such as animating themselves, or interacting
with others, the door is opened to many interesting and usefull
possibilities. Imagine describing large scenes in terms of high-level
objects that interacted and animated themeselves based on internal 
procedures. The possibilities here are great.

But I digress. Of course, that which I have just briefly described could be 
accomplished using a specialized language. The advantage of a normal 
language is that everyone gets stuff for free.

Anyway, my nominations for the language are (in this order):

1. Ruby
2. Python
3. Java

Look at his hypothetical Ruby snippet:


add Camera.new Vector.new(3,5,-10), Vector.new(0,0,0)
add PointLightSource.new Vector.new(30,30,-30), White.vector
add Plane.new x, -2, Texture.new( CheckerPigment(Black.vector,Red.vector) )
add Sphere.new Vector.new(0,0,0), 2, Texture.new(Yellow.pigment)
add SkySphere.new( GradientPigment( y, Colormap.new([0,SkyBlue.vector], \
        [1,Blue.vector])))
render


...Hmm, that looks a bit clunky; we'll try getting rid of the Vectors...


add Camera.new 3,5,-10, 0,0,0
add PointLightSource.new 30,30,-30, White
add Plane.new x, -2, Texture.new( CheckerPigment(Black,Red) )
add Sphere.new 0,0,0, 2, Texture.new( ColorPigment(Yellow) )
add SkySphere.new( GradientPigment( y, [0=>SkyBlue,1=>Blue] ) )
render

...rather than:


camera
{
        location <3,5,-10>
        look_at <0,0,0>
}

light_source
{
        <30,30,-30>,
        color White
}

plane
{
        x,-2
        texture
        {
                pigment{ checker Black Red }
        }
}

sphere
{
        <0,0,0>,2
        texture
        {
                pigment{ color Yellow }
        }
}

skysphere
{
        pigment
        {
                gradient y
                color_map
                {
                        [0 color SkyBlue]
                        [1 color Blue]
                }
        }
}

...Anyway, you get the idea of what it would look like. But it's really 
about being able to do any sort of task or calculation when making the 
scene.


Well, maybe you've all just been enlightened with a blinding stroke of 
genius, or maybe someone else has already suggested this, or maybe it's the 
stupidest thing ever. Anyhoo, I thought I'd mention it to you who know more 
than I do. Thanks for listening.

- -- 
David McCabe
http://12.225.144.95/pgpkey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9iV801bgGCL1rO04RAtLIAKDJqYTkESKHd36pK3xmkHDvsZy5gwCfc4XC
jSWQUlpGu/fRVqHJkFZJpKA=
=ZZQk
-----END PGP SIGNATURE-----

Post a reply to this message

Where actually did you see "some weird, limited, language" ?
Do you write about POV 3.5 or did you  intermix something with
your JAVA / C++ Code-Book (hehehe) ? :-)

--Theo

----------------------------------------------------------------------------
---------------------------------
Distributed Network-Rendering or Local SMP-Rendering on all CPU's you have.
With SMPOV und POV-Ray 3.5. Download free at:
http://www.it-berater.org/smpov.htm

Post a reply to this message

In article <3d895e0d@news.povray.org> , David McCabe 
<dav### [at] myrealboxcom>  wrote:

> Rather then having some weird, limited, language with a lot of code to
> maintain, why not use some full-blown standard scripting language for scene
> description? We could have some API that the user would talk to in order to
> tell POV-Ray what stuff to put in the scene, just as we have language
> directives now.

Not again this discussion, please.  Look at the discussion of the past one
to two years and you will see this idea comes up about every three month or
so.  So look for all the arguments for and against it in those threads.


    Thorsten

Post a reply to this message

Here are a few (not all, there have been other such discussions in other 
groups as well!), in no particular order:

From: "Vadim Sytnikov" <syt### [at] rucom>
Newsgroups: povray.programming
Subject: hash marks
Date: Tue, 12 Mar 2002 20:11:12 +0300
Message-ID: <3c8e36b2@news.povray.org>
Xref: news.povray.org povray.programming:5894


From: "Roberto Ferrer de Amorim" <ram### [at] comdescontocombr>
Newsgroups: povray.programming
Subject: Python and POVRay
Date: Mon, 12 Mar 2001 12:30:43 -0300
Message-ID: <3aacebd9$1@news.povray.org>
Xref: news.povray.org povray.programming:5163


From: ken### [at] uniplanit (Angelo 'kENpEX' Pesce)
Newsgroups: povray.programming
Subject: Povray 4? wish list
Date: Mon, 03 Dec 2001 17:20:19 GMT
Message-ID: <3c0baf07.22135953@news.povray.org>
Xref: news.povray.org povray.programming:5465


From: "Arie L. Stavchansky" <ari### [at] bellatlanticnet>
Newsgroups: povray.programming
Subject: Question about future version and coding
Date: Thu, 4 Oct 2001 10:16:16 -0400
Message-ID: <3bbc6f18@news.povray.org>
Xref: news.povray.org povray.programming:5372


Message-ID: <39747AD8.E2567B43@itam.cas.cz>
Date: Tue, 18 Jul 2000 17:42:16 +0200
From: Vaclav Cermak <dis### [at] itamcascz>
Newsgroups: povray.programming
Subject: Object oriented POV scene language?
Xref: news.povray.org povray.programming:4483


Message-ID: <399C8823.DD03EB6F@vrml.k12.la.us>
Date: Thu, 17 Aug 2000 17:49:39 -0700
From: Abe Heckenbach <abe### [at] vrmlk12laus>
Newsgroups: povray.programming,povray.general
Subject: object oriented features
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Xref: news.povray.org povray.programming:4620 povray.general:23862

Post a reply to this message

In article <3d895e0d@news.povray.org>,
 David McCabe <dav### [at] myrealboxcom> wrote:

> 1. The user gets a real scripting language that can do any kind of 
>         calculations or functions or whatever, and can even integrate
>         rendering with other tasks, automating something or other.

A "real scripting language"? How is POV not "real"?
Also, there are security issues...if it can do anything, it can do 
ANYTHING.


> 2. The user doesn't have to learn a new language, just a new API.

You assume the user already knows the language. Most users of POV don't 
have any programming experience other than POV.


> 3. You get a high-quality interpeter for free. This would greatly reduce
>         the size of POV-Ray, etc.

How would it make POV smaller? Instead of POV interpreter + POV core, 
you end up with POV core + generic interpreter + lots of glue code.


> But I digress. Of course, that which I have just briefly described could be 
> accomplished using a specialized language. The advantage of a normal 
> language is that everyone gets stuff for free.

The disadvantage: you get what you get. You can then mutate it into a 
custom language, making it more suited for your purposes but harder to 
update and losing compatibility with the "official" language, or you can 
stumble along with the unmodified version.


> Anyway, my nominations for the language are (in this order):
> 
> 1. Ruby

Not really designed to be embedded in another application, possible to 
do but awkward. I think Matz is working on making this easier.


> 2. Python

***gags***


> 3. Java

Most likely for a programmer to know, probably the fastest, but I'd hate 
to use it for scene description.


As someone else mentioned, it has been discussed many, many times 
before, but I'll say this anyway: the advantage of POV-script is that it 
is built for scene description. For example: in those languages you 
either have to create a class for vectors (which makes using them clumsy 
and takes lots of typing for the simplest things) or give up vectors 
completely, using the terrible solution of specifying 3 floats all the 
time (making it hard to tell a vector from a bunch of floats and making 
vector math nearly impossible, making bugs in math code almost certain 
for things that are extremely simple in POV).

Also, you get a pre-built language that is more powerful than the 
existing POV language, which is also harder to use for the simplest 
scene description tasks which don't require any programming and harder 
for non-programmers to learn. I started CSDL/Sapphire as a scene 
description language, and though I now think it is too complex for this 
use, I think it would be far better than any of the languages you 
mentioned simply because it supports vectors.

I think any new scene description language will have to be something 
like POV: partly a simple markup language or human-editable data format, 
with a scripting language and built-in support for vectors. Object 
oriented as well...POV is almost there, it could become a 
prototype-based OOL with just a few modifications.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

I agree with everything Chris Huff said.

  Also, I don't like your tone of voice at all. For example:

> 1. The user gets a real scripting language

  So the POV-Ray does not have a real scripting language. What is it then?

  Then your example is quite unfair:

> add Camera.new 3,5,-10, 0,0,0
> add PointLightSource.new 30,30,-30, White
> add Plane.new x, -2, Texture.new( CheckerPigment(Black,Red) )
> add Sphere.new 0,0,0, 2, Texture.new( ColorPigment(Yellow) )
> add SkySphere.new( GradientPigment( y, [0=>SkyBlue,1=>Blue] ) )
> render

> ...rather than:


> camera
> {
>         location <3,5,-10>
>         look_at <0,0,0>
> }
[snip]

  First you write one-liners in the proposed language and then you write
the "equivalent" with pov sdl using a lot of whitespace, indenting and
putting every item in their own lines. It's like you wanted to trick the
readers to think that your proposition is a lot more compact and thus better,
when if fact it isn't.

  And what's all that obsession about using 'new' everywhere? As far as I
can see, every single 'new' you used in your proposition is obsolete and
unnecessary.
  You have probably coded too much in Java.

  Just a tip: When you want to make a suggestion, revise your attitude.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Excuse me. I did not in any way intend to sound rude, arrogent, or whatever. 
In fact, I think you've misinterpeted me altogether. Notice the last 
paragraph, in which I say, "maybe it's the stupidest thing ever. Anyhoo, I 
thought I'd mention it to you who know more than I do.".

By 'real', what I meant was, well, standard, or fully able to do anything, 
almost general-purpose at least, as in "PostScript is unreal (you could 
write a program in it, but it would be hard)".

The examples are not unfair; that is simply how I always style code in Ruby, 
and how I always style code in POV-SDL. In Ruby you have to do stuff to 
split things over multipal lines. But I've never seen a lot of POV-SDL code 
with everything on one line. No, everybody seems always to space and intend 
and stuff.

Anyway, please understand that my attitude is and was in no way negitive 
whatsoever.

Warp wrote:

>   I agree with everything Chris Huff said.
> 
>   Also, I don't like your tone of voice at all. For example:
> 
>> 1. The user gets a real scripting language
> 
>   So the POV-Ray does not have a real scripting language. What is it then?
> 
>   Then your example is quite unfair:
> 
>> add Camera.new 3,5,-10, 0,0,0
>> add PointLightSource.new 30,30,-30, White
>> add Plane.new x, -2, Texture.new( CheckerPigment(Black,Red) )
>> add Sphere.new 0,0,0, 2, Texture.new( ColorPigment(Yellow) )
>> add SkySphere.new( GradientPigment( y, [0=>SkyBlue,1=>Blue] ) )
>> render
> 
>> ...rather than:
> 
> 
>> camera
>> {
>>         location <3,5,-10>
>>         look_at <0,0,0>
>> }
> [snip]
> 
>   First you write one-liners in the proposed language and then you write
> the "equivalent" with pov sdl using a lot of whitespace, indenting and
> putting every item in their own lines. It's like you wanted to trick the
> readers to think that your proposition is a lot more compact and thus
> better, when if fact it isn't.
> 
>   And what's all that obsession about using 'new' everywhere? As far as I
> can see, every single 'new' you used in your proposition is obsolete and
> unnecessary.
>   You have probably coded too much in Java.
> 
>   Just a tip: When you want to make a suggestion, revise your attitude.
> 

- -- 
David McCabe
http://12.225.144.95/pgpkey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9ifTP1bgGCL1rO04RAhjmAKC5cW8/eNKIPRR212wp6Coll2AglwCfSnh5
ZSr2fdy9TKKjlSUIoDblgg8=
=VPQ/
-----END PGP SIGNATURE-----

Post a reply to this message

Christopher James Huff wrote:

> In article <3d895e0d@news.povray.org>,
>  David McCabe <dav### [at] myrealboxcom> wrote:
> 
>> 1. The user gets a real scripting language that can do any kind of
>>         calculations or functions or whatever, and can even integrate
>>         rendering with other tasks, automating something or other.
> 
> A "real scripting language"? How is POV not "real"?
> Also, there are security issues...if it can do anything, it can do
> ANYTHING.
POV is not real...because it can't do everythingor it makes it really hard. 
POV is like PostScript, which you wouldn't exactly call a scripting 
language, even though it can do that kind of thing to some degree.

Security is an issue whever you are writing a program. How is writing a 
script for POV less secure then writing a script that runs alone?

> 
> 
>> 2. The user doesn't have to learn a new language, just a new API.
> 
> You assume the user already knows the language. Most users of POV don't
> have any programming experience other than POV.
OK.

> 
> 
>> 3. You get a high-quality interpeter for free. This would greatly reduce
>>         the size of POV-Ray, etc.
> 
> How would it make POV smaller? Instead of POV interpreter + POV core,
> you end up with POV core + generic interpreter + lots of glue code.
No, the interpreter would be an *external dependency* (get used to it :-).



>> But I digress. Of course, that which I have just briefly described could
>> be accomplished using a specialized language. The advantage of a normal
>> language is that everyone gets stuff for free.
> 
> The disadvantage: you get what you get. You can then mutate it into a
> custom language, making it more suited for your purposes but harder to
> update and losing compatibility with the "official" language, or you can
> stumble along with the unmodified version.
Sure. That is a disadvantage, and a really big one too, such that it really 
kills the idea.


>> Anyway, my nominations for the language are (in this order):
>> 
>> 1. Ruby
> 
> Not really designed to be embedded in another application, possible to
> do but awkward. I think Matz is working on making this easier.
it's a good language, however. 


>> 2. Python
> 
> ***gags***
Here, here! I would prefer Java 1000 times, but the syntax would be *so* 
clunky for an SDL application.


>> 3. Java
> 
> Most likely for a programmer to know, probably the fastest, but I'd hate
> to use it for scene description.
So would I, or it would be nomination #1.

> 
> 
> As someone else mentioned, it has been discussed many, many times
> before,
Pordon me. I'm new.

> but I'll say this anyway: the advantage of POV-script is that it
> is built for scene description. For example: in those languages you
> either have to create a class for vectors (which makes using them clumsy
> and takes lots of typing for the simplest things) or give up vectors
> completely, using the terrible solution of specifying 3 floats all the
> time (making it hard to tell a vector from a bunch of floats and making
> vector math nearly impossible, making bugs in math code almost certain
> for things that are extremely simple in POV).
Yeah.

> 
> Also, you get a pre-built language that is more powerful than the
> existing POV language, which is also harder to use for the simplest
> scene description tasks which don't require any programming and harder
> for non-programmers to learn. I started CSDL/Sapphire as a scene
> description language, and though I now think it is too complex for this
> use, I think it would be far better than any of the languages you
> mentioned simply because it supports vectors.
OK.


> I think any new scene description language will have to be something
> like POV: partly a simple markup language or human-editable data format,
> with a scripting language and built-in support for vectors. Object
> oriented as well...POV is almost there, it could become a
> prototype-based OOL with just a few modifications.
Okay, that's fine. But please make sure we get good OO features.

-- 
David McCabe
http://12.225.144.95/pgpkey

Post a reply to this message

>> 2. Python
> 
> ***gags***

I agree that POV is better off with the SDL. But what do you have against 
Python in general?

Post a reply to this message

In article <3d89ffe4@news.povray.org>, Artis <art### [at] aaaapollolv> 
wrote:

> I agree that POV is better off with the SDL. But what do you have against 
> Python in general?

It's Python.
I mainly hate the significance of white space as syntax, lack of visible 
block endings, and (in my opinion) horrible attempt at OO. That and the 
rest of the language.
Python has been suggested before, read my comments in those threads. If 
POV used Python, I wouldn't use POV.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3d89f678@news.povray.org>,
 David McCabe <dav### [at] myrealboxcom> wrote:

> POV is not real...because it can't do everythingor it makes it really hard. 

That is a very bad definition of "real". 


> POV is like PostScript, which you wouldn't exactly call a scripting 
> language, even though it can do that kind of thing to some degree.

Actually, I do call PostScript a scripting language. A fairly 
well-designed and flexible one too...have you seen the PostScript 
raytracer?
Not anything I'd write an application in, but that doesn't mean it isn't 
a real language...what it does, it does well, and doesn't need to do 
more.


> Security is an issue whever you are writing a program. How is writing a 
> script for POV less secure then writing a script that runs alone?

Huh? The point is that a script for POV is more secure, not less. You 
can render a scene being fairly confident it won't destroy your system. 
Using an external language would lose that security, making things more 
difficult to secure. Not a huge drawback, but a potential problem, and 
especially necessary for applications like a web interface to the 
renderer.


> > How would it make POV smaller? Instead of POV interpreter + POV core,
> > you end up with POV core + generic interpreter + lots of glue code.
> No, the interpreter would be an *external dependency* (get used to it :-).

POV wouldn't ship with it? The user would have to download an entire 
language package ported to their platform in order to just render a 
scene? Bad idea. Extremely bad idea:

1: More platform-dependant code to maintain or port, for hooking up with 
the chosen language package.

2: Dependance on a specific version of the interpreter. No control over 
conflicts with official includes, if the interpreter or language changes 
it would force a quick release of POV just to restore compatibility, it 
is just asking for trouble.

3: Dependance on the interpreter being available and up-to-date on all 
supported platforms, making it impossible to port to platforms where the 
interpreter doesn't exist.


> > Not really designed to be embedded in another application, possible to
> > do but awkward. I think Matz is working on making this easier.
> it's a good language, however. 

I like it. It is very similar to a cleaned-up Objective C. (actually, 
more like Smalltalk, which is the main influence of Objective C)
Take this, add some syntactic sugar for defining scene entities and 
handling vectors (and get rid of some Perl-isms), and it'd be a nice 
language. You can write very concise but clear code in it.

I think something closer to Sapphire would be better though, something 
closer to the current POV language (so it is still familiar), and 
simplified (a scene description language doesn't really need regular 
expressions built-in).


> > I think any new scene description language will have to be something
> > like POV: partly a simple markup language or human-editable data format,
> > with a scripting language and built-in support for vectors. Object
> > oriented as well...POV is almost there, it could become a
> > prototype-based OOL with just a few modifications.
> Okay, that's fine. But please make sure we get good OO features.

Heh, I'm not on the design team...but the POV Team has hinted at a 
"major reworking" of the language for 4.0.

Some other languages you might look at:
Sapphire (on my web page)
A prototype-based object-oriented language with a fairly Java or C-like 
syntax. Very dynamic and flexible, built-in support for vectors, made to 
be embedded in other programs or run standalone.
Wait a while though, I've made some big changes since the last release.

Io: http://www.dekorte.com/Software/C/Io/
Very small, embeddable, pure prototype-based OO language.

Cel: http://freshmeat.net/projects/cel/?topic_id=49
Another prototype-based language (can you tell I'm interested in 
Prototype based OO? I think it applies well to this sort of problem.).

Also Lua, Self, Smalltalk, Objective C, etc...you mentioned Ruby, so 
chances are you are already familiar with at least a few of these.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

David McCabe <dav### [at] myrealboxcom> wrote:
> POV is not real...because it can't do everythingor it makes it really hard. 

  The POV-Ray SDL is a turing-complete language.
  "It's hard to use" is not a good definition of "real" scripting language.

  In fact, in some generic scripting language some things can be harder
to do than with POV-Ray SDL (ie. you need a lot more code to achieve the
same thing). Thus, "better" is always a subjective issue.

> POV is like PostScript, which you wouldn't exactly call a scripting 
> language, even though it can do that kind of thing to some degree.

  I see absolutely no reason for not calling it a scripting language.
As Chris mentioned, you can even make a raytracer with post-script (as
you can do with POV-Ray SDL, btw).

  Your definition of "scripting language" is a bit odd and quite unclear.

> Security is an issue whever you are writing a program. How is writing a 
> script for POV less secure then writing a script that runs alone?

  Have you noticed that POV-Ray 3.5 has new security settings? Have you
ever wondered why?

> No, the interpreter would be an *external dependency* (get used to it :-).

  Just one word: Portability.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

David McCabe wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Excuse me. I did not in any way intend to sound rude, arrogent, or whatever. 
> In fact, I think you've misinterpeted me altogether. Notice the last 
> paragraph, in which I say, "maybe it's the stupidest thing ever. Anyhoo, I 
> thought I'd mention it to you who know more than I do.".
> 
> By 'real', what I meant was, well, standard, or fully able to do anything, 
> almost general-purpose at least, as in "PostScript is unreal (you could 
> write a program in it, but it would be hard)".


I do not want to use POV to read my DVD:
If it was possible to write a DVD-reader/player software in pov SDL, it 
would be, IMO, a very bad thing!
I want POV to raytrace images!
Please, know and limit your goal for a language.
Performing account-balance or database access is IMO not the goal for POV.
Neither is performing telecommunication protocols (sending mail, 
browsing websites) or even solving NP-complete problem (even if a 
graphical display of the solution made with POV is usually a nice picture).
And I certainly do not want POV to be part of the realtime system in 
charge of the control of a powerfull facility (nuclear plant, but also 
hydroelectric, or what ever) [excepted if POV get the extra cycle of CPU 
to retrace an image in background, instead of using the classical 
looping idle-task]).

Post a reply to this message

I just had the same discussion about "the world does not need one more
scripting language"
in another newsgroup. It was not about POV but about this:
http://www.it-berater.org/tt-info.shtml
(in german only - sorry). Its a scripting language specialized for doing
desktop-automations.

The two points are the same for POV 3.5's scripting language.
Reading this, please keep in mind that these "special pupose scripting
languages" developed in
an evolutionary process to fit best exactly for their purpose.

1. Those people are familiar with THEIR scripting language which is a
"general purpose language".
    Is like a hammer you can use for many things. They would prefer to use
it then switch to anotehr language and leran new.

2. They say "If you sell your "specialized tool" as a "in a general purpose
tool-box" then you can sell more pieces.

What they can't know is this:

1. If you are a car mechanic you need othr tools then if you are a
door-mechanic. You may use a hammer instead but it will be difficult. To
drive with your "standard car" on a mountain may work with some aditions -
but better learn to drive a car that was specialy constructed for exactly
that purpose. YOU will know later WHY.

- If you take time and LEARN these special-purpose tools first, you may
later think diffrent.

All those people recruit out of newcomers who don't know how it feels to use
the "special purpose tool"
compared to open a door with a "hammer" (general purpose tool).

--Theo

----------------------------------------------------------------------------
---------------------------------
Distributed Network-Rendering or Local SMP-Rendering on all CPU's you have.
With SMPOV und POV-Ray 3.5.Download free at:
http://www.it-berater.org/smpov.htm

Post a reply to this message

IMHO povray is very good at what it does. That is only one thing that annoys
me. It is the fact that you cannot hold variable values from one frame to
another. But, then again, that wouldn't be very easy to implement, I
suppose. Using files to store values is a bit cumbersome.
But anyway, it still rocks just as it is now.

All the best

Fidel.

in article 3D8### [at] freefr, Le Forgeron at jgr### [at] freefr wrote
on 20/9/02 9:29 am:

> David McCabe wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Excuse me. I did not in any way intend to sound rude, arrogent, or whatever.
>> In fact, I think you've misinterpeted me altogether. Notice the last
>> paragraph, in which I say, "maybe it's the stupidest thing ever. Anyhoo, I
>> thought I'd mention it to you who know more than I do.".
>> 
>> By 'real', what I meant was, well, standard, or fully able to do anything,
>> almost general-purpose at least, as in "PostScript is unreal (you could
>> write a program in it, but it would be hard)".
> 
> 
> I do not want to use POV to read my DVD:
> If it was possible to write a DVD-reader/player software in pov SDL, it
> would be, IMO, a very bad thing!
> I want POV to raytrace images!
> Please, know and limit your goal for a language.
> Performing account-balance or database access is IMO not the goal for POV.
> Neither is performing telecommunication protocols (sending mail,
> browsing websites) or even solving NP-complete problem (even if a
> graphical display of the solution made with POV is usually a nice picture).
> And I certainly do not want POV to be part of the realtime system in
> charge of the control of a powerfull facility (nuclear plant, but also
> hydroelectric, or what ever) [excepted if POV get the extra cycle of CPU
> to retrace an image in background, instead of using the classical
> looping idle-task]).
> 
> 
> 
>

Post a reply to this message

On Fri, 20 Sep 2002 11:01:13 +0100, Fidel viegas
<fid### [at] artrecognitioncouk> wrote:

>That is only one thing that annoys
>me. It is the fact that you cannot hold variable values from one frame to
>another. But, then again, that wouldn't be very easy to implement, I
>suppose.

It was implemented in MegaPOV and the Team had their good reasons that
the implementation didn't make it into 3.5.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg: 

>> > I think any new scene description language will have to be something
>> > like POV: partly a simple markup language or human-editable data
>> > format, with a scripting language and built-in support for vectors.
>> > Object oriented as well...POV is almost there, it could become a
>> > prototype-based OOL with just a few modifications.
>> Okay, that's fine. But please make sure we get good OO features.
> 
> Heh, I'm not on the design team...but the POV Team has hinted at a 
> "major reworking" of the language for 4.0.
> 
> Some other languages you might look at:
> Sapphire (on my web page)
> A prototype-based object-oriented language with a fairly Java or C-like 
> syntax. Very dynamic and flexible, built-in support for vectors, made to
> be embedded in other programs or run standalone.
> Wait a while though, I've made some big changes since the last release.
> 
> Io: http://www.dekorte.com/Software/C/Io/
> Very small, embeddable, pure prototype-based OO language.
> 
> Cel: http://freshmeat.net/projects/cel/?topic_id=49
> Another prototype-based language (can you tell I'm interested in 
> Prototype based OO? I think it applies well to this sort of problem.).
> 
> Also Lua, Self, Smalltalk, Objective C, etc...you mentioned Ruby, so 
> chances are you are already familiar with at least a few of these.

I agree with Lua choice :-)
It is small, fast, with a familiar and friendly syntax.
It is aimed as describing data, yet has powerful language features.
The last version allows to load a file with a custom loader: you can use it 
to load a description scene with Lua code embedded in it, a bit like PHP or 
ASP code can be embedded in HTML.
As per security, Lua allows to desactivate at runtime chosen functions from 
the provided library before executing a script. It is suited at user-defined 
level of security.

BTW, my idea of binary POV-Ray file format would allow this: to write a 
scene in one's favorite language, and to generate data directly 
understandable by the renderer, without additional parsing stage.

Biggest drawback: not all POV-Ray users would be able to understand/replay 
the scene. Imagine having Python, Perl, Ruby, Rebol, JavaScript, Lua, 
Scheme, Small, Java, Tcl, SDL, S-Lang, VBScript, etc. interpreters for POV-
Ray, all installed on your system. A nightmare for this newsgroup :-) Not to 
mention maintaining these interpreters for all platforms...

Bah, enough dreaming, neither Lua nor binary files will be used.
And, franckly, I can live without them in POV-Ray :-) But I could accept 
some SDL improvements, like a for loop, better functions, etc.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

On Fri, 20 Sep 2002 10:29:44 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> I do not want to use POV to read my DVD.

Sorry, but I still plan mpeg2 port ;-)

ABX

Post a reply to this message

In article <3d8ae9eb@news.povray.org>,
 "Theo Gottwald *" <The### [at] t-onlinede> wrote:

> I just had the same discussion about "the world does not need one 
> more scripting language" in another newsgroup. It was not about POV 
> but about this:
> http://www.it-berater.org/tt-info.shtml
> (in german only - sorry). Its a scripting language specialized for doing
> desktop-automations.

I would say the answer will always be "yes". First, as you said, 
different languages are better at different problems. But also, a new 
language can try out wild ideas that would never be added to a 
widely-used existing language. A given language may never get more than 
10 users and never be used for any serious purpose, but if it works out 
a concept that turns out to be useful in a more successful language, it 
was a success. What would things be like if people never created a new 
language if there was already one that was "good enough"?

Plus, I believe that the more languages you know, the more ways of 
looking at problems you learn, the better you will be at programming. 
The book "The Pragmatic Programmer" (which I don't own, but plan to get) 
recommended learning at least one new language a year, to avoid getting 
stuck in a single mindset.
http://www.pragmaticprogrammer.com/loty/

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> It was implemented in MegaPOV and the Team had their good reasons that
> the implementation didn't make it into 3.5.
> 
Well, I never played that much with MegaPov. But, now that you have
mentioned it, what were the reasons that led the team to omit it from
version 3.5?

Best Regards

Fidel.

Post a reply to this message

In article <B9B1143E.4D9E%fid### [at] artrecognitioncouk>,
 Fidel viegas <fid### [at] artrecognitioncouk> wrote:

> Well, I never played that much with MegaPov. But, now that you have
> mentioned it, what were the reasons that led the team to omit it from
> version 3.5?

Well, as I recall, it never quite worked right and there wasn't 
agreement on exactly how it should be done. And maybe the POV Team plans 
some better way for 4.0, and didn't want to add an incompatible method 
to 3.5.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

in article chr### [at] netplexaussieorg, Christopher
James Huff at chr### [at] maccom wrote on 20/9/02 6:37 pm:

> In article <B9B1143E.4D9E%fid### [at] artrecognitioncouk>,
> Fidel viegas <fid### [at] artrecognitioncouk> wrote:
> 
>> Well, I never played that much with MegaPov. But, now that you have
>> mentioned it, what were the reasons that led the team to omit it from
>> version 3.5?
> 
> Well, as I recall, it never quite worked right and there wasn't
> agreement on exactly how it should be done. And maybe the POV Team plans
> some better way for 4.0, and didn't want to add an incompatible method
> to 3.5.

Thanks Chris.

All the best

Fidel.

Post a reply to this message

> The book "The Pragmatic Programmer" (which I don't own, but plan to get)
> recommended learning at least one new language a year, to avoid getting
> stuck in a single mindset.

This book could be from me. I am also a fan of "one new each year".
(not gf, but PGML :-).

--Theo

----------------------------------------------------------------------------
---------------------------------
Distributed Network-Rendering or Local SMP-Rendering on all CPU's you have.
With SMPOV und POV-Ray 3.5. Download free at:
http://www.it-berater.org/smpov.htm

Post a reply to this message

David McCabe wrote:
>Hello!
>
>I don't know how far you are in the design process for 4.0, but assuming not
>very far at all, I just had an idea that you might like.
>
>Rather then having some weird, limited, language with a lot of code to
>maintain, why not use some full-blown standard scripting language for scene
>description? We could have some API that the user would talk to in order to
>tell POV-Ray what stuff to put in the scene, just as we have language
>directives now.
>
>This has several advantages:
>1. The user gets a real scripting language that can do any kind of
>        calculations or functions or whatever, and can even integrate
>        rendering with other tasks, automating something or other.
>2. The user doesn't have to learn a new language, just a new API.
>3. You get a high-quality interpeter for free. This would greatly reduce
>        the size of POV-Ray, etc.
>
>By choosing a language that has object-oriented features, you allow users
>to do all kinds of fun stuff. At present, we have '.inc' files with
>macros in them to do things. Put if they had classes in them, that
>knew how to do things, such as animating themselves, or interacting
>with others, the door is opened to many interesting and usefull
>possibilities. Imagine describing large scenes in terms of high-level
>objects that interacted and animated themeselves based on internal
>procedures. The possibilities here are great.
>
>But I digress. Of course, that which I have just briefly described could be
>accomplished using a specialized language. The advantage of a normal
>language is that everyone gets stuff for free.
>
>Anyway, my nominations for the language are (in this order):
>
>1. Ruby
>2. Python
>3. Java
>
>Look at his hypothetical Ruby snippet:
>
>
>add Camera.new Vector.new(3,5,-10), Vector.new(0,0,0)
>add PointLightSource.new Vector.new(30,30,-30), White.vector
>add Plane.new x, -2, Texture.new( CheckerPigment(Black.vector,Red.vector) )
>add Sphere.new Vector.new(0,0,0), 2, Texture.new(Yellow.pigment)
>add SkySphere.new( GradientPigment( y, Colormap.new([0,SkyBlue.vector], \
>        [1,Blue.vector])))
>render
>
>
>....Hmm, that looks a bit clunky; we'll try getting rid of the Vectors...
>
>
>add Camera.new 3,5,-10, 0,0,0
>add PointLightSource.new 30,30,-30, White
>add Plane.new x, -2, Texture.new( CheckerPigment(Black,Red) )
>add Sphere.new 0,0,0, 2, Texture.new( ColorPigment(Yellow) )
>add SkySphere.new( GradientPigment( y, [0=>SkyBlue,1=>Blue] ) )
>render
>
>....rather than:
>
>
>camera
>{
>        location <3,5,-10>
>        look_at <0,0,0>
>}
>
>light_source
>{
>        <30,30,-30>,
>        color White
>}
>
>plane
>{
>        x,-2
>        texture
>        {
>                pigment{ checker Black Red }
>        }
>}
>
>sphere
>{
>        <0,0,0>,2
>        texture
>        {
>                pigment{ color Yellow }
>        }
>}
>
>skysphere
>{
>        pigment
>        {
>                gradient y
>                color_map
>                {
>                        [0 color SkyBlue]
>                        [1 color Blue]
>                }
>        }
>}
>
>....Anyway, you get the idea of what it would look like. But it's really
>about being able to do any sort of task or calculation when making the
>scene.
>
>
>Well, maybe you've all just been enlightened with a blinding stroke of
>genius, or maybe someone else has already suggested this, or maybe it's the
>stupidest thing ever. Anyhoo, I thought I'd mention it to you who know more
>than I do. Thanks for listening.
>
>- --
>David McCabe
>http://12.225.144.95/pgpkey
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQE9iV801bgGCL1rO04RAtLIAKDJqYTkESKHd36pK3xmkHDvsZy5gwCfc4XC
>jSWQUlpGu/fRVqHJkFZJpKA=
>=ZZQk
>-----END PGP SIGNATURE-----
>

If one wishes to code in any other language all one needs to do is write the
libraires that out put the code in POVSDL. Then you can write your scene
and control pvengine any way you want.

I knwo there are things about POVSDL I would like changed but there is no
other language that truely can replace POVSDL. The idea of useing a
"standard" language would have needed to be made at the start. I already
know POVSDL and whould hate to have to change.

Keep up the very good work on POVRAY. In my opinion it is THE most powerfull
3D system available. In the last few weeks I have had a number of projects
and as I thought about how to do them I could only come to one conclusion.
Povray was the only one that would do it. No other program can handle a 30
meg heightfield ,works well with metaballs or has such a flexable and easy
to learn scripting language.

Post a reply to this message

(By the way, it's a good custom to not to quote the whole article you
are responding to, but only the relevant parts, or nothing at all if the
article is long and you are responding to everything.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

ABX wrote:

> On Fri, 20 Sep 2002 10:29:44 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> 
>>I do not want to use POV to read my DVD.
>>
> 
> Sorry, but I still plan mpeg2 port ;-)



That will be ok (allowing POV to read a mpeg2 file to extract a frame to 
use as image map).
What is not ok is using POV as WinDVD, thanks to a simple scene script 
in pov SDL turning pov-renderer in a menu/mouse-driven DVD player !->
(displaying the actual movie in realtime, with sound-decoding and all 
features...)

Post a reply to this message

I think you're in the minority here.  Povray's SDL is quite simply the 
best DSL for scene creation out of any options out there -- check out 
Renderman's ribs out there or some of the stupid XML sh!t many modern 
renderers go for these days.

I like ruby, but you're ruby code is ruby code, not a sweet and simple 
DSL for scene creation.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> I think you're in the minority here.  Povray's SDL is quite simply the 
> best DSL for scene creation out of any options out there -- check out 
> Renderman's ribs out there or some of the stupid XML sh!t many modern 
> renderers go for these days.

  Just because it's the best *existing* language doesn't mean that it
couldn't be even better...

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> I think you're in the minority here.  Povray's SDL is quite simply the 
>> best DSL for scene creation out of any options out there -- check out 
>> Renderman's ribs out there or some of the stupid XML sh!t many modern 
>> renderers go for these days.
> 
>   Just because it's the best *existing* language doesn't mean that it
> couldn't be even better...

Oh, yes!  BTW, I just installed a news cliente here and it downloaded 
all the headers.  I didn't see the date on this one!! 2002! :P

Post a reply to this message