http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.

--
Larry Gritz
l...@...

Anybody?


On Jan 14, 2010, at 11:58 AM, Larry Gritz wrote:

http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.

--
Larry Gritz
l...@...

The mod() function was zeroing out derivs. I think it's pretty simple, mod(x,y)
has the same derivs as x, right?

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?


On Jan 14, 2010, at 11:58 AM, Larry Gritz wrote:

http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.

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

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

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...@...

Well, there's "math" and then there's "what's useful in shaders."

Agreed. You answer seems the most useful one.

--jono

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!

~Chris

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
l...@...