just curious.
could this extract deep information from a scene?
in arnold, as i understand it, during render the information nessesary
for a deep image is calculated but not saved to a file.
this is a long shot but could get interesting.
_sam
On 2/17/2012 7:17 AM, Jep Hill wrote:
Hello all,
Here's a little demo I did to showcase a Nuke utility I wrote to highlight the capabilities of a new
functionally that my company has developed using the Cortex open source libraries. With the help of John
Haddon, we have created an "open framebuffer" for Nuke... it basically creates a TCP/IP socket to
which many renderers/3D packages (Arnold,PRman,3Delight,etc) and can be ported directly into Nuke
framebuffers thus bypassing the host packages render view. These are NOT read nodes -- they are LIVE
connections to the renderer's render stream via a custom display driver. The difference in renderers is
invisible to the user -- the tool figures all that stuff out... and it can actually support multiple
renderers/3D packages at the same time. This allows us to use Nuke as a common denominator for a
multi-package and multi-discipline pipeline and preview all renders REAL TIME. This helps avoid issues that
arise from not being able to hire talent due to the fact that they aren't familiar with "this" or
"that" package. I'm a fan of becoming package agnostic and allowing people to work the way that
best suits them.
We can actually start comp'ing the frames, on the fly, as they render... in addition, we
can import an .ass file directly into Nuke, automatically detect all AOVs (including
custom AOVs), and allow the user to toggle AOVs on and off inside of Nuke. The goal
behind this is to be able to better plan which render passes will actually be used in
Nuke without having to go back and forth between packages... even better, we don't have
to save out preview renders one frame at a time from one or more 3D package. Along with
streamlining your workflow, this should lead to optimized use of storage and network
bandwidth. In this case, the process does not change the exported scene file (although I
could modify it to) -- it's simply meant to make the most out of an exported scene file
to then communicate back to the lighter which passes the compositor will be using in the
comp. The lighter would then make the appropriate updates to the scene in the 3D package
and render out the needed sequences... once they are done, the compositor can simply
replace the "ieDisplay" nodes (open framebuffer nodes) with Read nodes.
All the AOV functionality does work seamlessly with the Rib compliant renderers
as well; That video is coming out soon...
One more thing, I realize that large houses have similar tools however, these
drivers are now *open source* and included in the Cortex tools... now we can
all share in the fun.
I hope you'll enjoy the demo:
http://vimeo.com/j3pnyc/using-nuke-as-a-render-preview-to-any-3d-renderer
Cheers,
Jep_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
