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

Christopher James Huff wrote:
> 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.

If you say so. Are you quite sure of what you're talking? Some of those 
languages are very powerful, especially for large projects.

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

But they can't do advanced things as easy as they could if there existed 
some default front-end for one of those programming lanugages mentioned 
above. So there should be an alternative for those who want to do the 
more advanced stuff.

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

Programming languages don't change that much. Last change of C++ was in 
2001, I guess, and that was just a minor issue. Ok, C++ is complex. You 
might consider the use of any other programming language. They are well 
defined and if there are substantial changes you might stick to the old 
version for a while. You might even use external compilers so the POVRay 
team can concentrate on the raytracer.

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

It's not learning POVRay SDL but getting complex work done with it. I 
can tell you that it is not motivating if you are just experienced 
enough to know that the code you are writing will not be maintainable.

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

So there would be another POVRay modification. I don't have the time for 
this. I would have to redesign half of the program. This is useless 
since I would have to spend so much time and in the end noone would use 
my version (except me). All the advanced features of the next version 
and it's bugfixes would not be in my version. Therefore this is pointless.

Regards,
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> I once had to do a couple of things 
> with Scheme and I was really pretty upset because of certain things.

  Typical example of "extrapolation from one or less examples".

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

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 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).

  I don't understand what you are talking about.

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

Look at this stuff
http://www.photon.at/~werner/light/
http://www.photon.at/~werner/light/doc/a00451.html

And also you can try to search the web for other projects I didn't do it 
thorougly.
What do you think?

Andrey.

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>   Typical example of "extrapolation from one or less examples".

If you say so. No, really. I developed (with my partner) about 10 
programs that were more or less complex. So I don't think what and how 
you say about my Scheme experience is not really fair. I won't answer 
that anymore since it's really pointless.

Bernd Fuhrmann

Post a reply to this message

In article <41dbac8c@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.
> 
> If you say so. Are you quite sure of what you're talking?

Yes, I am quite sure. I have done complex simulations in POV-Ray, it's a 
pain in the ass. I have also done scenes coded directly in Java and C++, 
that's a bigger pain in the ass than writing the raytracers. As I 
mentioned before, simply the lack of a built-in vector syntax makes 
things much harder to write and read. My C++ tracer can be made to do 
Monte-carlo path tracing by simply coding the materials in a certain 
way, but building a scene of any complexity is maddening due to all the 
C++ syntax I have to work through.

Pascal, Delphi, JavaScript, and PHP would all have similar problems to 
C++ and Java related to the requirement of using an API. A Prolog SDL 
would be...very interesting, but probably not very good for general use. 
Scheme might make a useful, but idiosyncratic SDL. XML is useless for 
hand coding, and no easier for automated programs to write than a custom 
SDL would be.


> Some of those languages are very powerful, especially for large projects.

And this shows you completely miss the point. It doesn't matter how 
powerful the language is if you must be a programmer to use it. Most POV 
users aren't programmers, despite hand coding their scenes in a 
Turing-complete programming language.


> But they can't do advanced things as easy as they could if there existed 
> some default front-end for one of those programming lanugages mentioned 
> above. So there should be an alternative for those who want to do the 
> more advanced stuff.

They can't do them *now*. They could with a improved scene description 
language, more easily than they could with a general programming 
language.


> Programming languages don't change that much. Last change of C++ was in 
> 2001, I guess, and that was just a minor issue. Ok, C++ is complex. You 
> might consider the use of any other programming language. They are well 
> defined and if there are substantial changes you might stick to the old 
> version for a while. You might even use external compilers so the POVRay 
> team can concentrate on the raytracer.

...

The POV-Team, and all the people developing patches, will concentrate on 
what they want. Much of the time, that is extending the language to be 
more powerful for describing scenes. It is not just a minor subsystem 
for loading scene data.

In addition, an external language will either lose a great deal of 
versatility because it can't tie directly into the tracer, or lose 
portability due to having to dynamically load the POV-Ray renderer as a 
library. Evaluation of pigments, transformations, and ray intersections 
during scene construction are extremely important features. You just 
can't do this without adding problems with portability, dependency on 
other libraries or utilities, etc. And then you have the issues with 
ensuring security from malicious scripts, convincing users that they 
have to learn a complex programming language and scene API, etc...


> It's not learning POVRay SDL but getting complex work done with it. I 
> can tell you that it is not motivating if you are just experienced 
> enough to know that the code you are writing will not be maintainable.

You miss the point again...that can be fixed by improving the SDL, 
without losing its advantages...which would be lost by moving to a 
general programming language. Ease of learning the language and using it 
for things which are simple in terms of programming are far more 
important than you seem to realize.


> So there would be another POVRay modification. I don't have the time for 
> this. I would have to redesign half of the program. This is useless 
> since I would have to spend so much time and in the end noone would use 
> my version (except me). All the advanced features of the next version 
> and it's bugfixes would not be in my version. Therefore this is pointless.

I think this should be obvious, but if nobody finds it useful, it 
shouldn't be in the official version.

-- 
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 <41db3709$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> > 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.
> 
> You can write OO-ness in Tcl, entirely in Tcl. Many of Tcl's control 
> structures are written in Tcl.  Adding a vector type to Tcl is *trivial*.

After looking at some examples online, I begin to see...it's one of 
those "mutable" languages I was talking about.


> Yes. That's called an "extensible" language, and includes Tcl, FORTH, 
> and Lisp. Lisp still has the ((())) syntax to deal with, FORTH has the 
> postscript, and Tcl has very few drawbacks in this regard. Altho, as you 
> mention, Tcl expression syntax can be a little bit ugly, just a tad.

Sounds like we're talking about the same thing, just that I don't know 
anything about Tcl.


> Tcl, I'd venture. :)
> 
> Mind, Tcl isn't really good at math as such, but on the other hand since 
> math isn't technically built into the language, that would probably be 
> pretty easy to improve.

Well, I'll have to put Tcl near the top of my list of alternative 
existing languages. However, I'd still prefer a custom one, for the 
control over architecture and reduction in dependency, and more clear 
responsibility for bugfixes and such. Based in spirit on languages like 
Tcl, but not in actual code. Writing a language parser isn't all that 
difficult, it's mainly tedious after you get basic expression parsing 
done...and once it's done, adding or minor modification is pretty easy.

And, if it's not designed for it from the start, making the VM 
high-performance for things like shaders would probably be quite 
difficult. Going from dynamic dispatch of an operator method to 
performing a VM operation on a numeric primitive type is quite a change. 
Something like overlapping it with a far more static language...

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