Warp  wrote in message <47076431@news.povray.org>:
>   Btw, how do you envision the basic user being able to write shaders in
> this system?

Actually, I do not know exactly what a shader is. Would a basic user be able
to write one, in any system?

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> Warp  wrote in message <47076431@news.povray.org>:
> >   Btw, how do you envision the basic user being able to write shaders in
> > this system?
>
> Actually, I do not know exactly what a shader is.

A user-definable function that accepts some information about a scene,
object, surface or ray and returns information that the renderer then uses
to modify the shading, illumination, any other aspect of the rendered
image.

I suspect though  that the shading language under consideration is solely to
replace only what other packages would call surface shaders: these shaders
accept information about a ray and the object it intersects, and return a
final surface colour using some internal process. POV's support for this is
quite focussed on colour, rather than surface properties; almost that you
can have any BDRF so long as it's Lambert.

> Would a basic user be able to write one, in any system?

Yes. Although the actual shader language is usually quite low-level (often
C-like), and therefore not particularly artist-friendly, most applications
provide a specialised visual editor. These days they are usually based on
nodes (plug a texture node into a diffuse shading node to get a texture
mapped diffuse surface, for example). Some systems opt to use layers, but
it ends up being the same. The systems are very powerful indeed, much more
powerful than my textured diffuse example.

I guess the plan in POV is not to ship any such visual support by default,
and make the underlying shader language artist-friendly enough to use. As
far as I know this will be a unique achievement, both in terms of
originality and, as always, difficulty.

Some further reading:

http://www.janwalter.com/
(the shader writing bits show how a few other packages handle this in their
C-like shading language)

http://www.xsi-blog.com/archives/118
(clever use of the visual shading language to speed up ambient occlusion in
XSI/mental ray)


Tom

Post a reply to this message

"Tom York"  wrote in message
<web.47079017bcc3cc027d55e4a40@news.povray.org>:
> A user-definable function that accepts some information about a scene,
> object, surface or ray and returns information that the renderer then uses
> to modify the shading, illumination, any other aspect of the rendered
> image.
<snip>

Ok, thanks.

> Yes. Although the actual shader language is usually quite low-level (often
> C-like), and therefore not particularly artist-friendly, most applications
> provide a specialised visual editor. These days they are usually based on
> nodes (plug a texture node into a diffuse shading node to get a texture
> mapped diffuse surface, for example). Some systems opt to use layers, but
> it ends up being the same. The systems are very powerful indeed, much more
> powerful than my textured diffuse example.

I do not think that can be called "writing" a shader. And what you describe
seems to me quite similar to what is possible already with the numerous
pigments of POV-Ray. Isn't it?

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> I do not think that can be called "writing" a shader. And what you describe
> seems to me quite similar to what is possible already with the numerous
> pigments of POV-Ray. Isn't it?

  A shader should be able to, for example, launch additional rays if
necessary.

-- 
                                                          - Warp

Post a reply to this message

Warp  wrote in message <47079ed1@news.povray.org>:
>   A shader should be able to, for example, launch additional rays if
> necessary.

Yes, I understood that. And I ask again the question, this time more
precisely:

Is, with any system, a basic non-programmer user, capable of writing a
shader that does more that what is possible with textures and pigments?

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> "Tom York"  wrote in message
> > Yes. Although the actual shader language is usually quite low-level (often
> > C-like), and therefore not particularly artist-friendly, most applications
> > provide a specialised visual editor. These days they are usually based on
> > nodes (plug a texture node into a diffuse shading node to get a texture
> > mapped diffuse surface, for example). Some systems opt to use layers, but
> > it ends up being the same. The systems are very powerful indeed, much more
> > powerful than my textured diffuse example.
>
> I do not think that can be called "writing" a shader.

Does it matter? As I said, I really doubt POV 4 will include such a visual
editor.

> And what you describe seems to me quite similar to what is possible already
> with the numerous pigments of POV-Ray. Isn't it?

You can look though the archives of this NG to find out. Some of it is not
exactly straightforward. A lot of it is impossible. For an example of the
first, consider a surface whose specularity varies independently of its
roughness. To vary one or the other property requires only a texture_map.
To vary both independently requires two nested levels of texture maps.
That's very clumsy, and hopefully you do not want to vary the diffuse
property as well, or that will be another nesting level working off 8
textures at the lowest level.

For an example of the second, there's plenty of stuff it can't do. Off the
top of my head, apart from launching new rays as Warp suggested (essential
for ambient occlusion), there's ramp/gradient shaders (shaders that can use
the level of illumination to select a colour), using any BDRF apart from
tweaked lambert with tweaked phong specularity, anisotropic highlights. You
can probably find more in the NG archives.


Tom

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> Is, with any system, a basic non-programmer user, capable of writing a
> shader that does more that what is possible with textures and pigments?

  Well, I think that's a bit like asking "is a basic non-programmer user
capable of writing a #while loop which creates 100 objects in a row?"

  Often some appropriate mathematics knowledge would be necessary to
perform certain things (such as knowing which direction to shoot a
ray towards), but POV-Ray could provide auxiliary functions to help
with this (in the same way as currently if you need to know the distance
between two points you don't actually need to know the mathematical
formula to do that because POV-Ray offers you the vlength() function
which you can use for this exact purpose).

  Sure, if you have no experience nor knowledge about the relevant
mathematics related to computer graphics, it will be quite more difficult
to write shaders. However, some basic things shouldn't be too hard to
create. And what a better way of learning some math while asking how
to do something specific.

-- 
                                                          - Warp

Post a reply to this message

> Warp  wrote in message <47079ed1@news.povray.org>:
>>   A shader should be able to, for example, launch additional rays if
>> necessary.
> 
> Yes, I understood that. And I ask again the question, this time more
> precisely:
> 
> Is, with any system, a basic non-programmer user, capable of writing a
> shader that does more that what is possible with textures and pigments?

No. Not a "non-programmer".  Since a shader consists in taking some
input (point position, normal,...), applying some algorithm, and
returning some final value, it's programming.

However, that's someting a beginner prorammer (someone who already
have the aptitude to create a #macro) should be able to do without
learning C++ first.

IMO, ideally, the shading language should be part, or a subset, of
SDL.

Fabien.

Post a reply to this message

> Nicolas George <nicolas$george@salle-s.org> wrote:
>> "Tom York"  wrote in message
>>> Yes. Although the actual shader language is usually quite low-level (often
>>> C-like), and therefore not particularly artist-friendly, most applications
>>> provide a specialised visual editor. These days they are usually based on
>>> nodes (plug a texture node into a diffuse shading node to get a texture
>>> mapped diffuse surface, for example). Some systems opt to use layers, but
>>> it ends up being the same. The systems are very powerful indeed, much more
>>> powerful than my textured diffuse example.
>> I do not think that can be called "writing" a shader.
> 
> Does it matter? As I said, I really doubt POV 4 will include such a visual
> editor.

But if there's a propre shading system, there are chances that someone
someday will write a GUI system like the one described to help designing
shaders.

Fabien.

Post a reply to this message

Fa3ien  wrote in message <47087cc2$1@news.povray.org>:
> However, that's someting a beginner prorammer (someone who already
> have the aptitude to create a #macro) should be able to do without
> learning C++ first.

Ok, to you and to Warp.

But in the scheme I have described, he would be able to write such a
function in Lua.

Post a reply to this message