Hymyly <chr### [at] hotmailcom> wrote:
> Aren't shaders used mainly for pseudo-realistic effects (such as creating
> shadows by superimposing a transparent texture generated from a stencil buffer)
> rather than proper raytracing? How do you envision a shader being merged with a
> full-fledged raytracer such as povray?

  What's the relation between "what shaders are usually used for" and
"what can be done with shaders"?

  Besides shaders are not mainly used for what you describe. They are mainly
used for texturing.

  I don't see the slightest problem in incorporating shaders to a raytracer.

> To me it seems that what could be introduced into povray is a system for
> altering the lighting model on a local level, which I agree could be done by
> creating a brand-new programming language.

  It's called "shader". Even the name implies it (shading algorithm -> shader).

-- 
                                                          - Warp

Post a reply to this message

> Aren't shaders used mainly for pseudo-realistic effects (such as creating
> shadows by superimposing a transparent texture generated from a stencil 
> buffer)
> rather than proper raytracing?

Yes, but that's only because they are mainly used by GPUs for real-time 
applications.  No reason at all why something similar can't be used in POV.

> How do you envision a shader being merged with a
> full-fledged raytracer such as povray?

What the shader must do, is to take some data as input (eg world space 
coordinates, uvw texture coordinates, surface normal etc) and return a 
colour value.  You could just define it as another user defined function 
type in POV.

Maybe something like:

#shader myShader( worldPos , texCoords , normal , rayDir)

 #local color = <0,0,0,0,0>;

 // add some suface normal modifier
 #local normal += noise3d(worldPos)*0.1;

 // add some basic ambient
 #local color.rgb += <0.1,0.1,0.1>;

 // loop through each light in the scene
 #local n = 0;
 #while( n < nLightsInScene )

  // add simple diffuse lighting
  #local color.rgb += vdot(normal,light[n].direction) * <0.7,0.4,0.4>;

  // and some specular
  #local color.rgb += pow( vdot(vreflect(rayDir,normal),lightDir[n]),40)) * 
<1,1,1>;

 #local n--;
 #end

#end

Post a reply to this message

Warp skribis:
>   It's called "shader". Even the name implies it (shading algorithm -> shader).

OK, fair enough, let's call it a shader.

In this case my first post was a proposition for how a rudimentary yet still
powerful _shader_ could be implemented into povray, without disrupting the
existing lighting model, and being relatively easy for newcomers to learn.

If you have other ideas feel free to share those. I am here to make povray
better, not to have an argument.

Hymyly.
And there was light.

Post a reply to this message

Hymyly <chr### [at] hotmailcom> wrote:
> In this case my first post was a proposition for how a rudimentary yet still
> powerful _shader_ could be implemented into povray, without disrupting the
> existing lighting model, and being relatively easy for newcomers to learn.

  You suggested a very specific (and thus limited) solution: To have an
"advanced reflection block" where you can define how many rays to shoot
and to which directions.

  This is a very limited solution. A better solution would be to be able
to define texturing shaders using a shader language. This language could
do almost anything (including sending new rays) and affect the texturing
of the surface in almost any possible way.

> If you have other ideas feel free to share those. I am here to make povray
> better, not to have an argument.

  I don't think POV-Ray will become better and competitive by adding even
more and more specific hard-coded features, making it more complicated.

  What POV-Ray needs is to become simpler: Less but more expressive features.
Instead of having 10 lighting models and 6 reflection models, it should
instead have one single solution: A generic shader language which can be
used to create 1000 different lighting models if you want.

  The renderer itself becomes simpler because it's not burdened by so many
individual hard-coded features, yet the scene description language becomes
more expressive, and you can do more with it than before.

  Of course this doesn't stop POV-Ray from having a library of shaders
which imitate what the current hard-coded lighting models and textures do.
(In some cases perhaps some hard-coded versions may be necessary for
speed reasons.)

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
>   Of course this doesn't stop POV-Ray from having a library of shaders
> which imitate what the current hard-coded lighting models and textures do.
> (In some cases perhaps some hard-coded versions may be necessary for
> speed reasons.)

It could have something like the current internal() stuff for isosurface 
functions.

Post a reply to this message

> #local n--;

Oh yes, we should definitely add that to pov4 SDL!

(remember that currently you need #local n=n-1;)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > #local n--;

> Oh yes, we should definitely add that to pov4 SDL!

> (remember that currently you need #local n=n-1;)

  I still think that it's better to develop a new language from scratch
than trying to patch the existing one.

  (And no, this doesn't mean the new language must look very different
from the current one. It just means that these suggestions all sound
like "this should be added to the *current* SDL", not "the *new* SDL
should have this feature".)

-- 
                                                          - Warp

Post a reply to this message

>> #local n--;
> 
> Oh yes, we should definitely add that to pov4 SDL!

and even I guess #local n++ should also be allowed ,-)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

> A better solution would be to be able
> to define texturing shaders using a shader language. This language could
> do almost anything (including sending new rays) and affect the texturing
> of the surface in almost any possible way.
> ...........
>   Of course this doesn't stop POV-Ray from having a library of shaders
> which imitate what the current hard-coded lighting models and textures do.
> (In some cases perhaps some hard-coded versions may be necessary for
> speed reasons.)

I agree with Warp ideas. We could compare such a technique with Design Pattern
in programming language. Design Patterns says just to avoid hard-coded
features.

Post a reply to this message

Warp wrote:
>   Of course this doesn't stop POV-Ray from having a library of shaders
> which imitate what the current hard-coded lighting models and textures do.
> (In some cases perhaps some hard-coded versions may be necessary for
> speed reasons.)

And in point of fact, hard-coding the common algorithms is something 
that ought to be considered for version of POV-Ray beyond v4.

I know that there will be trade-off considerations.  Code that is 
simple, small, and very commonly used will be hard-coded first.

The way POV-Ray currently does macros allows something to be done with 
macros at the start, then implemented in binary later, and the only 
thing that has to be done to make the scene code work is to comment out 
the macro.

Giving the SDL the capability to detect whether a keyword is part of the 
SDL may be the simplest way to support this.  #ifndef makes semantic 
sense in this regard:

#ifndef(function_name)
   // SDL code to define function_name()
#end

Until function_name is hard coded, the code block defines the function 
and its behavior, but one it's defined, the SDL version is no longer 
needed and is no longer parsed.  If done right, the effect should be 
transparent to later users of the code.

Regards,
John

Post a reply to this message