|
 |
In article <41dd6fb2$1@news.povray.org>, Darren New <dne### [at] san rrcom>
wrote:
> Let's reset a little bit. I'm talking about whether it would be better
> to base SDL 4.0 on an existing extensible scripting language with
> ray-tracing primitves added, rather than basing it on a whole new
> parser/runtime. (Note: I am not suggesting anything about POV4. Just
> talking. :-)
>
> In either case, if the primitves are inadequate and you don't have a
> precompiled version of the shader, then you're SOL. So maybe I'm missing
> why shaders even came up in the discussion.
It's a reason why a new parser/runtime could be better than an existing
one, like your suggestion of Tcl.
> > "It" is POV-Ray. It supports user-defined functions which are compiled
> > into opcodes for a virtual machine, and optional further compilation
> > into native machine code. These functions can be used to define
> > isosurfaces, patterns, and with a little extra work, pigments. Not quite
> > a full-blown shader language, but the closest thing POV-Ray currently
> > has.
>
> OK. And surprisingly enough, this implementation doesn't require a C
> development environment. So....
POV doesn't currently use a "standard" programming/scripting language
like Tcl. It uses its own language, and its own VM, designed
specifically for floating point functions. Isosurfaces would render a
lot slower if their functions were written in Tcl. They'd be faster if
they were written in C, but that isn't very practical.
> Actually, I'd expect it to be quite suitable, but relatively slow since
> it is after all byte-compiled. If you wanted it to be fast, you'd either
> do something like POV-Ray does now, or you'd write the shader primitve
> you're interested in in a faster compiled language like C and
> dynamically load it as needed, or you'd write it in Tcl with possibly an
> option to look for the already-compiled code and load that if it's
> available.
We're talking about something that could be a complex function evaluated
for every ray traced, possibly hundreds of times per pixel...thousands
of times with antialiasing. Much more with blurred reflection, media
shaders, and so on, and there's no reason the intersection calculations
themselves couldn't be done in it for custom shapes. "Relatively slow"
is too slow. Interpreted languages are barely suitable but practically
necessary, which is why the POV-Ray function VM has hooks for JIT
compilation. You really need a language optimized for floating point
calculations, preferably with optimizations for colors, points, and
normals.
> The benefit having to do with compiled shaders is the same, regardless
> of what syntax you use for the SDL. Either you support user-defined
> shaders in some custom language, or you support them as C libraries, or
> you don't support them at all, and all three of those are available
> regardless of the syntax of the language.
But once you have a custom language for shaders, why do you need another
language like Tcl for the SDL? You could use one language, one VM for
both purposes. The result is less internal code, and less stuff for
people to learn.
> > Superficially. What I was trying to point out was the difference from C,
> > in that machine-specific forms are rarely distributed widely.
>
> Well, ask yourself why. It's not like *no* software is widely
> distributed precompiled. If it's easy to dynamically load shaders on
> demand, there's no reason they couldn't be precompiled. Imagine an SDL
> that would do a google search for a precompiled shader for your platform
> if it ran into a Tcl implementation of that shader....
They can't be precompiled because they are written and distributed by
users! You can't expect every user that wants to write shaders for
others to use to have a C development environment with cross-compilers
for every platform someone might want to use it on.
--
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
|
|
