Re: Review: fix derivatives of mod()

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 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.
After 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!


Join { to automatically receive all group messages.