My desire is to get these primitives working with the ScanlineRenderer.All of this Scene subclassing talk is under the assumption I'm writing the renderer?If not, I don't really get how I'm supposed to give this subclassed Scene to Nuke.
And really, thanks...for the time Could someone from the Foundry comment on the performance impact of multiple requests ( and by multiple this would mean one for each primitive that appears in a scanline ). From: jegs...@earthlink.net Subject: Re: [Nuke-dev] Primitive material assignment Date: Fri, 2 Mar 2012 10:44:22 -0800 To: nuke-dev@support.thefoundry.co.uk 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, 2I'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
_______________________________________________ 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
