Date
1  7 of 7
Review: fix derivatives of mod()
Larry Gritz <l...@...>
http://codereview.appspot.com/189073
Ugh, still having trouble making it send all review emails to this list automatically.  Larry Gritz l...@...


Larry Gritz <l...@...>
Anybody?
On Jan 14, 2010, at 11:58 AM, Larry Gritz wrote: http://codereview.appspot.com/189073 Larry Gritz l...@...


Jonathan Gibbs <jono...@...>
The mod() function was zeroing out derivs. I think it's pretty simple, mod(x,y)Well, I'm not sure what to think. The derivatives of mod(x,y) is the same as x most of the time, but at the discontinuity? Not sure what else you could really do since the function isn't continuous... jono On Fri, Jan 15, 2010 at 8:37 PM, Larry Gritz <l...@...> wrote: Anybody?


Larry Gritz <l...@...>
On Jan 15, 2010, at 8:54 PM, Jonathan Gibbs wrote:
Well, I'm not sure what to think. The derivatives of mod(x,y) is the Well, there's "math" and then there's "what's useful in shaders." In the strict mathematical sense, the derivative is undefined at the discontinuity (x==d), though you could speak of the limit as you approach from x<d versus x>d. My guess is going to match at least one of those! I'm not sure what we can do that's any smarter or more useful in a case like this.  Larry Gritz l...@...


Jonathan Gibbs <jono...@...>
Well, there's "math" and then there's "what's useful in shaders."Agreed. You answer seems the most useful one. jono


Chris Foster <chri...@...>
Hi guys,
On Sat, Jan 16, 2010 at 4:15 PM, Larry Gritz <l...@...> wrote: Well, there's "math" and then there's "what's useful in shaders." In theAfter quite some thought I agree that d/dx mod(x,a) == 1 is about about the best you can do, even though it doesn't make sense at the discontinuity. It is possible to make sense of the derivative of mod() using the Dirac delta distribution, but that's definitely a "math" thing rather than a "what's useful in shaders" thing :) I had a think about alternatives, and ended up concluding that the only other possiblity is analytical antialiasing of the derivative at the discontinuity. However, that doesn't seem to be right because 1) It only makes sense when mod() is being used in certian ways for pattern generation. 2) It means that mod needs to take derivatives of its arguments which presumably makes things less efficient. 3) Surely if the derivative is being antialiased, the function value itself should be? 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... 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! ~Chris


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 antialiasedOh yes, I've written AA'd versions of many of these at various times. "aastep" (aka "filterstep" in RManland) 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 thinkThanks! 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 l...@...

