Hi everyone!

<rambling>
It seems to me that one of the main recurring feature requests in the POV-ray
groups has to do with the lighting model. Some want to include Bi-directional
Reflection Distribution Functions (BRDFs) to simulate accurately things like
diffuse reflections and anisotropic surfaces. Others think things like that
would bloat POV-ray without adding any really useful functionality.

What strikes me though is that we have yet to see someone proposing _how_ such
features could be implemented, rather than just saying "we should have it" or
"it's impossible". This is what I am trying to do.

First of all, I think that the lighting model used by POV-ray is excellent. It
has been in use for well over a decade, and can easily last one more.
Eventually however, the current lighting model will be obsolete, and the sooner
we start introducing a new one the better. This feature does however not have
that much to do with the lighting model. Backwards compatibility comes before
awesomeness.
</rambling>

What I propose is the following. It is subject to alteration.

A keyword such as "adv_reflection" be introduced into the finish-block. This
keyword can be used to shoot rays. Normally when a ray hits an object, two rays
can be shot away, the reflected and the refracted; both these rays follow the
laws of physics. The adv_reflection keyword will allow you to specify
additional rays to be shot, possibly hundreds or thousands (you know, if you
happen to have HAL 9000 in your basement).

The direction, intensity, and even origin of the additional rays are completely
customisable. This feature could therefore be used to create portal-looking
objects, by shooting a ray out of object B when a ray hits object A. You could
also use it to create retroreflectors, and all kinds of cool stuff.

The syntax I propose is that within the adv_reflection block should be three
blocks:

1. origin
2. direction
3. intensity

If any of these are omitted, POV-ray should default that particular block. If
all blocks are omitted, adv_reflection should behave like regular transparency.

Within these blocks the location where the ray hit, the surface normal at that
point, etc, should stored into some keyword, such as "origin" and "normal"
perhaps. You then write an expression using these keywords.

Exactly how intensity should work together with conserve_energy, I haven't got a
clue. Yet.

====And the grand finale for all of you BRDF-freaks out there:====

If you use a random function within any of the blocks above, you will get
different rays coming out from each hit. Also, the entire adv_reflection block
should have a "count" parameter, specifying how many rays are shot at each hit.
This way, true anisotropic or diffuse reflection (and refraction for that
matter) can be simulated.

I don't expect this just to get plugged into POV-ray exactly as I have described
it, and your input is very valuable - developers and noobs alike.

Hymyly.
And there was light.

Post a reply to this message

The better solution is, as already mentioned about a hundred times,
to create a shader language which, among other things, supports shooting
additional rays.

  The renderer doesn't need to worry about how the colors are mixed or
anything because it's the user-written shader which defines everything.

-- 
                                                          - Warp

Post a reply to this message

Warp skribis:
> The better solution is, as already mentioned about a hundred times,
> to create a shader language which, among other things, supports shooting
> additional rays.
>
>   The renderer doesn't need to worry about how the colors are mixed or
> anything because it's the user-written shader which defines everything.
>
> --
>                                                           - Warp

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?

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. I did contemplate this while
sketching the ideas outlined in the previous post, but abandoned it on the
grounds that this would be more difficult for newcomers to learn. Writing the
alterations directly into SDL seems like a more streamlined way of doing it,
which is why I proposed that instead.

Of course, a specifically designed shader-like language for povray would be more
flexible, so if you have any specific ideas for how such a language would be
tied into povray without disrupting the existing design, feel free to share it.

Hymyly.
And there was light.

Post a reply to this message

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