Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> >   Then in your opinion for example Lisp and Prolog are not true
> > programming languages?
> > 
> I hate them, yes.

  How does you hating them affect in any way the fact whether they are
true programming languages or not?

  That's like saying that you hate toyotas and thus toyotas are not cars.

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

Darren New <dne### [at] sanrrcom> wrote:
> It might be worthwhile to consider the use of an existing scripting 
> language that's designed to be embedded in other programs, and use that 
> for the scripting language.

  That has been considered many times, but doesn't seem to be a good
solution.
  POV-Ray needs a language specific for POV-Ray. Using a generic
programming language will make many things too awkward and hard to
use (too many things will have to be kludged).
  Besides, optimally the new language will somewhat resemble the
current one so that the learning curve will not be as steep. Most
POV-Ray users have never used any other language and learning a
new language which is similar to the current SDL will be easier
than learning a completely different language.

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

in news:41d9bf11@news.povray.org Bernd Fuhrmann wrote:

> It would be better to 
> develop some kind of library for that programming language that would
> be used by most people who want to develop extensions that cannot be
> done properly with POVRay SDL.

Something like:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205451

Ingo

Post a reply to this message

In article <41d86f9a$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Once you get to the point of *interpreting* what "#while" means, you're 
> past the parsing stage. POV-Ray may call that "parsing", but it isn't. 
> It's executing the specification. In other words, if the OP wants to do 
> something like add a namespace to some selected number of variables, you 
> don't have to understand a "while" loop to find all the variables you're 
> going to change, any more than emacs needs to understand SDL to 
> search-and-replace spheres with something else.

When POV says it's parsing, it's really parsing. POV executes the scene 
file as it parses it, rather than parsing into an intermediate form to 
be executed later. This is one of the reasons it is so slow, and one 
thing which badly needs improvement in POV4...it crawls around the input 
source files while generating the scene. The body of a loop is actually 
parsed once per iteration. Then there's a postprocessing stage where 
stuff like photons and radiosity are precalculated, basically "filling 
in the blanks" of the generated scene, and then you get to the rendering 
stage.

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

ingo wrote:
> in news:41d9bf11@news.povray.org Bernd Fuhrmann wrote:
> 
> 
>>It would be better to 
>>develop some kind of library for that programming language that would
>>be used by most people who want to develop extensions that cannot be
>>done properly with POVRay SDL.
> 
> 
> Something like:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205451
> 
> Ingo

Yes. I don't know Python good enough, but I think something like that. 
Perhaps with slightly more features or better internal structure, but I 
really don't know Python good enough to decide that. Just a feeling in 
my stomach that this can be done better.

Thanks for the hint. Btw: What is you opinion of a facility like it is 
shown in that Python code piece?

Regards,
Bernd Fuhrmann

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> 
>>It might be worthwhile to consider the use of an existing scripting 
>>language that's designed to be embedded in other programs, and use that 
>>for the scripting language.
> 
> 
>   That has been considered many times, but doesn't seem to be a good
> solution.
>   POV-Ray needs a language specific for POV-Ray. Using a generic
> programming language will make many things too awkward and hard to
> use (too many things will have to be kludged).
>   Besides, optimally the new language will somewhat resemble the
> current one so that the learning curve will not be as steep. Most
> POV-Ray users have never used any other language and learning a
> new language which is similar to the current SDL will be easier
> than learning a completely different language.
> 
I don't understand that one. Why should people _need_ to learn new 
languages. If there is just a frontend that is able to create SDL code 
they'd still have SDL code to work with. They won't be able to 
effectively modify it but they aren't now either in many cases (those 
that are just to hard to be treated with common SDL).

Regards,
Bernd Fuhrmann

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>>  Then in your opinion for example Lisp and Prolog are not true
>>>programming languages?
>>>
>>
>>I hate them, yes.
> 
> 
>   How does you hating them affect in any way the fact whether they are
> true programming languages or not?

It doesn't. "Being a true programming language" is not defined. If you 
mean Turing-complete was a good sign of true programming languages just 
have a look at brainfuck (http://www.muppetlabs.com/~breadbox/bf/). No 
sane person will use that language to code any serious software. So you 
wouldn't consider that a real programming language. On the other hand: 
What if you used such a programming language for 40 years and you could 
do things faster with that awkward programming language then with any 
other? You'd certainly consider it a real programming language. So what? 
It's a matter of opinion. So why should we argue about it?

But there are still facts: Some things just save you a lot of time, like 
OOP. Modularization is important. So we should have a good look at all 
those little nice features of all kinds of programming languages that 
allow a better form of modularization. These things should go into 
POVRay SDL or any officially recommended frontend for it.

>   That's like saying that you hate toyotas and thus toyotas are not cars.

Come on. I did'nt say that. They are considered real programming 
languages by many people. I know that. But I still don't like them. It's 
just my opinion. Call it a feeling. I once had to do a couple of things 
with Scheme and I was really pretty upset because of certain things. So 
I will not consider them as a true alternative for C(++) for my 
programming work. Other people will think different. I can live with 
that (as long as I don't have to mess up with their code).

Regards,
Bernd Fuhrmann

Post a reply to this message

in news:41daff5b$1@news.povray.org Bernd Fuhrmann wrote:

> Thanks for the hint. Btw: What is you opinion of a facility like it is 
> shown in that Python code piece?
> 

In general it works fine. In this specific case there's a few things I'd 
have done differently, the syntax is 'relative' close to POV-SDL. I'd 
probably prefer something like VPython http://vpython.org/ with an 
export to POV-Ray, becaus when working in one language I probably don't 
want to bothered by another. For generating POV-Ray SDL from another 
language I've been looking at templating systems and I think most what 
one needs can be done with them, as after all, it's only text.

Here's yet another one:
http://www.4dsolutions.net/ocn/numeracy0.html
and other pages on the site.

Personaly, I think there are three interesting options:
One is a standalone parser that interfaces with, in my case, Python. It 
would suit my current needs, but it lacks interaction, so no "trace" 
ability.

Two, the possibility to call, in my case python, scripts from POV-Ray as 
a kind of include files. I guess the chanches for the latter to happen 
are rather small.

A third and maybe most interesting option, is something like Jython 
http://www.jython.org/ . POV-Ray SDL implemented in another programming 
language in such a way that it completely interacts with that language 
and you can use any library available in the two languages. And 
regardless what you use, everything looks like POV-Ray-SDL syntax.

All that, from a non-programmers view,

Ingo

Post a reply to this message

In article <41dade0b$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Warp wrote:
> >   POV-Ray needs a language specific for POV-Ray. Using a generic
> > programming language will make many things too awkward and hard to
> > use (too many things will have to be kludged).
> 
> I disagree that this would be the case for several languages designed 
> specifically for this purpose, such as FORTH and Tcl. I'd be interested 
> in an example of something that current SDL does that would be severely 
> awkward in (say) Tcl.

Uh...what? You disagree that Forth would be more awkward? Your brain 
must be inside out. ;-)
I actually considered a similar language (more similar to PostScript, 
actually) for driving my own raytracer, but I'd never construct a 
complex scene in it directly. I've had enough of that stuff with some 
hand coded PostScript logos I did. (I finally decided that C++ was good 
enough, considering that it was primarily a testbed for raytracing 
algorithms.)

I don't know much about Tcl, but I doubt it would be as convenient as a 
special purpose language. Simply having a built-in syntax for specifying 
vectors is a huge advantage. A quick web search tells me it's designed 
to be easily extended though, so maybe you could modify it to support a 
fairly POV-like syntax...

In a general purpose language, you're pretty much restricted to 
manipulating the raytracing engine through an API, rather than writing a 
scene in a scene description language. For just general scene coding, 
this is usually more work. For example, something like:

sphere {< 0, 1, 0>, 1
    scale < 1, 0.2, 1>
    rotate < 45, 0, 0>
}

typically turns into something like:

Sphere mySphere(Vect3(0, 1, 0), 1);
mySphere.Scale(Vect3(1, 0.2, 1));
mySphere.Rotate(Vect3(45, 0, 0));

scene.AddShape(mySphere);

It gets worse when you throw things like transformations into the mix. 
You end up with either a complex, hard to maintain API, or complex, hard 
to write and maintain scene code. An "elegant" way to handle 
transformations would be to give objects a single method for applying a 
transformation:

mySphere.Transform(Transforms::Rotation(Vect3(45, 0, 0)));

The "convenient" way would be to provide a method for each type of 
transformation, with different versions for vectors, scalars, and 
triples of vectors:

mySphere.Rotate(45, 0, 0);

Much easier to write and read. But the API now has at least 3 rotation 
methods in addition to the general Transform() method. If you add an 
axial rotation transform, you need to add at least another method to the 
shape classes.

Some languages (including Lisp, I think) allow parts of the language 
itself to be modified by programs written in the language...this could 
be a very useful feature, since you could build the scene description 
language with the base programming language. However, I don't know of 
any which would be good candidates for a POV-Ray input language.

Another thing to consider is that most scripting languages aren't 
designed for efficiently processing floating point math. The current 
POV-Ray SDL is one of the worst at this, but the new one should be good 
enough to use as a shader language and to specify functions for 
isosurfaces without needing an entirely separate VM.

-- 
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 <41d98ce0$1@news.povray.org>,
 Bernd Fuhrmann <Sil### [at] gmxde> wrote:

> What should be thought of is this: There are a lot of good programming 
> languages out there: C/C++, Java, Pascal/Delphi, JavaScript, XML, 
> Scheme, Prolog, PHP, and so on. Why does POVRay need to have it's very 
> own programming language that is compatible to none of the existing 
> ones? The only thing that POVRay needs to do is this (simplified):

Simplicity. None of those really cut it.


> So one has to ask: How can I get all that date in a clean and easy way 
> from all kinds of different sources to the renderer? What sources might 
> that be?

Primarily hand-written scene files. XML is basically useless for that, 
those other languages are usually just very awkward, and require 
knowledge of a complex programming language. The existing SDL is 
limited, but it's also simple. People can do substantial things while 
knowing very little about programming.
Then there's maintenance issues...keeping up with updates to the 
language, changing the language if the developers take it in a direction 
that makes it less useful to POV-Ray, etc. Plus debugging someone else's 
code base.

For someone with experience in those languages, learning the POV-Ray SDL 
shouldn't be a challenge, but the POV language will be better at what it 
needs to do.


> Cool. Where do I have to go to join development team? #4 doesn't seem to 
> be under development. Or is it? Couldn't find any info, any invitation, 
> anything.

That was probably because you weren't invited. POV 4 isn't even 
partially released yet, but that you can't see it doesn't mean there 
hasn't been any design or code written. You can write and distribute 
modifications as allowed by the license, but you'll have to work with 
3.6 for now.

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