Re: Review: fix derivatives of mod()

Larry Gritz <l...@...>

On Jan 16, 2010, at 2:07 PM, Chris Foster wrote:
That leads me to idly wonder if there's any call for an antialiased
version of mod (or more likely, floor(), since the user can then
trivially construct their own antialiased version of mod)? I notice
that you've included an aastep(), but that's arguably more useful than
aafloor() and easier to implement too...
Oh yes, I've written AA'd versions of many of these at various times. "aastep" (aka "filterstep" in RMan-land) is there mostly for historical reasons. Other aa functions are a little trickier and tend to be in the private shader libraries of any decent shader department rather than making their way into the standard library, but there's no good reason for that.

By the way, I very much like what you're doing here with OSL. I think
the use of dual arithmetic for derivatives is particularly neat. I've
toyed with the idea before, but you guys have done all the hard work to
actually implement it, wow!
Thanks! I'd been wanting decent derivs of arbitrary calculations without needing grids or "extra points" (such as described in my JGT 1996 paper about BMRT), and had always hoped something like this approach would work. But I never worked out the details until now. It was nice to have Dan Piponi's paper "Automatic Differentiation, C++ Templates and Photogrammetry" (JGT, 2004) to point the way. Even as we were implementing it, I wasn't sure it was really going to work out, but it really does a quite satisfactory job.

By the way, after I wrote the Dual2<> template (based on Dan's paper) and the first few shadeops that used it, Cliff Stein implemented the bulk of the routines computing derivatives, and Chris Kulla went the extra mile of extending our noise routines and OIIO's texture lookups to *return* derivatives as well as values, when needed.

Larry Gritz

Join { to automatically receive all group messages.