Lazy evaluation


Jono Gibbs <jono...@...>
 

Hello OSL-folk!

I've been thinking about our shading system and how it maps to OSL, and am curious what y'all think.

First, our shaders inputs are evaluated in a very lazy fashion. For instance, if a shader had input colors A and B, both bound to the output of other shaders, then code like this:

if (something) {
return A;
} else {
return B;
}

Would cause only one of the two input shaders to be evaluated and not evaluated until "A" or "B" was first needed.


Then on top of the we allow shaders to modify the global shading state, so I can do:

uv *= 4;
result = A;
uv *= 12;
result += B;

And the result is the shader attached to "A" sees different uvs than "B" does.

The benefit is we can write some powerful shaders which are very useful in a dag/graph authoring environment which otherwise would need more nodes and more user-visible complexity.


So, is this just totally an abomination?

--jono --mobile--

On Mar 16, 2010, at 8:41 PM, Larry Gritz <l...@...> wrote:

Minor oversight on my part: Cliff, please don't commit the change until we get a signed CLA from Chris. I've sent it to him as well as posted it in the "downloads" section of the google code web site.

Sorry for the mixup.

-- lg


On Mar 16, 2010, at 4:58 PM, Chris Foster wrote:

On Wed, Mar 17, 2010 at 9:20 AM, <cliffo...@...> wrote:
Description:
Here are some fixes to get OSL to compile with gcc-4.4.2. Some of these
fixes I shamelessly lifted from Chris.F's patch from a while back. It's
mostly pretty straightforward.
LGTM2. Good to see the patch I posted a while back wasn't too moldy
to be slightly helpful :)
--
Larry Gritz
l...@...




--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@... .
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en .