Christopher James Huff wrote:
> In article <405b7e15$1@news.povray.org>,
>  David Burnett <var### [at] ntlworldcom> wrote:
 >
>>the checkerboard distance between points. Perhaps it might be better 
>>just to put a complete parser in.
> 
> 
> A shader language capable of doing this would indeed be very nice. I 
> started such a thing with my G patch, now called Ember. Basically a 
> simplified C, with additional features for vectors and colors, written 
> for fast execution so it would be useful for shaders and other 
> render-time uses.
> 
I remember that patch, it looked very good, I'd like to see Ember if its
publicly available.

> 
> 
>> > Lua and Python
>>
>>>would be too slow for most of the things functions are used for anyway.
>>
>>Its faster for the things that can't be done in functions right now 
>>though. And if you improve functions, well chances are it would be 
  >
> They are too slow for anything that would be done at render time
 >

We use a raytracer we are used to long waits :-)
I just think dog slow is better than not at all.

> 
> That syntactical sugar is the primary advantage, and it's a big one.
> I'm no longer sure what problem you're trying to fix. You seem to want 
> additional languages to avoid the limitations of the scene description 
> language, but that assumes the scene language will always be as limited 
> as it is now.

The problem, when you right right down to the basics is, I would like
it to be easier to add 'features' without the pain of having to break
out the pov source, work out how the parser works and where to plug
in your own code and syntax.

My personal interest is textures, and what I in particular would
want was Turing complete functions, that can return colours or
vectors or floats depending on their use and can be used anywhere
a colour or vector or float is used. By that I mean colour functions
could be used for pigments, vector functions for for warps. Oh
yes and this functions should have access to as much information
about the render as possible, not just x,y,z, the point where
the object was placed. The vector the ray is coming from, the
current colour of the object it the texture is layered. And
those are the one that I can think of of the top of my head.

I'm sure that would be a the less than idea solution for other
peoples wants.

Yes SDL can be extended by someone else, but they might do do the 
feature 'I' need.



> However, it would add another thing to do when porting POV to a new 
> platform

Most of the languages already have a cross-platform embedding API's, 
even parrot.

> another external thing that the developers have no control 
> over, and we would have to support it. 

As you would have to support language extensions, thats a no win situation.

And this is for the interpreted
> languages you mentioned...compiled plugins *would* require a development 
> environment.
>

Well there's no way compiled plugins needing a development environment
The advantage comes form a simplified API.
Not all the scripting languages are interpreted,parrot for example is 
JIT'ed so any language used with parrot is JIT'ed.

> 
>>There would also be no dealing with the pov SDL parsing code to add a 
>>quick new function or object.
> 
> 
> That isn't exactly difficult. The parsing code is usually the easiest 
> part to write.
> 

Difference of opinion there. I think the parser code is quite difficult 
to get into, especially to a new pov developer. There's a sub thread 
about it somewhere in this big thread.

Dave

Post a reply to this message