[Bf-committers] From Farsthary another anouncement

Yves Poissant ypoissant2 at videotron.ca
Tue Feb 10 01:43:24 CET 2009

From: "joe" <joeedh at gmail.com>
Sent: Friday, February 06, 2009 3:05 PM

> Except I thought those renderers don't allow custom shaders,

They do. But they would not be called shaders I guess. Rather, they would be 
called custom BRDF.

> while we
> obviously have access to the legacy shading code in blender.  It seems
> if you hacked together BRDF black boxes like brecht said, you'd at
> least get a better result then the sort of conversions done for those
> renderers.

Of course, you can work on doing that blackboxing of legacy shaders into 
BRDF blackboxes. For some shaders, the way of doing that is already known 
and documented in papers. Some are actually quite trivial. For other, 
someone would have to hand derive the distribution functions for numerical 
integration and the sample distribution warping function for importance 
sampling. The mathematical technique for doing that is also documented in a 
Graphics GEMS (I don't have them with me so I cannot point to which specific 
one but there is the world "warping" in the article title). There are also 
other techniques. IMO, it is not worth the time to do that because they will 
alll give more or less the same material look anyway but one could do that. 
If someone can do that succesfully, then, indeed, you wouldn't need to 
convert the shaders parameters to BRDF equivalents.

> Ah so your saying a shading language would be used to define BRDF's?

That is quite possible if the shading language API provides all the hooks 
and power for doing that.

> What sort of constraints would it have?

A BRDF must provide much more services than a shader. A Shader basically 
receives a couple vectors and returns a color. A BRDF must be able to do 
that too. But it must also be able to provide the services oulined by Raul 
in his latest post here under the heading "The main functions are". Those 
other services are the ones that are going to be hard to implement in the 
black box wrappers discussed above.

> I'm just really curious, since
> I think a shading language would be an important part of a redesigned
> shading pipeline (at the very least, nodes would compile to it).

The "shading pipeline" is a first generation renderer paradigm. If you try 
to fit a physically based renderer into that strict paradigm, you will 
quickly bump into problems.


More information about the Bf-committers mailing list