Jim Charter <jrc### [at] msncom> wrote:
> Since we are undertaking the conversation.  I would enjoy having you 
> sketch this out a little more.   I hit a bump, conceptually, when I see 
> the term 'shader language'.  I am not really sure what it means in 
> relation to the texturing that POV uses.  You are usually pretty good at 
> sorting out these kind of semantic/conceptual tangles for us that are 
> less technical.  For instance I thought that 'shader language' went 
> along with 'scanline rendering'

  Shaders are not inherent to scanline-renderers, even though the vast
majority of shaders are used in scanline-renderers (most notably modern
3D acceleration cards support shaders).

  The idea of shaders is that instead of having a limited set of hard-coded
algorithms for calculating surface texturing (which was the case with older
renderers, older 3D acceleration cards, and closest to home, is the case
with POV-Ray), the engine offers an efficient language which can be used to
add new algorithms used to determine the color of the surface.

  Let's take, for example, the 'finish' block of POV-Ray. While there are
quite many parameters to fine-tune, it's still a fixed amount of possible
parameters. As an example, fresnel reflection is available only because
it has been added to the core code. However, if you would want to test
with some other type of reflection algorithm there just isn't an easy
way (the only way is to modify the source code and recompile the program).

  A shader language allows you to create new types of algorithms to calculate
reflection, or almost anything else related to the surface coloring.

  There are many nice tricks which can be relatively easily achieved with
shaders (which would otherwise require specific hard-coded support in the
core code) such as furry texturing, subsurface scattering, etc.

  Of course it's not like this feature was mandatory for povray, but it
would be nice to have.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Jim Charter <jrc### [at] msncom> wrote:
>> I hit a bump, conceptually, when I see the term 'shader language'.
> 
>   The idea of shaders is that instead of having a limited set of
> hard-coded algorithms for calculating surface texturing <snip>
> the engine offers an efficient language which can be used to
> add new algorithms used to determine the color of the surface.

Just to add a bit to what Warp has said.

A shader language would allow a user of SDL access to more of what 
POV-Ray knows abut a surface, light_source, etc.

An example is the calculation of a specular highlight which requires 
knowledge of the angle of incidence of a light_source to a surface. 
Bringing that information to the user on a ray by ray basis would allow 
for things like:

#if AOI > SomeNumber color_it_this_way #else color_it_another_way

or

pigment { AOI * Something + SomethingElse color_map { ...

A possibly more exciting example to a traditional media artist like 
yourself: You'll be familiar with the concept of shading and tinting 
paint. POV-Ray (effectively) shades colors as they darken, with access 
to the illumination of a ray intersection, you could instead tint colors 
as they lighten.

  -Shay

Post a reply to this message

Warp and Shay, Thanks and thanks.

I think it is always good to expose internal functionality to the 
artists, where possible. I will always remember the creative spurt that 
accompanied the introduction of the trace() and eval_pigment() functions 
which I saw in just that way, as exposing internals to the user.

Post a reply to this message

FYI I will this weekend attempt to get a wiki set up on povray.org.

-- Chris

Post a reply to this message

> 
>   Let's take, for example, the 'finish' block of POV-Ray. While there are
> quite many parameters to fine-tune, it's still a fixed amount of possible
> parameters. As an example, fresnel reflection is available only because
> it has been added to the core code. However, if you would want to test
> with some other type of reflection algorithm there just isn't an easy
> way (the only way is to modify the source code and recompile the program).

We could imagine this :

- a shading language with it's own syntax (it have to be very
"programmatic"), allowing any algorithm one can imagine

- while, in POV-Ray SDL, existing texture/pigment/normal/finish features
are kept mostly as they are currently, but actually (and transparently 
to user) uses stuff defined in the new shading language.

Each existing pattern, reflection algoritm,... has to be transcribed
in shading language, which would form a huge base of sample code to
start writing new shaders.

Users can limit themselves to existing stuff without re-learning
anything.  Those who'd like to get their hands dirty can do it with
a smooth learning curve.

this would also put all texture-related algorithms out of POV-Ray's main
code, and allow people who aren't high-end programmers to contribute
to an important part of POV-Ray (thus less time spent on it by better
programmers in the re-write process).

(light sources and cameras should also become shaders, ideally, BTW)

note : some years ago, someone made a "POV-Man", which was POV-Ray
with the ability to use RenderMan shaders.  It would be interesting
to find it back and have a look.

Fabien.

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
>
> Just to add a bit to what Warp has said.
>
> A shader language would allow a user of SDL access to more of what
> POV-Ray knows abut a surface, light_source, etc.
>
>   -Shay

As an illustration of that, we can 'pigment' and 'normal' our textures with
user-defined functions. Its is highly embryonic, but it already opens
perspectives for those who can imagine functions. I guess some of you have
obtained nice results.

And in addition, POV's principle of having user-modifiable patterns
(including functions) with color_maps or pigment_maps and many
possibilities for 'finish' is so much flexible that all the stuff produced
so far with POV uses it.

This makes me say that, in a way, POV has already some kind of 'shader
language'.

BUT: we can (it's time to) go much further. A true shader language might
open entire worlds for artists and for those who want to ilmitate nature.
Ideas welcome. Can somebody remind us Renderman's approach of shaders? We
can get inspired by existing solutions.

Bruno

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> - while, in POV-Ray SDL, existing texture/pigment/normal/finish features
> are kept mostly as they are currently, but actually (and transparently 
> to user) uses stuff defined in the new shading language.

  That assumes that they will be as fast as they are currently. If changing
them to use the shading language would make them slower then it would be
a setback.

  The purpose of a shading language is to open new options, not to make
existing options worse (ie. slower).

-- 
                                                          - Warp

Post a reply to this message

In general I think that the object definition syntax of the
current SDL should be preserved.  I also agree that the
addition of additional features would be good, though
command-set bloat should be avoided. My wish list includes...

1) An optional "environment {}" command section where
the command line options for a scene can be placed within
the scene file (like the COBOL environment section).
One objection I've read on this is that letting the
environment (image size, animation options, etc.) be set
from inside the scene file breaks compatibility with the old
system, but it would be easy to get around that by just
adding a "default" setting to quick-rez, if it's rendered with
default it reads environment {} otherwise it ignores it.

2) Better medias. IMO fixing this will eventually lead to
re-defining the syntax for medias, and possibly the need
to resort to scan-line like routines, particularly for things
like sub-surface light scattering.  The upside here is the
possibility of describing the way a media should look,
instead of tweaking commands to the routines that are
supposed to get the look, but often don't.  This matches
the original philosophy of SDL, SDL is a description of
a scene, not a description of the algorithms needed to
render a scene.

3) Binary reading from files.

4) Post processing of images. This could fall under something
like a post_process{} section.  One thing that might be nice
here would be the ability to directly produce animation files in a
couple of formats.

5) Allow the linking of external libraries, so that POV can
access custom programming routines from various languages.

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> - while, in POV-Ray SDL, existing texture/pigment/normal/finish features
>> are kept mostly as they are currently, but actually (and transparently 
>> to user) uses stuff defined in the new shading language.
> 
>   That assumes that they will be as fast as they are currently. If changing
> them to use the shading language would make them slower then it would be
> a setback.
> 
>   The purpose of a shading language is to open new options, not to make
> existing options worse (ie. slower).

If the shaders are compiled on the fly before rendering (which is, IMMSMW,
what POV-Man did), could they really be slower than hard-coded ones ?

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> If the shaders are compiled on the fly before rendering (which is, IMMSMW,
> what POV-Man did), could they really be slower than hard-coded ones ?

  It assumes that the shaders can be compiled and that the compiler will
be able to optimize them in the same way is the C++ compiler optimizes the
current algorithms written in C++.

-- 
                                                          - Warp

Post a reply to this message