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