FWIW, we have an existence proof that this is doable, we have customized RenderMan's version to support this, but we haven't upstreamed it yet because there were some niggling TODO's around defaults (

Ahh, yes, you're right -- that's more complicated than the copy we have locally. That extra complication is to deal with parameters that are arrays, and translating from SOA back to the AOS layout of

Yeah, that looks like I just "missed a spot" -- it turns out while we use keyword args, in our renderer, they've only ever been uniform across the batch so I didn't catch it. I don't have the cycles t

The intent was that if you had an existing method to parse the closure and decide what to do with them, you could just call that in a loop -- that's what our renderer does, and we've used something ve

Indeed Zap has hit on separate shaders one of the big reasons why what we have is more complicated, and the compile time being the reason you may not want this.

+1 to what Thomas said about executing a subset for a particular "context/stage/mode" of rendering. We currently have a bit more complicated way of doing this as we mix C++ and OSL shaders together, b

Nothing pressing from me, either. --Stephen

What actually ends up in the u,v globals isn't dictated by OSL -- it's renderer-dependent "local parametric coordinates" and will often be whatever happens to be most optimized for that renderer's int

On a similar note, the 25th is a big US holiday, and I'll definitely be skipping that one. Should we give it a pass as well? --Stephen

Agreed, this is looking really good across the variety of use cases. Is it wrong to have a favorite square? My favorite is easily the center square in color-band 4 of the blend shaded version. The way

I noticed the following recently, and I wanted to double check to see if I was missing something. Even though the language spec has this in it: Arrays may also be declared without a set length: ... wh

Necro-ing this thread because I'm looking at implementing something very similar. In prman, our C++ shaders support a form of "gather" connection to pull in a bunch of scalar values and feed them to a

The dict() functions are internal to OSL and I don't think they require support form the renderer, and a quick code inspection in our SIMD branch of the code in prman also looks like it supports them