Gaffer is a node based lighting and lookdev application that studios can extend

A lighting tool that is also a framework

Gaffer is described as a VFX application that enables look developers, lighters and compositors to easily build, tweak, iterate and render scenes. The topics it covers on its own repository point at the same audience, and the application framework angle is the part that distinguishes it from a lighting package.

The README says Gaffer provides an application framework for studios to design and create their own VFX production pipeline tools. That is a different proposition from shipping a lookdev application. A studio can use Gaffer as it is, and can also build its own internal tools on the same foundation, which is the argument a technical director makes when deciding whether to adopt a project rather than write a house tool.

Two things make that possible and both are named in the README. Gaffer supports in-application scripting in Python and in OSL, so VFX artists and technical directors can design shaders, automate processes and build production workflows. And the application is built using the Cortex libraries, shipping with a multi-threaded, deferred evaluation engine and a flexible user interface framework.

The deferred evaluation engine is the piece that matters for how the tool feels. A node graph where a change is evaluated lazily, rather than recomputed eagerly, is what lets a look developer tweak a light and see the result without a full re-render of the scene. The multi-threading is what keeps that responsive.

The homepage is gafferhq.org, and the documentation is published there, with developer notes on the Gaffer developer wiki. Community participation is gated on the project Code of Conduct, which the README points at directly.

Binary releases exist, but the source build is the documented path

Compiled binary releases are available for download from the releases page, and Gaffer is officially supported and tested on Linux, on RHEL, Rocky and AlmaLinux 9, and on Windows, on Windows 10 and 11. That is a short and specific platform list, and it is the first thing to check if you are considering a studio deployment on anything else.

The README then gives a full build procedure, and the shape of it is what distinguishes Gaffer from a typical application build. Gaffer depends on a number of third party libraries, and the recommended source is the pre-built dependencies from the Gaffer dependencies project, which are used in the automated test builds and so are guaranteed to be up to date with Gaffer's requirements. The dependencies distribution forms the basis of a Gaffer build, and the root of the expanded archive becomes the BUILD_DIRECTORY passed to scons.

The clone step is the usual one.

git clone https://github.com/GafferHQ/gaffer.git
cd gaffer

Then the dependency installer, which the README describes as the easiest way to get the right dependencies version. It downloads the correct version for the version of Gaffer you are building and unpacks them to a directory of your choice, and in the example the target is a gaffer-build directory next to the checkout.

./config/installDependencies.sh ../gaffer-build

The build itself is scons, with the build directory passed in.

scons build BUILD_DIR=../gaffer-build

And the result is a launcher in the build directory's bin folder.

../gaffer-build/bin/gaffer

The README also notes that if scons has issues finding dependencies or tools, the SConstruct file lists the various options that can be set to specify their location, which is where to look when a build fails on an unusual machine.

The prerequisite list is short but exacting

The build requirements are given as a table, and the README is direct about the consequence: without these tools you will not be able to build Gaffer.

The main requirements are gcc at version 11.2.1, scons and inkscape. The presence of inkscape in that list is unusual for a C++ application and tells you something about the project: documentation images and icons are part of the build rather than being prepared by hand.

Building the documentation is optional, and it has its own requirements. Sphinx is needed at version 4.3.1 or above, together with a set of Python modules, namely sphinx_rtd_theme at 1.0.0, myst-parser at 0.15.2 and docutils at 0.17.1.

Two caveats are attached to all of this. The first is that the list changes from time to time, and the README points at a Podman setup in the GafferHQ/build repository for a complete and up to date method of installing the prerequisites on Linux, and that is the same container used for building automatic releases. The second is that specific package names may differ depending on the Linux distribution and repository, which is the usual friction when a project supports a family of enterprise distributions.

The target platform is stated as well. Gaffer targets the VFX Reference Platform and the README says it is currently on CY2025, which is the reference platform release that a studio's own pipeline configuration is likely to be pinned to.

Cycles comes with the dependencies, Arnold and 3Delight do not

Renderer support is where the build options come in, and the README explains the split plainly. Gaffer dependencies ships with Cycles, but to build the modules for one of the other supported third party renderers you need to set the appropriate scons options pointing at your installation. The two options are named: ARNOLD_ROOT for Arnold and DELIGHT_ROOT for 3Delight.

The command looks like this.

scons build ARNOLD_ROOT=/path/to/arnold BUILD_DIR=...

That is a one line difference in the build, but the operational consequence is larger. A studio with an existing Arnold installation can build a Gaffer that knows about Arnold, while the Cycles path works out of the box because the renderer ships inside the dependency distribution. The same applies to 3Delight.

This also frames the difference in approach between the two ways of getting Gaffer. The binary releases are the fast route for an artist who wants to open a scene and light it. The source build is the route for a studio that needs a specific renderer integration, a patched build, or a version aligned with its own pipeline, and it is the route that the dependency installer and the BUILD_DIRECTORY convention exist to support.

The repository layout is consistent with a project of this size and age. There are src/ and include/ for the C++ code, python/ and startup/ for the Python side, shaders/ and glsl/ for shading, usdSchemas/ for USD support, apps/, bin/, config/, contrib/, doc/, resources/ and arnoldPlugins/.

Releases move quickly and the nightly build sits alongside them

The release history shows a project on a steady cadence. The listed releases are 1.7.4.0 on 2026-10-09, 1.7.3.1 on 2026-09-25, and a nightly build entry dated 2025-10-28. The last push to the repository was on 2026-10-15, days after the 1.7.4.0 tag, so the main branch is ahead of the newest release at any given moment.

The versioning itself carries information. The four part numbers, 1.7.4.0, are a studio convention rather than a semantic version, and they signal that patch level 4 of the 1.7.4 line is a specific, named configuration that a pipeline can be pinned to. For a VFX studio, the version string is a contract, not just a label.

The licence is BSD, with the file at the LICENSE path, and the copyright notice lists three holders: John Haddon, Image Engine Design Inc. and Cinesite VFX Ltd., each for 2011 to 2026. The repository also carries a Changes.md file, which is where a studio would look to see what moved between two pinned versions.

The community process is documented and slightly unusual. Questions and troubleshooting go to the Gaffer community group on Google Groups rather than to GitHub issues, and the same applies to feature requests: the README asks you to request a feature on the community group and not to create an issue on GitHub for it. Bug reports and contributions go through the contribution guidelines in CONTRIBUTING.md.

Editorial conclusion

Gaffer fits a studio or a technical artist who needs one lighting and lookdev tool that runs on Linux and Windows, and who wants to script it in Python or OSL rather than click through a renderer's own lookdev package. It is a poor fit if you need a single application with no build step and no dependency management, since the binaries are there but the source build is the deeper workflow. Verify first which Gaffer version your studio's pipeline expects, because the release line moves quickly, and read the VFX Reference Platform note before planning a build against CY2025.

Frequently asked questions

Official sources

1. GafferHQ/gaffer on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases