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

In article <cjameshuff-C93C28.15390704012005@news.povray.org>, 
cja### [at] earthlinknet says...
> 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.
> 
Ah hah... I knew I was right about that. I look forward to a more JIT 
type system in 4.0, if they do so.


-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <41db0035@news.povray.org>, Sil### [at] gmxde says...
> 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).
> 
Except that the frontend is entirely unneeded if you extend the SDL to 
support things properly in the first place. Moray does a decent, but not 
complete job of acting as a front end and even solves some problems, in a 
general way, like animation that are troublesome with pure SDL. But it 
falls short of supporting some basic things, like being able to link a 
light source to an object, so they move together, let alone some more 
complex things. The more abstraction you put between the core functions 
and the user, the more limited you end up making their options and the 
more the perception becomes, "That program can't do X". Of course, some 
times, like with media for subsurface scattering, the 'correct' solution 
can actually have the opposite result, making it so complicated to use 
the feature that the abstracted simulation of it might be preferable, but 
that is generally a far more rare situation. Any abstraction shouldn't be 
in the language someone uses to manually edit things in most cases, but 
more like Moray, when the abstraction is to a simpler representation of 
what it really being done. XML or other structures can't improve the 
ability to see that, it only obfuscates the actual process or nature of 
the objects in it even more.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

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

> > 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.
> 
> Errr, well, I'd expect there's be a call that says "Trace." :-) Tcl's 
> all in C, and it's designed to call C routines pretty seemlessly. I 
> wouldn't think you'd implement the shaders in Tcl, but in C.

C is impractical for other reasons...you'd need a C compiler, obviously. 
This is a bigger problem than you'd think. The compiler must exist for 
all the platforms POV is likely to run on, and is an obstacle to porting 
to new platforms.

Then you need to run this external compiler with the shader code and 
link in the result. A C development environment is a bit heavy to 
include along with the raytracer, and is likely to be a huge source of 
problems on different configurations. Plus there's the security risks of 
using such a low level language...you'd pretty much have to disable 
programmable shaders for a web-driven application, for example.

Also, with no support for vector/color math or operator overloading, C 
shaders would get pretty ugly...though if you can solve the compiler 
problem, I suppose you could translate from a customized language into 
C, as was done for early C++ and Objective C compilers.

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