Food for thought: You might not want to break the ability of your plugin to concatenate with Transforms upstream in all cases. The only time when it's annoying is when there's motionblur, because the Transform implementation of sample() explicitly disables motionblur.
But for every other case, you'd benefit from your plugin doing its thing in a single filtering hit, and it would be a shame to break that for all cases. You could try to check whether your input is a Transform AND input->isMotionBlurring(), and then use input->motionBlurSample() instead of sample(). That would give you the motionblurred sample, but unfortunately it won't do any further filtering (as in, the effects of your lens distortion would be unfiltered). I don't know if there's a better/smarter way to go about it. But in any case, instructing artists to manually break concatenation when needed might be better than breaking it always. Other nodes behave the same way (lens distortion, stmap, warps, etc), so artists shouldn't find it too strange :) On Mon, Mar 26, 2012 at 10:51 AM, joshimbruglia <nuke-dev-re...@thefoundry.co.uk> wrote: > Hi Ivan, > > That looks like it may be the problem, I'm definitely calling > input0().sample() within my code. I tried the following: > > input0().getTransform()->sample() > > and > > input0().getTransform()->concat_input()->sample() > > but both caused nuke to crash, it looks like I may just have to wrap it up > as a gizmo with a grade node in front. a shame really. > > josh > > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > _______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
