NukeRef adds a PureRef-like reference board directly inside the Nuke Node Graph. Copy an image, hover over the DAG, paste, and the image appears as a clean reference backdrop under the cursor.

The tool comes from Denis Rychkov and targets the usual reference problem in comp: screenshots, lookdev frames, texture grabs, paint notes, and client-provided “can you make it more like this” images usually live outside the node graph. NukeRef pulls them into the working space instead of asking the artist to split the screen or jump between viewers, browsers, and image boards.

What it actually builds

The script creates reference images as regular BackdropNode objects. Each reference backdrop stores its position, size, and metadata, then renders the image through two paths. The native path uses BackdropNode.setCustomIcon, which also feeds the DAG mini-map. The overlay path uses a transparent QWidget attached to the DAG window and paints the image with Qt for Python. On macOS, the script enables the Qt overlay because the Node Graph is treated as a stable native widget named DAG_Window. On Windows, the script disables that overlay path and relies on the native custom icon route, because the code identifies the DAG as a volatile GL widget. That is the kind of boring implementation detail that becomes very exciting when a tool does not explode mid-shot. The script imports PySide2 first and falls back to PySide6. It also imports shiboken2 or shiboken6 for Qt object liveness checks. That matters because Nuke UI widgets can disappear while scripts still hold Python wrappers. Dead wrappers are where “works on my machine” goes to retire.

Paste first, ask questions later

NukeRef binds Paste Reference to Ctrl+V in the Node Graph. Copy an image from a browser, Photoshop, or the operating system clipboard, then paste in the graph. The script reads clipboard image data first. It also accepts local image file URLs if the extension matches png, jpg, jpeg, tif, tiff, or webp. When the clipboard does not contain an image, the script delegates back to normal Nuke node paste behaviour. That means regular copied nodes should still paste as nodes, not become collateral damage in the reference-board revolution.

Copy Reference binds to Ctrl+C. When exactly one NukeRef backdrop is selected, it copies that reference image back to the system clipboard. If the selection contains anything else, the script falls back to native node copy. This is qutie civilised for a shortcut override.

Saved next to the script

NukeRef requires a saved Nuke script before it can store pasted image data. Unsaved scripts trigger a message asking the user to save first, because reference images are written beside the .nk file. The storage folder is named nuke_ref_images and sits next to the Nuke script. Pasted clipboard images are saved as PNG files with timestamped names. Local image paths can also become reference backdrops. That design keeps the .nk file small because the script stores paths and metadata on the backdrop instead of cramming image payloads into the node graph. It is also the reason references travel with the shot folder rather than a screenshot lost in Downloads, which is where production evidence goes to become folklore.

Aspect ratio, mini-map, and resize behaviour

The script records each source image’s native width and height on hidden knobs. When an artist changes bdwidth, the knob callback recalculates bdheight from the stored native dimensions. The default reference width is 400 DAG units, or the source width if the image is smaller. The code creates the BackdropNode, centers it near the cursor position, sets the display size, hides the normal backdrop label by setting a tiny note font size, and stores the source path and native dimensions in invisible knobs.

The mini-map support comes from the native custom icon path. The overlay can make the main DAG view cleaner on macOS, but the mini-map sees the native BackdropNode icon. That is a practical split: pretty drawing in the graph, native visibility in the navigator. During resize, the script records a short timestamp and dims the overlay to 30 percent opacity for 0.20 seconds after bdwidth changes.

Installation is old-school

Installation uses the familiar .nuke folder route. Copy nuke_ref.py into the local .nuke directory, then add import nuke_ref and nuke_ref.install to menu.py. Restart Nuke, copy an image, hover over the Node Graph, and paste with Ctrl+V on Windows or Linux, or Cmd+V on macOS.

Price and license

The tool is free. The release note mentions an MIT License, but the uploaded script and setup guide do not include MIT license text.

https://www.linkedin.com/feed/update/urn:li:activity:7465470321228300289

https://drive.google.com/drive/folders/1-MiiUsfbJiyCvxZFy3eeAvuh6nrM6tqI

The post NukeRef Adds References to Nuke first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Beeble is a AI based VFX toolset built around video to video processing, including SwitchX for background replacement, object inpainting, and relighting, plus Switch Light for generating compositing passes such as normals, albedo, roughness, specular, metalness, depth, and alpha.

The short version: yes, you can use it in Nuke

The Nuke Plugin enables a workflow that stays inside Nuke: load a pass set, connect it to a controller, then drive lighting with dedicated nodes. It targets relighting work where you want quick iterations without building a full CG relight setup from scratch, but still want predictable inputs and knobs you can animate. You need Nuke 14.1v2 or newer. The plugin is working on Windows and macOS. If your show sits on Linux, that missing test line matters.

Install: one folder, one line, one restart

Installation is classic Nuke: unzip the plugin folder, move the Beeble folder into your .nuke directory, then add a single plugin path line to init.py. On macOS, the target path is ~/.nuke/Beeble/. On Windows, it is C:\Users.nuke\Beeble. After restart, the plugin appears on the toolbar as a new menu.

If you want the lowest-drama rollout on a facility machine, treat it like any other Nuke plguin deployment: version the folder, keep init.py changes minimal, and test on a clean user profile before you touch shared configs.

What the plugin actually wants: a very specific PBR stream

The plugin’s key constraint is the PBR multi layer format. It expects a single image stream containing multiple Nuke layers named Source, Normal, Basecolor, Roughness, Specular, and Metallic. The node reference calls this “PBR multi layer stream” the core input, and the controller and light nodes all build on it.

There are three supported ways to feed it: EXR sequences, PNG sequences, or MP4 videos. EXR needs each frame to carry multiple passes packed into layers in a single EXR file per frame, such as Frame_000001.exr. PNG and MP4 need one pass per sequence or video, arranged so the loader can map names to the expected pass inputs.

This is also where the tool draws a hard line between convenience and correctness: if your pass naming or folder layout drifts, import stops being one click.

Load PBR Passes: the most important button is the first one

The Quick Start flow begins in the Nuke toolbar: Beeble, then Load PBR Passes. You point it at an unzipped folder of VFX passes. For PNG, the folder must contain subfolders for each pass, and each subfolder holds a PNG sequence like Normal/Normal_000001.png. For MP4, the folder must include one video per pass named .mp4 such as Normal.mp4.

When you load PNG or MP4, the plugin automatically creates a PBRPacker node to pack the six inputs into a single multi layer stream. For EXR sequences, the PBRPacker is not needed because the passes are already packed into layers. If you ever need to build the stream by hand, the helper menu exposes PBR Packer, and it takes exactly six inputs in this order: Source, Normal, Basecolor, Roughness, Specular, Metallic.

PBR Controller: fix the material before you blame the light

After import, the plugin creates a PBRController node. It exists for one reason: adjust pass intensities and blending before lighting.

Source Blend ranges from 0 to 1 and blends between BaseColor at 0 and Source at 1. Roughness Exposure, Specular Exposure, and Metallic Exposure each run from minus 2 to 2 and adjust intensity in stops. This is the difference between a light that looks wrong and a material that was weighted wrong.

If you plan to publish a facility preset, this is the node to standardize. It is also the node to keyframe if you need a shot that shifts from dry to wet, but still stays within the same pass set.

Lights: three nodes, clear ranges, and a Merge plus

Lighting lives under Beeble, then Lights. The basic rule stays consistent: connect the PBRController output to the light input, tweak properties, then stack more lights with a Merge set to plus. That Merge plus step is explicitly called out for multi light setups.

Directional Light exposes a horizontal rotation from 0 to 360 degrees and a vertical rotation from minus 90 to 90 degrees, plus light color and an intensity multiplier that starts at 0 and defaults to 1.0.

Point Light exposes XY position in pixels, Z depth from minus 5 to 5, light color, intensity starting at 0 with default 1.0, decay starting at 0 with default 2.0 described as inverse square, and maxDistance starting at 0 where 0 means infinite reach.

Environment Light applies image based lighting using an HDRI and takes two inputs: the PBR multi layer stream plus the HDRI. The Quick Start notes you load the HDRI file and connect it to the light input. The node reference describes HDRI as the second input, and the environment light output is RGBA like the other light nodes.

Limits and gotchas you should not ignore

The documentation states the prerequisites clearly: Nuke 14.1v2 or newer, tested on Windows and macOS. It also defines the pass set rigidly as six layers in one packed stream. If your pipeline produces additional passes like depth or alpha, the Nuke Plugin page does not list them as inputs for the PBR stream.

Use it where you can afford to iterate and where the pass set stays stable across the shot. Lock your ingest, standardize your pass naming, then let artists work with Directional, Point, and HDRI lights like they would in any comp, with the added bonus that they can animate light behavior using regular Nuke tools. And yes, test it before you commit. New tools are great at demos and even better at breaking when a client sends a new plate at 2am.

https://docs.beeble.ai/integration/nuke-plugin
https://docs.beeble.ai/tutorial/nuke-tutorial

Suggested tags:

The post Beeble Nuke plugin: relight with passes first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The latest update to Nuke Stage stays with the preview: real-time playback of photoreal environments on LED walls, plus live compositing tools that shoulkd feel familiar to artists. The tool targets virtual production and in camera visual effects (ICVFX), with a workflow designed to keep VFX artists in creative control on set.

The core stays high-resolution playback for 2D and 2.5D environments, with EXR as the playback format and USD used for 3D geometry. Live compositing comes from a set of Nuke nodes rewritten for real-time performance, so operators can blend the on-set environment with the physical build and manage the relationship between camera and screen.

The practical takeaway: this is not a game engine project that happens to output to a wall. It is a VFX-flavoured playback and live comp system that tries to keep your pipeline language intact.

The parts you actually run on set

Foundry built a three part architecture: an editor where the operator works, a headless networking relay, and render nodes that run on each machine driving the wall. A launcher defines where those processes run and can start them across a larger stage, then the editor connects to the relay and render nodes and reports cluster health.

A typical topology puts the editor and relay on the control machine, distributes renders to the render nodes, then sends images to the wall. The setup flow walks through networking first, then hardware outputs and physical displays, then display mapping, and then cameras and tracking. Configurations can be exported and imported so teams do not have to repeat the same stage setup every day. Unless they want to. But in general, that is the unglamorous part of virtual production that still decides whether you shoot before lunch or after dinner.

Metadata Vault: your future self says thanks

The headline feature is metadata capture via a Vault that records on-set decisions for handoff into post. The Nuke Stage supports logging scene data, camera tracking, lens metadata, timecode, scene settings, and colour decisions. The Vault documentation also describes two capture workflows: Snapshots for a point-in-time save, and Take Record, which creates a camera USD file between defined start and end points.

If you have ever tried to reproduce a wall look from a vague note like “match take three but slightly warmer with some *Ooompf* “, this aims to make the record concrete. It will not fix bad habits, but it can at least preserve what you actually did on set.

NotchLC and EXR playback, plus a faster sequencer loop

On the playback side, the feature list now includes native support for NotchLC and B44 EXR for high-resolution background playback. There is a drag-and-drop sequencer panel, one-click keyframing, and editing and interpolation tools for timing changes.

In the operator view, the track-based sequencer remains central. Content created in Nuke can be staged over time, keyframed, and adjusted live for collaborative iteration with the on-set team.

USD scenes and splats, now aimed at the wall

Nuke Stage supports importing OpenUSD scenes that can be edited and overridden for real-time blending of virtual and physical sets. For file and colour standards, the tool lists OpenEXR and OpenColorIO alongside ACEScg support via ACES. It also claims support for HDR and a color pipeline intended to carry creative decisions from set into post.

For scene representations, the tool now highlights importing and controlling Gaussian Splats for high fidelity 3D scenes, alongside standard USD geometry. In the broader ecosystem, Foundry also shipped Gaussian Splat support in Nuke and built a USD based 3D system in there too, which positions splats and USD as shared data types across stage and post.

Standard hardware, scaling, and the usual fine print

The product page repeats the goal of running on commodity hardware without specialist media servers or bespoke equipment, and scaling across render node clusters. It frames this as cost and setup-time control and as a way to make stages repeatable.

Pricing is not specified in the sources. The product page offers a register your interest contact flow.

New tools and innovations should be tested before use in production, especially anything that touches playback codecs, cluster timing, genlock, tracking inputs, and colour consistency. Run your own worst-case plate, your own camera tracking feed, and your own handoff into post before you bet a shoot day on it.

https://www.foundry.com/products/nuke-stage

The post Foundry expands Nuke Stage for LED walls first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Neat Video runs as a denoise plug-in inside apps like Adobe After Effects, Adobe Premiere Pro, Apple Final Cut Pro, Blackmagic Design DaVinci Resolve, and Foundry Nuke. It cleans up shots without making you leave your host, which is the nicest kind of cleaning.

What 6.1.2 actually changes

Neat Video 6.1.2 shipped on 9 April 2026. The update targets three very practical areas: support for new Apple Silicon graphics hardware, compatibility with newly released host versions, and small workflow and stability improvements across plug-ins and platforms.

Boris FX welcomes Vegas Pro

The headline compatibility additions are support for Apple M5 Pro and M5 Max GPUs on macOS, support for Nuke 17 on Windows, macOS, and Linux, support for Nuke Studio 17 and Nuke Indie 17 on Windows, macOS, and Linux, plus support for Vegas Pro 2026 on Windows.

If your pipeline depends on host upgrades staying unblocked, that list matters more than any marketing adjective. A denoiser that falls behind host compatibility turns into the most expensive bypass node you never wanted.

Vegas Pro 2026 support on Windows

6.1.2 adds support for Vegas Pro 2026 on Windows. What is clear is the intent: the update aligns the plug-in with the newest Vegas Pro release line, so editors on that host can update without losing access to the denoise plug-in. If your finishing workflow includes cuts or conform work in Vegas Pro, this update keeps that lane open. And, if you think that EWgas is getting a second wind, you don’t have to miss your favourite denoiser.

Nuke 17, Nuke Studio 17, Nuke Indie 17 compatibility

6.1.2 adds support for Nuke 17 across Windows, macOS, and Linux, and adds support for Nuke Studio 17 and Nuke Indie 17 across the same trio of platforms. In a mixed facility where artists jump between OS builds or where show work crosses between Linux workstations and macOS laptops, that cross-platform statement carries scheduling weight.

Some teams will care about this update purely because it removes friction around moving to Nuke 17. Others will care because they have already moved and need the denoise step to catch up. Either way, the result is the same: one less reason to keep an older host version installed just to keep a plug-in alive.

Apple Silicon M5 Pro and M5 Max support

Version 6.1.2 adds support for Apple M5 Pro and M5 Max GPUs on macOS. The practical promise is simple: GPU-accelerated processing for faster renders on Apple Silicon M5 Pro and M5 Max machines.

Updating, licensing, and what costs money

6.1.2 is described as the latest update improving compatibility and support for new software and hardware, and it is free for licensed users of version 6 of the product.

To update, the release directs users to the My Products page. The My Products page requires login access through the vendor site, so you should expect the usual account-based download flow rather than a public direct installer link for licensed builds, or a line of smooth WinGet.

Upgrading from older major versions gets described in two ways across the official materials provided. Owners of versions 1 through 5 can upgrade to the new major version 6 with a discount. Another official upgrade page adds extra detail: version 6 can coexist with version 5 or older and does not replace it in current projects, a v6 demo is available to try before upgrading, and users who purchased version 5 within the last 12 months receive an additional discount.

Pricing of a single-copy license price is €72.90 for the Home edition and €136.90 for the Pro edition on several host categories. The same page also shows discounted bundle pricing for certain host combinations, but the exact bundles and discount figures vary by host section on that page. If you buy based on a specific host, verify the exact host row you plan to license, because the page layout presents pricing per host family.

https://www.neatvideo.com/news/nv612

The post Neat Video 6.1.2 adds Vegas 2026 and Nuke 17 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Feature animation gets performance-obsessed

A new set of feature animation sessions puts character performance front and centre. Supervising Animator Adam Sarophim will present how performance-driven animation gets built at Sony Pictures Imageworks using work from KPop Demon Hunters and GOAT. The session description focuses on crafting emotion, personality, and audience connection through movement, timing, and subtle detail.

Animator Jacob Frey will present The Animation of Zoomania 2 and describe collaboration between art and technology as part of the filmmaking process at Walt Disney Animation Studios. The session description frames the work as an example of how tools and artistic intent meet inside a feature pipeline. Details about specific story beats, pipeline tooling, or shot counts are not specified in the Sources.

Two European-leaning projects also land on the slate: The Last Whale Singer (a teenage humpback whale named Vincent), and a procedural real-time pipeline segment called Trash Island. The speakers listed for that session are Jan Hofmann, a CG Supervisor and Unreal Engine expert at Telescope Animation, and Amir Ashkezari, an FX Supervisor and Technical Director at PFX. The pipeline description centers on Houdini generated assets moving via OpenUSD into both real-time Unreal Engine and a traditional Autodesk 3ds Max and V-Ray workflow, connected by custom tools intended to support daily collaboration between studios in different locations.

Zako is a feature project based on a true story about an Armenian painter during World War II and the Soviet Union. Director Tigran Arakelyan of OnOff Studio will present how VR animation can serve as a core creative tool for sketching, staging, and animating directly in 3D space, as well as practical methods for integrating VR animation into a feature film production pipeline.

AI talks that aim past hype

The Artificial Intelligence track is around practical production use and the question of what AI should do in modern pipelines, with an emphasis on keeping a human artist in the loop.

Ben Grossman of Magnopus is listed for an individual session, followed by a panel appearance. Mohsen Mousavi, Senior Director of Visual Pioneering at Eyeline Studios, is also in an individual session and on the same panel. Hao Li, founder of Pinscreen, is about to present on work spanning computer vision and facial performance technology, having completed AI work on Fallout Season 2. The track is curated by Mike Seymour, co-founder of fxguide.

Cinematography goes deep into the lens mess

The Cinematography track highlights craft from stop-frame production through to photoreal VFX . Cinematographer Dave Alex Riddett will present Work Aard Play Aard, a behind-the-scenes look at decades of cinematography at Aardman and the practical skills involved in stop-frame storytelling.

VFX Supervisor Victor Perez will present GLASS: Capturing the Lens Look for Photorealistic VFX. The session description focuses on lenses having distinct optical characteristics including distortion, chromatic aberration, field curvature, vignetting, iris behavior, and micro-contrast, and on methods to analyze, measure, and reconstruct those characteristics inside VFX pipelines so CGI inherits the visual identity of the camera that shot the plate. The track is curated by Sara Coppola-Nicholson, Director of Research and Education at Cooke Optics.

Partners bring cloud and tools to the conversation

Two newly announced partners add their own angle on production infrastructure and creative tooling. AWS Visual Computing is about cloud-based solutions for visual effects, animation, and 3D content production, including scalable rendering, virtual workstations, and high-performance storage optimised for media workflows. It also highlights AWS Deadline Cloud as a fully managed render management service.

Foundry is … well, if you don’t know the company making Nuke, you should reconsider and read the rest of this website. The partner programming showcases compositing, lighting, look development and texturing, with participating studios named as Industrial Light and Magic, RISE FX, Outpost VFX, and Mikros Animation.

The partner section also includes an in-person day at Raum Mannheim featuring project insights on Fallout Season 2, Netflix’s The Dinosaurs, and Teenage Mutant Ninja Turtles: Chrome Alone 2 – Lost in New Jersey, plus a talk by Director and VFX Supervisor Hugo Guerra.

Dates and tickets, plus the reality check

Tickets are on sale, and the “On Site” runs at Haus der Wirtschaft in Stuttgart from May 5 to 7, Online and On Campus run on May 8, and On Demand runs from May 9 to June 9. See all of you there!

https://fmx.de/en

The post FMX 2026 adds animation, lens talks and of course AI first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the event: FMX is where post, VFX, and realtime folks compare notes, spot new workflows, and meet toolmakers from Foundry to AYON .

The 30th edition runs on site May 5 to May 7, with Online and On Campus on May 8, and On Demand from May 9 to June 9. Early Bird ticket options run until March 20. Tickets are sold through the ticket shop, and the full schedule is published as an online program schedule.

This year’s reveal is a broad spread across VFX, animation, and digital media creation, with more updates promised as additional speakers and topics get added. The headline message is simple: the program is live now, and it is designed to be browsed like a buffet. Get your preferred morsels here :)

RENO turns a studio inward

A newly confirmed session in the Shorts track focuses on RENO, an original sci fi short used as a live testbed for virtual production and machine learning workflows. The session names Tav Flett, Rob Hifle, James Pollock, and Paul Silcox, and describes how a traditionally post-driven VFX studio re-engineered its pipeline for a newly opened virtual production stage. It also calls out Gaussian splat scanning, automated rotoscoping, and marker removal as tools for streamlining production.

Generative video, now with shot notes

The hype cycle is almost over. The bubble tends to pop the moment somebody asks where this stuff fits into an actual production pipeline. That is the useful angle of Moonvalleys‘ session in the “The Road ahead” track. . Instead of treating generative video as a party trick, Ben Lock looks at what happens when studios try to use it for real: control, continuity, versioning, integration, governance, and all the other small details that usually kill shiny ideas on contact.

For VFX and animation teams, that is the point. Not more halfbaked sizzle reels, but a sober look at where generative video already helps, where it still breaks, which parts of the panic were never grounded in production reality, and when studios may begin hiring artists again once practical applications, and their many many limits, are easier to assess.

Predator: Badlands, built as a handoff

A joint presentation in the VFX for Features track names Laurens Ehrmann from The Yard VFX and Dominik Zimmerle from TRIXTER discussing work on Predator: Badlands. Shared assets, shared look development, and constant creative exchange across studios to ensure continuity while elevating environments, characters, creatures, and effects, plus a deep dive into selected sequences and the creative and technical challenges behind them.

And there is more to come! Much more!

https://fmx.de/en/program/program-2026/overview

The post FMX 2026 program goes live first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Nuke from Foundry is a node based compositing application used in feature film and episodic VFX. It ingests multi pass renders, deep data and USD scenes, and sits downstream of layout, animation and lighting while feeding DI and delivery.

Gaussian Splats go native

Foundry has released Nuke 17.0 with native support for Gaussian Splats. Artists can now import, view, manipulate, render and export splat data directly inside Nuke without third party conversion tools. Gaussian Splats are point based scene representations in which radiance is encoded as collections of anisotropic Gaussians rather than polygonal meshes. In Nuke 17.0, splats can be imported via GeoImport or GeoReference nodes and visualised in the Hydra based 3D viewer.

Rendering is handled through the SplatRender node, which supports depth output, deep output and motion blur. GeoDeletePoints enables non-destructive point removal, while GeoGrade allows colour grading operations on splat data. Field Nodes integrate with splats, enabling combination and transformation of point data. According to Foundry’s documentation, these nodes allow non-destructive masking and manipulation of 3D data, including Gaussian Splats.

USD 3D system leaves beta

The new USD-based 3D system is now fully released. It is built on Pixar’s Universal Scene Description and is intended to bring structured scene management into Nuke’s compositing context. A new import dialogue enables selective loading of data from complex USD scenes, including payload control and item-activation toggles. GeoImport supports USD with scene graph metadata as well as Alembic cameras and geometry. Axis nodes now include new constraint input pipes such as LookAt, Translation and Rotation constraints, alongside a Snapshot function to freeze transforms.

Camera workflows have been extended. Viewer locator visibility is improved, GeoCamera nodes can be created directly, and GeoEditCamera allows direct editing of USD camera data. Projection tools have moved into ScanlineRender. Cylindrical projection and UV Unwrap are supported, including UDIM tile outputs.

Material workflows have been aligned with USD and MaterialX. MtlXStandardSurface supports MaterialX Standard Surface preview and render in the Hydra viewer. New shader nodes include ReflectiveSurface for reflections and refractions, BasicSurface and WireframeShader. Legacy equivalents such as ConstantShader, FillShader and MergeLayerShader are retained.

Material binding is handled through GeoBindMaterial, which includes Binding Strength and Purpose controls to balance performance and render fidelity. Lighting nodes have been expanded. USD light attributes can be pulled directly into Nuke without baking. Updated DirectLight, SpotLight, PointLight and EnvironmentLight nodes include shadow toggles and output channel controls.

New USD aligned light nodes include GeoEditLight, GeoDistantLight, GeoDiskLight, GeoSphereLight and GeoDomeLight. Controls extend to intensity, exposure, falloff type, focus and colour temperature, with terminology aligned to physically based workflows. ScanlineRender now exposes explicit ray tracing controls, including Max Ray Depth and separate depth limits for reflection, refraction and diffuse rays. Motion blur controls include Shutter, Shutter Offset, Shutter Segments and Shutter Bias.

AOV output control has been expanded with Z depth, motion vector variants and independent surface AOV toggles. GeoMask and GeoClearMask nodes enable 3D masks to cascade down the node graph with visible indicators, improving readability in complex setups. GeoPython provides direct Python access to USD prims and schemas inside the scene graph, allowing scripted edits to USD data within the comp context. Graph Scope Variables can now operate inside USD scenes to swap geometry, cameras and textures based on variable logic.

BigCat scales machine learning

Nuke 17.0 introduces BigCat, extending the existing CopyCat machine learning toolset. While CopyCat focuses on shot level training, BigCat is designed for large scale dataset training across tens or hundreds of shots. BigCat supports data augmentation to generate variation for lighting and motion conditions. Validation tools include validation loss graphs and a validation contact sheet. Custom loss functions such as LPIPS are supported to encourage structural and semantic alignment beyond simple pixel difference metrics.

Graph Scope Variables mature

Graph Scope Variables receive a production ready framework update. Python callbacks and API integration allow custom code to be triggered on variable events. Root node knob expressions such as frame range and fps can drive dynamic variable values. Variable names can now be displayed in node labels for improved script readability. Foundry reports performance improvements for large scripts using Graph Scope Variables, though no numerical metrics are published.

Annotation and UI refinements

The annotation system has been overhauled. Drawing tools are more responsive, brushes are redesigned and a dedicated comment panel is introduced. Visual indicators aim to clarify review notes within the node graph.

In the 3D workspace, node colour coding, mask icons, scene graph filtering and live read indicators have been updated to improve clarity. Error and warning visibility in the viewer and node properties has also been enhanced. By the way, if that person looks familiar: You’ve read a whole story about that project in Digital Production:

We Hunt Giants

Core performance and colour

Core image processing updates include significant acceleration in TVIScale. Foundry states that GPU upscaling can be up to 98 times faster and CPU upscaling up to 26 times faster than previous behaviour. Deep composite rendering is reported to be up to 1.88 times faster to viewer and disk. Test conditions are not detailed in the documentation.

OFX plugins are no longer artificially resolution-limited. Plugins, including Furnace OFX, can now run at full hardware resolution. HDR MOV reading and writing now preserves YCbCr matrix, colour primaries and transfer functions. Native ACES 2.0 configurations are included. NotchLC codec support for MOV ingest and export is available on Windows and Linux.

Platform alignment and SDK updates

Nuke 17.0 supports USD 25.08 and aligns with VFX Reference Platform 2025. Third party libraries updated under this platform include Boost, OpenColorIO, OpenEXR, TBB and OpenVDB. OpenAssetIO and OpenAssetIO MediaCreation libraries are upgraded to version 1.0.0, with MediaCreation at 1.0.0 alpha.12.

Camera format support is updated via the latest Sony SDK and SMDK, including support for Burano firmware version 2 and 3.8K and 4K formats. Monitor out updates include AJA NTV2 17.5x, DeckLink 14.4 and NDI 6.x SDKs, with 10-bit support.

Parallel release for conservative pipelines

Alongside Nuke 17.0, Foundry has released Nuke 16.1. It includes most of the same feature updates but is built on the VFX Reference Platform 2024, allowing studios additional time to migrate their infrastructure.

Nuke 17.0 is available to customers with an active subscription. Pricing details are available from Foundry’s official product pages.

As with any major release that modifies 3D scene handling, machine learning workflows and core processing behaviour, facilities should validate performance, memory usage and pipeline compatibility before deploying to live productions. New tools and innovations should always be tested in controlled environments before use in production.

// Foundry Nuke 17.0 release notes
// https://learn.foundry.com/nuke/17.0v1/content/release_notes/nuke_17.0.html

And, if you want, you can compare it to the release of the Beta version in November:

Foundry Opens Nuke 17 Beta: New 3D System, New Variables

The post Nuke 17.0 rewires 3D and adds Gaussian Splats first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Foundry develops tools including Nuke and AI features such as CopyCat. Griptape is an AI orchestration platform with a Python framework and node interface, aimed at integrating multiple AI models into production pipelines.

A strategic buy, not a feature drop

Foundry has confirmed the completion of its acquisition of Griptape, an enterprise AI orchestration platform founded in 2023 in Seattle. According to Foundry, the acquisition adds orchestration capabilities to its existing AI-powered features, which began in 2021 with the release of CopyCat inside Nuke. CopyCat introduced machine learning training directly within the compositing environment. The Griptape acquisition is positioned as the next step in that strategy. Foundry states that the deal accelerates its AI roadmap by enabling the orchestration of multiple AI models and agents within professional workflows that integrate with its existing creative toolsets. The company describes this as critical as studios move from AI experimentation to routine production use.

No financial details of the acquisition were disclosed.

What Griptape is

Griptape describes itself as an “enterprise-grade AI orchestration platform”. It was founded in 2023 by former Amazon Web Services veterans and offers a dual-layer architecture. The first layer is an open-source Python framework. This provides programmatic control over AI models and agents. The second layer is a node-based visual interface designed for artist-facing workflows.

According to Griptape, the platform enables controlled access to open-source and commercial AI models within a secure and traceable framework. It is designed to balance model flexibility with the security requirements of large-scale production environments. The company states that Griptape is already in use at several leading production studios. Specific studio names were not disclosed.

Orchestration, not generation

Foundry’s announcement does NOT mention generative features. Instead, it focuses on orchestration. In practical terms, this means managing how multiple AI models and software agents are invoked, connected and governed inside a production pipeline.

Foundry highlights the need for better control over AI models as studios shift towards daily production use. It positions Griptape as a framework that allows access to both open-source and commercial AI systems while maintaining security and traceability. Traceability in this context refers to tracking which models, prompts or agents were used in a workflow. This is increasingly relevant for studios that must document provenance and comply with contractual or regulatory requirements.

Programmable agents in production

A central point in the announcement is Griptape’s support for secure, programmable agents. Agents in this context are software components that can execute defined tasks using AI models and other tools. According to Foundry, these agents can operate within Griptape and across the wider pipeline.

The company distinguishes this from simple conversational interfaces. The implication is that Griptape is not positioned as a chat-based assistant but as a programmable layer. This distinction matters for production environments where repeatability, logging and integration with asset management systems are required.

Context within Foundry’s portfolio

CopyCat marked the first visible step in that direction inside Nuke. Griptape shifts the focus to pipeline architecture rather than isolated ML nodes. From a technical perspective, the combination of a Python framework and a node-based interface aligns with established DCC and pipeline patterns. Python remains the dominant scripting language across VFX facilities. However, no specific integration APIs, SDK updates or version dependencies have been detailed, as well as integrations with Katana, Mari, or even Flix. It is also not clear how authentication, model hosting or cloud dependencies will be managed within Foundry’s subscription-only ecosystem.

What is not yet stated

Several practical questions remain unanswered, for example, no pricing information for Griptape under Foundry ownership has been published yet. It is not specified whether Griptape will be bundled with existing Foundry licences, offered as a separate subscription, or integrated into enterprise agreements. These omissions are not unusual at the acquisition stage. But they will matter to pipeline TDs and production engineers planning near-term infrastructure changes.

At present, the confirmed facts are limited to the acquisition itself, Griptape’s architectural description, and Foundry’s intent to integrate it with Nuke and broader pipelines. As always, new tools and innovations should be tested thoroughly before use in production environments.

https://www.griptape.ai/

Foundry.com

The post Foundry buys Griptape to “orchestrate AI” first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Katana from Foundry is a look development and lighting application used in feature animation and VFX. It sits downstream of asset creation DCCs and upstream of final rendering, managing complex scene assembly and renderer integration.

Foundry has released Katana 9.0, introducing a new USD centric framework called UsdSuperLayer alongside new USD lighting and material nodes and early support for Hydra 2 in the Viewer. The company positions UsdSuperLayer as a foundational architectural change for USD workflows inside Katana. According to Foundry’s official release, UsdSuperLayer is designed to allow artists and TDs to create and edit any USD prim directly within Katana, with USD treated as the authoritative scene description.

UsdSuperLayer at Node Graph level

The UsdSuperLayer node is designed to expose the incoming USD stage and allow users to create or edit prims directly on its authoring layer. According to Foundry’s documentation, this layer then feeds back into existing USD native Katana workflows.

The purpose is to form a basis for future specialised and custom tools built around a USD native context, with scalability and flexibility as design goals. UsdGaffer is described as a derived example of such a tool. UsdSuperLayer and its derivatives can be edited directly through Katana’s Python API. Foundry states that USD is treated as the “source of truth” for all properties serving as UI elements.

A key parameter is primPath. This indicates the path on which the node will create or edit prims. If primPath is changed, any created prims or edits are transferred to the new path. Foundry also states that primPath assists performance by masking stage composition to that path. Users are therefore advised to scope the scene to as minimal a section as possible to attain best performance.

By default, primSpecifier is set to Define, allowing prim creation on new paths. Override and Class specifiers are also available via a dropdown. This menu is customisable using Python Context Menu Plug ins. Documentation is provided under USD Processing Engine and UsdSuperLayer in the developer guide.

In the initial release, the context menu supports adding lights by category, adding light filters, adding Rig Xform, Scope and Material prims, renaming locally created prims, and deleting prims or overrides. Downstream UsdSuperLayer nodes cannot fully remove upstream created prims, only their own authored opinions.

Light creation is driven by discovery through the SdrRegistry for entries with light as context. Associated API schemas, such as MeshLightAPI and VolumeLightAPI, are auto applied using apiSchemaAutoApplyTo metadata. Foundry states this allows Katana to remain up to date with renderer specific choices while treating USD as the universal source of truth for registered prim data.

If a light shader defines a Category, a custom menu is generated grouping registered lights by category. By default, the light creation menu appears only on UsdSuperLayer and UsdGaffer nodes.

Light filters are created as child prims of selected light prims, with relationships set automatically when possible. If the parent is unsuitable, the filter is created at the same hierarchy level without automatic relationship creation. Deleting a filter removes references from immediate ancestors only. Relationships outside the filter hierarchy remain.

The parameter panel is populated based on the currently selected prim in the tree view. At present, it supports single selection and displays the first selected item if multiple prims are selected.

Parameter display is handled by Parameter Handler Plug ins. In Katana 9.0, three are shipped: Properties, Metadata and Shader handlers. The Properties handler displays API and Typed schemas on the prim, including locally and upstream authored values via the Stage Parameter Policy. Locally authored attributes not part of current schemas are also shown. The Metadata handler exposes prim level metadata editing. The Shader handler appears if a shader id property is detected and queries the SdrRegistry for matching shader definitions.

A showIncomingScene toggle exposes upstream created prims for downstream editing. Visual indicators in the tree view include grey U for unchanged prims, yellow E for edited prims, and green N for locally created prims. This provides a high level overview of authored changes at node level.

Filtering is supported through setFilteredConcreteSchemas and setFilteredApiSchemas methods, which restrict the tree view to prims matching defined schema filters. If filters are empty, all prims are shown.

A SyncSelection toggle mirrors behaviour found in GafferThree, with off, out and in or in out modes. By default, it is set to in out and can be changed in preferences.

Transformations can be applied to Xformable prims via Viewer manipulators. Transformations use a new SubEngine feature for the LayerEngine. This relies on attributes stored on the prim using the FnSubEngineAPI multi apply schema, included with FnUsdShim. C plus plus utilities and Python bindings via usg.FnSubEngineAPI are provided.

SubEngines allow procedural on demand interpretation of the incoming stage on each traversal. The Engine system is extensible, comparable to the Geolib Op system, and documented in the developer guide under Usd Processing Engine and Engines.

To transform incoming prims, MakeInteractive must be set to Yes. A right click option allows batch modification of this value. Locally created light prims default to MakeInteractive set to Yes.

Visibility can be toggled in the tree view, setting USD visibility on the prim. Four states are defined: incoming, local visible, local invisible and inherited invisible. The tree view toggle cycles between incoming, local invisible and local visible for efficiency.

UsdSuperLayer and its derivatives support copy and paste of prims within and across nodes. Name clashes are resolved through enumeration. When copying edited prims, only authored edits are copied.

A tab system has been added to the parameters of UsdSuperLayer and derived nodes, with each tab representing a ParameterHandlerPlugin whose label and ranking priority can be adjusted.

UsdGaffer specialises for lighting

UsdGaffer is described as the first specialised node derived from UsdSuperLayer, focused on lighting workflows. Its primPath defaults to /lights, causing new light prims to be created under a /lights Scope prim, for example /lights/distantlight1.

The tree view applies filters to show only prims using specific Typed and API schemas relevant to lighting. Typed schemas include UsdLuxBoundableLightBase, UsdLuxLightFilter, UsdGeomXform, UsdLuxNonboundableLightBase, UsdLuxPluginLight and Scope. API schemas include UsdLuxLightAPI, UsdLuxVolumeLightAPI and UsdMeshLightAPI. Context menu options are inherited from UsdSuperLayer but filtered for lighting tasks. In addition to light and filter creation, Add Rig Xform and Add Scope options are provided. Pressing R in the tree view creates a Rig.

UsdGaffer introduces a linking tab for creation and editing of light and shadow linking relationships. Incoming upstream linking properties are also displayed. Foundry notes that in USD defaults, includeRoot in light and shadow linking collections is active. Linking collections can be edited via relationship or membership expressions. If includeRoot is enabled or includes or excludes paths are specified, membershipExpression mode is ignored. Collections can be inspected in the Scene Explorer by activating the Collections view tab and selecting the light’s Collections working set.

UsdMaterial as lightweight tool

Katana 9.0 adds a UsdMaterial node with three modes: create, edit shader and edit interface. Create mode generates a single shader material under the prim path defined by materialPrimPath. Edit shader mode targets an existing Shader prim defined in shaderPrimPath, populating incomingShaderNode and shader properties from the SdrRegistry. Edit interface mode targets an existing Material prim whose contained shader properties have been promoted to its public interface.

Foundry explicitly states that UsdMaterial is not a substitute for a future look development toolset in the USD native space. It is described as a lightweight tool to create single shader materials and edit existing Material setups on an individual prim basis.

Hydra 2 rendering behind an env var

Katana 9.0 includes an initial implementation of Hydra 2.0 rendering. This workflow is gated behind an environment variable. Setting KATANA_ENABLE_HYDRA2 to 1 enables two new features: the Hydra 2.0 Viewer tab and the Hydra Scene Browser tab.

Foundry describes this as a first glimpse of what an end to end Hydra rendering solution could look like in Katana, from viewport to final frame image. The Hydra 2.0 Viewer tab renders only Hydra 2.0 data. It differs from the existing Viewer tab and can be used as a quality check to compare rendered images to the Hydra 1 viewport.

In this iteration, USD stages render in the Hydra 2.0 viewport but not through expansion based loading. Some Geolib attributes also render, but Foundry states that parity with Hydra 1.0 has not yet been achieved.

The implementation for rendering Geolib data derives from an internal library, FnHdBridge2.0, which will not be publicly available. Default lighting is not included in the Hydra 2.0 Viewer, although default materials are present and can be overridden by assigned materials.

To compare images between viewerports when rendering Geolib attributes, default lighting and basic material toggles must be disabled in the Hydra 1 Viewer. For USD data, a GafferThree must be placed in the scene to render basic materials.

A shim layer has been implemented to allow studios to write their own SceneIndexFilters. This requires building Katana’s FnUsdShim against a studio’s own USD version. Instructions are located under the FnUsdShim directory in the Katana installation. Foundry recommends that users with custom render delegates begin this process.

Hydra Scene Browser for debugging

An experimental Hydra Scene Browser tab accompanies the Hydra 2.0 Viewer. It displays the unflattened Hydra scene, similar in concept to scene graph navigation in usdview, but with the added ability to show Geolib data being fed into Hydra. Its stated intention is to help debug scenes prior to final frame rendering.

In this iteration, the Hydra Scene Browser does not show USD data being fed into Hydra. Foundry indicates that this will be updated in later iterations.

The tab contains three panes. The left pane lists Hydra prims within the selected terminal scene index in a tree view. The middle pane shows Hydra prim data sources associated with the selected prim, expandable to leaf level. The right pane displays source values for the selected data source.

Additional controls include Choose Scene Index, Inputs for selecting upstream scene indices, Show Notice Logger for recording dirtied, added, removed or renamed events, and Write to file, which exports the scene to a text file and reports its location in the Katana terminal.

VFX Reference Platform CY2025 and USD update

Katana 9.0 updates to VFX Reference Platform 2025. Listed versions include GCC 11.2.1, glibc 2.28, Visual Studio 2022 toolset, Windows SDK 10.0.22621, Python 3.11.11, Qt 6.5.3 modified, PySide 6.5.3, OpenEXR 3.3.2, OpenSubdiv 3.6.0, Alembic 1.8.8, OpenColorIO 2.4.2, Boost 1.85.0, Intel TBB 2021.13.0, OpenVDB 12.0.0 and NumPy 1.26.4. Outside the VFX Reference Platform, Katana 9.0 updates to USD 25.08.

Studios upgrading from earlier Katana versions will need to validate plug-ins, render delgeates and pipeline integrations against these updated dependencies. As always, new tools and innovations should be tested in your own pipeline before use in production.

// https://campaigns.foundry.com/products/katana/whats-new

The post Katana 9 deepens USD and previews Hydra 2 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Foundry has confirmed what many suspected was coming: perpetual maintenance is officially on its way out. From 1 January 2027, all active maintenance customers for Nuke Family, Mari and Katana will be converted to subscription plans at their next renewal. Renewals during 2026 will run as normal. After that, Foundry’s entire licensing structure will be subscription only, with no further perpetual updates. According to the company, this change “aligns Foundry with industry-standard licensing practices.”

Same price (for now), probably not for long

The company promises that 2027 renewals will start at the same price as current maintenance, with annual increases not exceeding five per cent. In other words, yes, prices technically stay the same, but you might want to assume that five percent rise is baked in. The subscription is available only on an annual or quarterly basis. For a full commercial licence, Foundry lists €3,139 per year, including taxes, or €1,719 per quarter, including taxes. Indie, student and non-commercial versions exist, but these are not viable for most studio use. Customers who decline to renew will retain their perpetual licences for the last supported version but lose access to updates, support and bug fixes.

A year to plan your escape route

Announcing the change a year early, Foundry’s Alex Foulds said the goal was to give customers “the time and information necessary for a smooth and predictable transition.” Smooth or not, 2026 now becomes the year to review budgets, check pipeline dependencies and decide whether subscription fits your studio strategy, or if you will freeze your perpetual licences at the last maintenance release.

Predictable transition, unpredictable reception

Foundry says a unified subscription model will “accelerate development and deliver more features and performance enhancements”. That statement has not been independently verified at press time. The real test will come when existing users renew in 2027 and see what value those new builds actually deliver.

Studios still running older versions of Nuke, Mari or Katana should check support timelines and network licence compatibility well before the end of 2026. Once maintenance lapses, Foundry’s technical support and update access will be gone.

Proceed with caution

Licensing transitions have a habit of exposing pipeline surprises. Test the subscription editions in controlled conditions before rollout and confirm version parity across render nodes, farm licences and DCC integrations. Because as of 2027, everyone, from the smallest comp shop to the biggest feature house, will be renting their Foundry tools. For good.

The post Foundry locks in full subscription future for 2027 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

With Mari 7.5, Foundry introduces a long-promised feature that fundamentally changes how artists work with texture maps: Multi-Paint. This update lets artists paint or project on up to eight texture streams at once: diffuse, specular, bump, displacement, roughness and more, all from a single node.

The update also integrates a Bakery-powered Texture Transfer system for rapid re-baking between objects and UV layouts. Both systems are built to speed up high-end workflows in film and visual effects, where hundreds of UDIMs and dozens of maps per asset are the norm. The following is a based solely on Foundry’s official release notes and documentation. So, take it with a grain of salt and test fpor yourself, we didn’t have the time to update Mari yet.

Multi-Paint: simultaneous control of eight texture streams

Until now, Mari’s paint engine supported one RGBA image stream per paint node. Artists could paint colour (diffuse) directly on a model, but each additional surface channel such as bump, specular, roughness or subsurface required a separate node, layer or bake.

Mari 7.5’s new Multi-Channel Paint Node eliminates this bottleneck. A single node can now carry up to eight streams (texture channels) simultaneously. Each stream corresponds to a channel in the chosen Shader Model such as Arnold Standard Surface, V-Ray Mtl, or Unreal.

When a Multi-Channel Paint Node is active, the Multi-Paint Palette appears in the Palettes toolbar. The palette lists all streams associated with the shader model such as Base Color, Roughness, Metallic, Normal or Height, and allows enabling up to eight at once.

The active or Primary Stream determines what the viewport shows during painting, identified by a white eye icon in the palette. While you see and interact with the primary channel (for example, diffuse), every enabled channel receives the same brush stroke data in parallel.

The Multi-Paint Palette: command centre for channel management

The palette acts as a live editor for channel configuration. Artists can:

Select active streams (up to eight).
Set individual Blend Modes per stream (multiply, overlay and more).
Assign foreground and background colours or load image inputs.
Define Primary Stream visibility and quickly swap preview targets.
Reset, batch-edit or clear streams.

Adding textures is drag-and-drop from the Image Manager or file browser. When an Image Group is dropped into the palette, Mari auto-assigns textures to shader channels by matching filename patterns such as “_rough” or “_disp”.

Mari 7.5 introduces Multi-Paint Presets, stored as reusable configuration files in the Shelf palette. These presets capture stream layouts, colour and blend settings, allowing consistent setups across multiple assets or shader models.

Painting tools rebuilt for Multi-Paint

A large portion of Mari’s paint engine was refactored to handle the multi-channel context. The following tools are now compatible: Paint, Paint-Through, Roller Brush, Blur, Clone Stamp, Warp, Slerp, Tow Brush, Pinup, Paint Buffer Eraser, Select Tool Fill, Marquee Select and Paint Buffer Transform.

Each of these tools operates through the Multi-Paint layer stack. Brush properties, projection masks and painting palette parameters are now multi-aware, ensuring that texture projection or cloning behaves consistently across all active streams. Mari supports both colour and image input per stream. For procedural workflows, users can feed channel-specific images or colour corrections before committing to a bake, maintaining Mari’s hallmark non-destructive approach.

Image Groups: intelligent texture organisation

The Image Manager was redesigned to handle large datasets typical of production texture packs. The old tab system is gone, replaced by hierarchical Image Groups. Image Groups can be created manually or automatically when folders are imported. Inside a group, images can be sorted, renamed or reassigned. When dropped into the Multi-Paint Palette, Mari matches textures to shader streams using internal Material Ingest Presets (*.mip files). These presets store naming conventions and expected channel mappings for common vendors such as Texturing XYZ or scanned materials.

If automatic assignment fails because of unconventional filenames, artists can open the Image Group Properties table to manually link each image to the appropriate shader stream. A Lock Streams feature prevents reassignment of locked mappings during auto-assign. This makes Multi-Paint particularly suitable for texturing workflows using large texture libraries or vendor-supplied scan sets with predictable naming conventions.

Shader Model Context and Node Integration

Each Multi-Channel Paint Node must be initialised with a Shader Model. Supported shader contexts include:

Arnold Standard Surface
Autodesk Standard Surface (1.0.2.x)
3Delight Principled
Principled BRDF
USD Preview Surface
Unreal
VRay Mtl (5 and 6)

The shader model defines which streams are available in the Multi-Paint Palette. The palette updates automatically when switching between nodes in different contexts. The node can be merged into existing node graphs via a Multi-Channel Merge Node, integrating seamlessly with existing layer stacks. Artists can switch between single-channel and multi-channel painting by simply selecting the desired node in the graph. Resolution and bit depth can be defined per node such as 4K 16-bit, or the node can inherit channel settings downstream using the Use Channel Settings toggle.

Preset Workflows and Shelf Integration

Preset workflows address one of Mari’s historical pain points: repetitive setup across large asset sets. Once a Multi-Paint Palette configuration is complete, it can be stored as a .mpp file (Multi-Paint Preset).

Presets can include colour values, blend modes and stream assignments, and can be batch-applied to new paint nodes from the palette’s dropdown. Hovering over a preset reveals thumbnail previews for verification before applying.

In large-scale productions, this allows technical directors to define standardised setups for shader models and distribute them via the Shelf palette to all texture artists.

Bakery-powered Texture Transfer

The second major technical upgrade in Mari 7.5 is the Texture Transfer system, powered by Foundry’s in-house map-baking engine The Bakery. Previously, transferring texture data between models relied on a particle-based method that could be slow and sometimes inconsistent. The new Bakery system replaces it with a GPU-accelerated baking approach that can reproject paint data across topologies and UV layouts far faster and more accurately. In practical terms, Texture Transfer enables the reuse of existing texture work when:

Retopologising a model
Updating UV layouts
Creating LODs (levels of detail)
Transferring look-dev setups between asset variants

Users can select one or more nodes in the Node Graph, right-click, and choose Selection > Transfer. The system opens a dialog allowing specification of source object, target object and patch (UDIM) mapping. Foundry’s documentation cites an internal benchmark: transferring three 28-UDIM 4K 16-bit Paint Nodes into a single 4K UDIM in roughly ten seconds, a significant speed-up compared to the previous generation.

The Bakery supports transfer of Nodes, Layers or Channels. Transfers preserve topology-based alignment where possible, and a Patch Fill Color option highlights untransferred areas, allowing manual correction afterwards. The legacy particle transfer system remains accessible through Mari’s Python API for backward compatibility, but Foundry now recommends the Bakery workflow for all new projects.

Workflow Example: Multi-Paint and Texture Transfer in practice

1. Setup: Create a Multi-Channel Paint Node, select a Shader Model such as Unreal, and define resolution and bit depth.
2. Import assets: Drag vendor texture packs such as Texturing XYZ into the Image Manager. Mari auto-creates an Image Group.
3. Assign channels: In the Image Group Properties, map each texture to the correct shader stream or use Auto-Assign with an ingest template.
4. Activate Multi-Paint: Open the Multi-Paint Palette, enable desired streams such as Base Color, Roughness, Normal, set the Primary Stream, and start painting using any supported brush tool.
5. Preview and bake: Use the Paint-Through tool to project images while previewing the Primary Stream. All enabled channels are painted concurrently.
6. Transfer: Once the asset evolves, for example a new UV layout, select relevant nodes, choose Transfer and re-bake textures to the updated geometry.

This workflow shortens iteration time between concept, look-dev and final asset while preserving fidelity across multiple texture channels.

Performance and scalability considerations

While Multi-Paint greatly improves efficiency, painting multiple 4K or 8K 16-bit streams simultaneously significantly increases GPU memory demand. Each stream is stored and processed independently, so large UDIM sets can quickly saturate VRAM.

Foundry’s release notes do not specify new memory optimisations beyond the core multi-threaded backup system, suggesting artists may need to monitor GPU load closely. Using lower-resolution previews or fewer active streams may be advisable on mid-range hardware. Texture Transfer performance depends on The Bakery’s compute configuration. Transfers are faster on multi-core CPUs with high disk throughput.

Compatibility and industry formats

Mari 7.5 continues to support standard exchange formats: FBX, OBJ, Alembic, OpenEXR and USD. The new systems integrate with UDIM workflows and scale comfortably beyond one million polygons in a single topology. Shader-model-based mapping ensures compatibility with renderers such as Arnold, V-Ray, Unreal and 3Delight without custom remapping.

Final notes and caution

Foundry’s documentation emphasises that Multi-Paint is a complementary workflow. Artists can combine it with traditional Paint Nodes without breaking compatibility. Existing projects can adopt it incrementally. However, the complexity of eight-stream painting introduces new edge cases in performance and layer management. Artists should benchmark Mari 7.5 on representative assets before integrating it fully into production pipelines. As with any major feature update, test before committing, particularly in environments with shared asset libraries.

Conclusion

Mari 7.5 marks a structural evolution of Foundry’s texturing toolset. With Multi-Paint, texture artists can finally paint multiple channels in perfect alignment, directly within a single node. The Bakery-based Texture Transfer complements this by making map reprojection effectively real time.

Together, they shift Mari’s focus from per-channel micro-management to holistic, multi-stream surface authoring, a change that may redefine standard practice in VFX texturing.

The post Mari 7.5: Multi-Paint, Texture Transfer and the Death of the Single Channel first appeared on DIGITAL PRODUCTION and was written by Bela Beier.