LGTM2 http://codereview.appspot.com/205043/show

Reviewers: dev-osl_imageworks.com, osl-dev_googlegroups.com, Description: I forgot one important case in the get_light_side function - some closures receive light from both sides simultaneously (like

Now it looks clear. The only thing I don't like is using eval_sidedness of None for singular closures. Now I'm using sidedness to choose visible lights and this is going to break it. Can you avoid

I'm not sure I understand - we were already returning None from get_light_side() for singular closures before. Can you setup a test case for me to look

It breaks with my other review, so nothing that you could actually reproduce now. But the case is this. Think of a reflective plane that is reflecting a sphere light. That reflection comes from the

But the behavior for singular closures does not change in this review. So it sounds like something is already broken. http://codereview.appspot.com/206064/show

Is not broken now, because we don't use the sidedness to discard lights from the light loop. We use it to discard direct sampling, but not when sampling the closures. But now, with my added extra

Right - what I meant is that its already broken in your other review, regardless of this change. Let's discuss this more in the other code review. Since the behavior doesn't change for now - can I

That's right, but if you commit that how are we going to fix it? http://codereview.appspot.com/206064/show

No, wait a minute. Singular had already been taken out of MIS for optimization. This is not going to break anything. I still would change it, but it is safe to commit. Go

We could have get_light_side return front/back but then skip the eval loop for singular closures for instance. Whatever we come up with needs to be coordinated to your other fix. This change is only

This change No problem, go ahead. As I said in the previous reply we moved singular out of the light loop some time ago, so my code won't break anything. http://codereview.appspot.com/206064/show

Reviewers: dev-osl_imageworks.com, osl-dev_googlegroups.com, Description: This adds 'spline' to OSL. This op-code is a bit on the heavy side w.r.t. templates and that's due to the variety of ways

Wow. LGTM. I think you went way above and beyond the call of duty on this, Cliff. Ignoring knot derivs would probably have been fine. In fact, I would go so far as to say perhaps you should have a

Have you considered making the test an image instead of text only? Its kind of hard to know if this is working correctly or not by just looking at the

I sent from wrong account. Posting again to avoid bounce from SPI alias... Good point, Chris. An image would be great here. Might I suggest writing the shader so that it interpolates the spline

looking at During testing, I did plot the output (w/ 1000 points) of the various bases with gnuplot and they all looked pretty good. But I can try

That would make the basis "varying", which the code currently doesn't allow, but that can be changed. I'll make the change -- it shouldn't be tough to

Don't knock yourself out over varying basis (though if easy, please do), I was suggesting this only as a way to have a single image test show all the bases. -- Larry Gritz l...@...

Now I've spent nearly a week doing the comprehensive changes that allows a compile-time switch to select whether we use runflags, explicit indices, or spans. (Most of that time fixing the subtle bugs