clipka <ano### [at] anonymousorg> wrote:
> I'm well aware of your wish for this road to be taken, and while it's 
> currently invisible in the SDL, under the hood things are already moving 
> in that direction (your past posts have been quite inspirational in this 
> respect). More and more portions of the code get clearly delineated from 
> each other, modularized, and shoved into well-defined polymorphic 
> classes - which will make it a whole lot easier to plug in user-defined 
> code.

I'm glad to hear that.

> However, the user-supplied code portion of the scheme - and actually any 
> user-supplied code - /will/ have to wait for the parser rewrite: 
> User-supplied code needs /some/ sufficiently expressive syntax, a parser 
> for that, and a sufficiently powerful VM to run on - and I guess we 
> agree that it makes perfect sense to make that identical to the new 
> syntax, parser and VM for the general scene description.

Do you mean that the "shader" code ought to have identical syntax to
everything else in the input language (rather than them being essentially
two separate and independent languages, one inside the other, like the
current SDL and the user-defined functions are now)?

-- 
                                                          - Warp

Post a reply to this message

Am 02.08.2015 um 00:43 schrieb Warp:

> I'm glad to hear that.
>
>> However, the user-supplied code portion of the scheme - and actually any
>> user-supplied code - /will/ have to wait for the parser rewrite:
>> User-supplied code needs /some/ sufficiently expressive syntax, a parser
>> for that, and a sufficiently powerful VM to run on - and I guess we
>> agree that it makes perfect sense to make that identical to the new
>> syntax, parser and VM for the general scene description.
>
> Do you mean that the "shader" code ought to have identical syntax to
> everything else in the input language (rather than them being essentially
> two separate and independent languages, one inside the other, like the
> current SDL and the user-defined functions are now)?

Yup.

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.

Post a reply to this message

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.

(Also, the reason why shaders in graphics hardware can be so fast is
that they are highly parallelizable. Modern cards run thousands of
instances of shaders in parallel. Obviously there need to be some
limitations in the shader language for this to be possible. There
can't be inter-dependencies between shader instances being evaluated.)

-- 
                                                          - Warp

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message

"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

Am 05.08.2015 um 03:04 schrieb Anthony D. Baye:

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

Uh... "simply"?

Maybe because we'd need to...

- design the new SDL in such a way that the OSL can be embedded therein 
without conflict;

- design the new SDL parser in such a way that the OSL can be plugged 
into it;

- design a layer that provides the exact features exposed to the user by 
the OSL;

- prepare for a never-ending struggle to explain to users why feature X 
is part of OSL but not supported by POV-Ray; and

- prepare for a never-ending struggle to explain to users why syntax Y 
in the SDL doesn't do the same as in the OSL.


Thanks, but no thanks.

/Maybe/ OSL will be supported by some POV-Ray 4.5, as an /alternative/ 
to the native shader definition syntax. But not in POV-Ray 4.0, and 
certainly not as the primary language for user-defined extensions.


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

Exactly that.


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

Because (A) one of those two languages needs to be designed from scratch 
anyway, in order to be suitable as a Scene Description Language for 
users who don't want to be programmers.

I don't want users to have to write

      MySphere = new sphere;
      MySphere.center.x = 2.0;
      MySphere.center.y = 1.0;
      MySphere.center.z = 5.0;
      MySphere.radius = 0.5;
      MyScene.add(MySphere);

when a specially-designed language could make it a one-liner, like it is 
in the current SDL. I've yet to see a language other than SDL 3.x that 
fits the bill; but I know that a language can be designed to achieve 
that goal.

And (B) because the two complete languages will be just one. With a 
different set of objects to manipulate, but the same underlying language 
nonetheless.

Post a reply to this message

Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> 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/

The "shader" language would need to be able to do a lot more than just
get some values and input and return a color.

For example, it ought to be possible for it to say "shoot a ray starting
from this point towards this direction, and gimme all the info about
the object that the ray hits". (This kind of functionality could be
used, for instance, to create a "portal" shader. In other words, a
surface that shows a completely different part of the scene, as if
the suface were a "portal". Rather than this being a hardcoded feature,
the user ought to easily write such functionality as a "shader". As
such, it's then easy to create a myriad of variants with little effort.)

-- 
                                                          - Warp

Post a reply to this message

On Wed, 05 Aug 2015 19:29:42 +0200, Warp <war### [at] tagpovrayorg> wrote:

> Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
>> 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/
>
> The "shader" language would need to be able to do a lot more than just
> get some values and input and return a color.
>
> For example, it ought to be possible for it to say "shoot a ray starting
> from this point towards this direction, and gimme all the info about
> the object that the ray hits". (This kind of functionality could be
> used, for instance, to create a "portal" shader. In other words, a
> surface that shows a completely different part of the scene, as if
> the suface were a "portal". Rather than this being a hardcoded feature,
> the user ought to easily write such functionality as a "shader". As
> such, it's then easy to create a myriad of variants with little effort.)
>

Ooo portals! I like portals =D

-- 
-Nekar Xenos-

Post a reply to this message

On 8/5/2015 11:29 AM, Warp wrote:
> For example, it ought to be possible for it to say "shoot a ray starting
> from this point towards this direction, and gimme all the info about
> the object that the ray hits". (This kind of functionality could be
> used, for instance, to create a "portal" shader. In other words, a
> surface that shows a completely different part of the scene, as if
> the suface were a "portal". Rather than this being a hardcoded feature,
> the user ought to easily write such functionality as a "shader". As
> such, it's then easy to create a myriad of variants with little effort.)
>

It would also allow all kinds of tricks involving translucency, 
reflections, etc. For instance, the example of blurred reflection you 
gave in the first post.

Post a reply to this message