#3delight vs renderman windows#

Our 2nd workshop at the filmakademie in Ludwisgsburg, Germany. Speakers Jordan from the Foundry & Christos after the talks Special thanks to Jordan & Jen from The Foundry, Pixar's RenderMan Team. Refreshments and welcome start at 6:30 p.m, followed by our presentation at 7:00 p.m, leaving plenty of time for networking with our presenters and reps from Foundry before and after.' You’ll hear from Jordan Thistlewood, one of Foundry’s senior product managers, who is in town to talk about the latest developments in Katana, and the exciting things planned for 2017.Ĭhristos Obretenov of LollipopShaders will be joining us to showcase his latest work on 'Layering with PxrLayerSurface and Katana.'

#3delight vs renderman windows#

Katana is Foundry’s high efficiency CG look development and lighting tool, available for Windows and Linux. Location: Vancouver, Canada April 19 2017ĭescription: 'Join us for our first Katana meet-up in Vancouver. Presentations & Q&A - Photo Stephen Kelloway Presentations & Q&A - Photo Mark Flanagan Pre-event social hour - Photo Mark Flanagan Lineup! Waterfront Theatre, Granville Island - Photo Mark Flanagan Special thanks to Pixar's RenderMan Team, The Foundry, Max Liani, Matt Leonard, Mark Flanagan.

The very 1st Official Pixar RenderMan User Group Meeting in Vancouver! Held at the Waterfront Theatreon Granville Island, we had Max Liani from Pixar's RenderMan engineering group in Seattle, Christos Obretenov of LollipopShaders, Max Leonard from ILM Vancouver, and Mark Flanagan from Double Negative Vancouver. Special thanks to Arkel Rasiah, Volker Helzle, the filmakademie. Thanks to the filmakademie for hosting our 3rd workshop in Ludwigsburg Germany earlier this month on on HDR Light Capture and advanced Path Tracing in RenderMan, always great to go out there!ĭay 1 AM: Image capture in vfx, Shading paradigms in vfxĭay 1 PM: Practical capture, Equipment use/setup, Lighting setup captureĭay 2 AM: Rendering with RIS in RenderMan: overview, RIS vs REYES.ĭay 2 PM: Making Light maps, Making HDRIs (Photoshop+RV), Stitching maps (PtguiPro+RV), Gray/Color correction (Nuke+RV)ĭay 3 AM: More EnvLight: Importance Sampling, Area Lightsĭay 3 PM: Studio/Outdoor session, Practical capture II, More Lighting setup capture/ Hiresolution capture In general, if you are interested in using C++ dependencies but with a C-API, watch this project – C++-.Location: Ludwigsburg, Germany Jul圓-5 2017 You can grab specializations that expose a C-only API from an OpenSubdiv Rust wrapper. It uses CMake, can be built with the (default) CPU backend only and then has no further dependencies.Īdd it as a git submodule and a bit of CMake and you should be good to go.īeing C++ It uses some template classes that require a specialization, each, to be usable. If you wanted to add support for subdivs, Pixar's OpenSubdiv is a painless dependency (as in: as painless as it gets in C/C++ land). Workaround: ignore these attributes and just render the control cage as a polygon mesh. NSI also supports subdivision surfaces via extra attributes on the mesh node. It's based on reality – it doesn't have a concept of a light as something special.Ī bit more work: in your version/fork of the DCC plugins you can expose shader nodes only mirroring what your renderer supports. Same for lights which are just geometry with a surface shader emitting, in OSL. A bit of a hack but should be good enough. If you map what you have in the renderer to these two shaders and intercept dlTexture nodes plugged directly into their slots you will have something that is 90% useful w/o adding OSL support. They also recently added an implementation of Autodesk Standard Surface – dlStandard. The most used one is a Disney Principled based Uber shader called dlPrincipled. It's just that shaders are assumed to exist outside the renderer.ģDelight ships with a set of artist friendly OSL shaders and these are well integrated with the DCC plug-ins. NSI's shading system is built around the idea that the renderer supports OpenShadingLanguage (OSL) to describe shader graphs.Īgain, that being said: the API makes no assumptions in that regard. The DCC plug-ins have support for IPR viewport rendering which won't work w/o scene edits but that feature can probably be isolated with some #ifdefs to make everything work if this feature is not implemented.

Built a more robust API with an interactive scene state.īut this is not mandatory.To support this, too, you will need to add this bit that I saw on your todo list The NSI API supports scene edits via NSIRenderControl('sync'.).