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

> Translating the description of the shader into specific machine code or 
> specific byte codes would be the same amount of work to implement 
> regardless of whether you used Tcl or not to invoke the scripts.

Writing and maintaining both a shader language + VM and a Tcl SDL would 
be more work than writing and maintaining an SDL that also serves as a 
shader language. If you have a decent custom language already in the 
project, I see no reason to add another one.


> I expect the way you would use Tcl in this project is to implement 
> "sphere" in Tcl to output the appropriate bytecodes for the optimized 
> VM. I don't see writing the ray-tracer itself (i.e., the thing that 
> follows the rays and calculates pixel colors) in Tcl to be feasible any 
> more than doing so in SDL is feasible.

But maybe you don't want a plain sphere. Maybe you want a sphere with 
ripples on it. Thus, you need to execute user-defined code, and the 
faster the better.
With an improved custom-purpose SDL, replacing most of the raytracer 
with user-written code would be slower, but perfectly feasible. You 
could even implement your own raytracer, though there would be no reason 
I can think of to do so.


> Basically, you'd use Tcl to build the scene, and then your specific VM 
> to interpret the stream.  Layering, ya know?

But what purpose is there to another layer?


> The language that builds the VM byte stream doesn't have to be 
> especially fast. I mean, heck, POV-Ray 3.x (as far as I understand) 
> actually reparses the source text to do so. Tcl would be faster because 
> after the first time thru the loop, the parsing is byte-compiled.

But not fast enough. Not all VMs are equal. It's byte compiled, so are 
POV functions. However, the POV function VM is built for crunching 
numbers, and is almost certainly much faster at it than Tcl.


> > But once you have a custom language for shaders, why do you need another 
> > language like Tcl for the SDL?
> 
> The "custom language" would be Tcl.

No, the custom language I'm speaking of here is the shader language. 
Tcl's too slow for that.


> > You could use one language, one VM for both purposes.
> 
> Well, are you assuming that a VM needs a custom language to write a 
> compiler for? That may be the miscommunication.

No, of course not. The "custom language" could be essentially a clone of 
Tcl, with floating point and vector optimizations. Then there'd be even 
less reason to use standard Tcl.


> You can expect, however, that there is at least one person who has a 
> compiler for your platform, or POV-Ray wouldn't be running there. The 
> stumbling block isn't that compiled versions don't work for some reason. 

Yes, it is! I can't run x86 machine code on my iBook. Without a 
compiler, I can't run stuff I just wrote in C. Having someone else 
compile stuff for me every time I tweak the code just isn't an option.


> The stumbling block is a lack of distribution facilities where you can 
> find it precompiled. If there's a central place holding shaders, there's 
> a central place where people could contribute executable versions.

No, it isn't. I can't go download a compiled version of a shader I just 
wrote. Again, shaders are written by *users*. They need to be able to 
write the code, then run it. It needs to run as fast as feasible.


> Plus, if the shaders are written to compile down to some VM, the VM 
> code could be either built into POV or could be distributed along 
> with or instead of the source.

That is exactly what is done with many shaders, though it is a bit more 
flexible and useful to distribute the source.


> I mean, Tcl has a whole bunch of executable extensions that are written 
> and distributed by users. It's really not that hard. :-)  And I suspect 
> that POV-Ray doesn't run on *so* many platforms that, say, 6 different 
> executables wouldn't satisfy >95% of the users using it, and the other 
> 5% probably have the development environment anyway.

Requiring people to have a 6-way cross-compiling development environment 
in order to write and distribute a reasonably advanced scene is 
ridiculous. Alternatively, requiring them to have a development 
environment for their own system or know someone who does in order to 
render the scene is equally ridiculous. Interpreted languages are 
practically necessary for useable shader languages. However, even the 
fastest ones are also nearly too slow to be of practical use for that.

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