It *can* be, at least that's why it wasn't done that way in the original design, but there may now be ways to do multiple requests() without paying a big penalty - perhaps someone from the Foundry can chime in about it. If I remember right, each request() could cause the cache to be flushed in the original design.
But, since you're clearly in rendering code rather than shader code, you can also create your own Scene subclass and override Scene::request() to make sure the Primitives get their materials properly requested (normally Scene::request() is called in Render::request()). It's pretty cheap to just call Render::_request() and then iterate over all the GeoInfos again. -jonathan On Mar 2, 2012, at 10:30 AM, Frederich Munch wrote: > That's unfortunate... > > While I've got an ear, would there be a huge performance penalty if > Iop::request is called from inside an rPrimitive whenever intersect_scanline > returns true? > So far this seems to be the only way to always get the materials working at > render time > > And thanks! > > > From: jegs...@earthlink.net > Subject: Re: [Nuke-dev] Primitive material assignment > Date: Fri, 2 Mar 2012 09:10:17 -0800 > To: nuke-dev@support.thefoundry.co.uk > > I don't think the default Scene::validate() method checks each primitive of a > GeoInfo for dissimilar material assignments in order to call request() on > them…which is an oversight. The intention was there in the original design > to allow each Primitive to have a separate material assignment, but it was > never done in practice before Nuke left DD. One obvious use for this is a > particle system with each particle primitive is assigned a unique material. > > Put in a bug report to the Foundry about it! > > -jonathan > > On Mar 2, 2012, at 4:11 AM, Frederich Munch wrote: > > Generating primitives with differing materials via Primitive::material_ is a > bit sporadic in whether it woks or not, and I'm trying to figure out why. > This is the error that will occur when this is done: "Warning: > <NodeName>Interest(channels=0xf), but request() not called." > > The GeoOp in question has three possible material assignments: input 0, 1, 2 > I've tried a variety of things including calling request on the inputs in > GeoOp::_validate as well as always iterating over all the primitives during > GeoOp::geometry_engine and calling validate/request there. > Iterating all the primitives during geometry_engine works -most- of the time, > but seems pretty heavy, especially considering there's no way to test if > we're actually on a path to rendering... > > Is there any secret, or additional house-keeping that needs to be done? > > > _______________________________________________ > 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 > _______________________________________________ > 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
