I’ve just stumbled upon an extremely interesting project called Gaffer coming from Image Engine’s open-source kitchen. It’s an application framework focused on writing node-based VFX apps under the surface and a look dev/lighting/compositing app very similar in concept to Katana on top of it. It’s based on Cortex and Python and provides 3Delight, Arnold, Alembic, OpenColorIO and OpenImageIO support amongst other things. Similar to Katana, it can handle complex scenes gracefully, loading only those elements that are active for viewing/editing at the moment and it can be integrated for an interactive workflow with other apps (for ex. acting as a shader authoring tool or lighting tool for Maya). While it may seem pretty rudimentary at the moment, it shows quite a potential down the line.
I heard of katana but never really grasped what the program actually is for. Could some one point me out a couple of really good things I could do better in such a program rather then directly in the 3d package?
Well i never used it ; but i think it is for huge library management.When I saw the demonstration presentation i remember saying “interesting” , by it self it lets you edit parameters of objects,scenes and materials but when used with conjunction with a 3d package and compositor / nuke it makes the workflow and complex scenes manageable …
it is like a library manager which directly works with render plates… a uber-fancy-detailed outliner / data sheet manager
Off the top of my head, one big advantage of Gaffer (and Katana) compared to “regular” 3D apps like Blender, Maya, etc. is the deferred loading of 3D assets. Meaning that the complete scene can have hundreds and hundreds of millions of polygons, but the user can control which objects are loaded into memory and shown in the viewport and which are represented just with their bounding box. That way you can work with extremely heavy scenes without needing an insane amount of RAM.
Another advantage is the procedural nodal workflow, which once again enables the user to deal with complex scenes that have a huge number of objects/lights/shaders/textures/etc. in an elegant way. For ex. since the assets are stored separately from the scene and are only referenced by the scene, handling changes and different versions of the assets is straight forward. Trying different assets or different versions of the same asset is as simple as disconnecting one node and connecting another or even better using a switch node that controls which upstream node is passed on downstream.
Yet another advantage also related to the nodal approach is the simplicity of building reusable lighting/shading/etc. setups, that can be encapsulated and then have them present only the relevant controls to the user. And so on…
AFAIK both Katana and Gaffer don’t have any modelling, object animation, painting or similar asset creation capabilities. They instead rely on previously prepared assets (for ex. Alembic files) to “populate” the scene.
Unfortunately there are no pre-built Gaffer binaries for Windows at the moment. I don’t know how difficult it would be to build it from the source, though.
With Gooseberry production starting soon, maybe some of these concepts should be revisited? Especially the non-direct management of assets over a 3D View method.
Need to finish up the basics first and then restructure how the C++/python bindings are generated since now everything is just clumped into a single lib to make is easier for testing.
