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

> > C is impractical for other reasons...you'd need a C compiler, obviously. 
> 
> Um, well, yes. I was under the impression POV-Ray is written in C 
> already anyway. Indeed, you'd need a C compiler to extend POV-Ray in C. 
> If your implication is that no code written in C can be run on a user's 
> machine that doesn't have a C compiler installed... erm... :-)

No. I'm saying you'll need a compiler to run C source code, such as 
shaders written in C.


> I suspect Tcl already runs on more platforms than POV-Ray, altho I 
> wouldn't guarantee it runs on every platform POV-Ray runs on. I suspect 
> Tcl runs on more platforms than you think it does, tho. ;-)

I'm talking about the C compiler you suggested using for shaders. GCC 
might suffice, if the license allows bundling it like this, but it would 
add several megabytes at minimum to the POV-Ray distribution.


> You'd have to compile it, once per platform. Just like any attribute 
> you'd add to the SDL anyway. You wouldn't need to recompile the base 
> POV-Ray, tho.

But you would still have to compile the shader. It would probably then 
be loaded as a dynamic library by the POV executable, assuming the 
interface for doing so is reasonably easy to port. Tcl might have 
built-in facilities for doing this portably, but it's the first step 
that's hard.


> > 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.
> 
> I don't need a C development environment to run POV-Ray. I don't 
> understand what point you're trying to make.

Because it has its own custom language for functions, the closest thing 
it currently has to shaders. If you used C for a shader language, you 
would need a C development environment.


> Yes. Except that's already built into Tcl. It's called a "safe 
> interpreter". Been around for about 15 years now. I work with the guys 
> who invented it.

I don't see how that helps the security of the code written in C.


> Well, it's possible I just don't understand what you mean by a "shader". 
> However, what I was *trying* to say was, you can extend the SDL with C 
> if the extension is compute-intensive, and it wouldn't need to be part 
> of the official POV-Ray release, but it wouldn't be an entirely new 
> program either - just an extention.

That's essentially what a shader is. A mini-program used to do texturing 
and lighting calculations for the renderer. (Sometimes other stuff like 
geometry as well.)
They're typically compiled to bytecodes and interpreted. I think the big 
packages do let you load C object code or libraries, but you need the 
development tools...


> Or you can extend it directly in SDL, if the performance is good enough. 
> You could, for example, write Tcl code to import Wings3D files directly. 
> If that was too slow, you'd build an ImportWings.DLL (an ImportWings.SO 
> and etc) to run faster, and write Tcl code that if the DLL isn't there, 
> you fall back to the slower method.

But if Tcl doesn't even have built-in numeric calculations, it would 
probably be difficult to add them in a way that gets good enough 
performance for shaders.

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