"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 04.08.2015 um 16:10 schrieb Warp:
> > > clipka <ano### [at] anonymousorg> wrote:
> > >> Note that my goal is for the language /per se/ to have a very simple
> > >> syntax, and make it pretty much oblivious to rendering, except for
> > >> providing a few special native data types like 3D vectors and colours.
> > >> It'll be up to a bunch of predefined classes to fill it with raytracing
> > >> life in its scene description role. Such a language should be generic
> > >> enough to also be suited for the shader description role, so it would be
> > >> rather pointless and user-unfriendly to devise yet another language for
> > >> that purpose.
> > >
> > > OTOH the "shader" part has to, by necessity, be more limited than the
> > > generic part of the language. It wouldn't make sense, for example, to
> > > be able to create new objects into the scene while evaluating, for
> > > example, the color of a reflected ray. That would mess up things quite
> > > badly, I think.
> >
> > That's part of the "fill it with raytracing life" thing: To add geometry
> > to the scene, you'd invoke particular classes (such as a "sphere" class,
> > a "box" class, and so on), which just won't be available in shaders.
>
> why not simply add a shader option to the texture block, and use something like
> OSL for the shader language?
>
> http://code.google.com/p/openshadinglanguage/
>
> Regards,
> A.D.B.

Of course, using a shader with a patterned texture doesn't make a lot of sense,
so shaders could be used as alternatives to textures.

Then too, if we end up with an OO SDL, would the shader become an object?
Perhaps a subclass of texture... or maybe a superclass... sibling?

At any rate, my point is why make the job more difficult by designing two
complete languages, when we can use one that's already made.

Regards,
A.D.B.

Post a reply to this message