In article <405cbe16@news.povray.org>,
 David Burnett <var### [at] ntlworldcom> wrote:

> I remember that patch, it looked very good, I'd like to see Ember if its
> publicly available.

Not yet. I'm thinking of just shoving what I have out the door...got too 
many projects just sitting on my hard drive.


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

I don't think you quite understood how slow I meant. Someone (Slime?) 
built a JavaScript raytracer that might make it clearer...I mean too 
slow to be practical. These languages just aren't designed for any kind 
of speed, particularly not at floating-point heavy calculations.


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

Well, that will almost certainly never happen. You should take care to 
design a good syntax, I see no reason to make it easier to get away 
without doing so.


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

All of that should eventually be possible with the SDL.


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

Same goes for any other language. So what?


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

That doesn't matter. Even common libraries like libjpeg cause some 
trouble. Adding this would complicate the matter of building POV on a 
new platform or in a new development environment.


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

Except that those language extensions would be under the control of the 
POV developers. If there's a bug, it can be fixed.


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

I'm not sure what you're saying. Compiled plugins *would* need a 
development environment.


> Not all the scripting languages are interpreted,parrot for example is 
> JIT'ed so any language used with parrot is JIT'ed.

You are making the assumption that the JIT compiler is anywhere near as 
good as whatever C++ compiler POV is built with, and that the results 
will be at all efficient. And that the JIT is supported on all platforms.


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

It's not. Just look at what other code does to see how it works. It can 
be problematic if you're doing something unusual, but the parsing code 
for typical objects, patterns, or textures is extremely simple.

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