For those who don’t know the tool: Redshift from Maxon is a GPU renderer for Cinema 4D, Maya, 3ds Max, Houdini and Katana. It targets final-frame GPU rendering and USD Solaris pipelines, sitting at lookdev and lighting in production.

Consolidation, not features

Maxon has released Redshift 2026.3.0. The build includes plugins for Cinema 4D, Maya, 3ds Max, Houdini and Katana. It is a maintenance release focused on stability, host compatibility and incremental displacement updates. No new headline rendering features are introduced.

On Apple hardware, Redshift now requires macOS Sonoma 14 or higher. Maxon recommends macOS Tahoe 26.2 as the latest officially supported version, while noting known rendering artefacts on Intel CPU plus AMD GPU systems on Tahoe. On Windows and Linux, updated NVidia driver minimums apply, including specific requirements for Blackwell 50xx GPUs. Linux requires glibc 2.28 or higher.

Texture displacement cleaned up

Texture displacement receives performance improvements and several correctness fixes. The update resolves holes in meshes, vertical artefacts in the software ray tracer and cases where displacement disappeared on tessellated meshes without UVs.

Support for smooth normals has been added to texture displacement. The UV Context Projection node gains a new camera selection mode for camera projection mapping.

Additional fixes address deformation motion blur with displacement, incorrect auto-bump behaviour, and noisy details on scaled meshes. Material blending issues involving stacking and the Material Blender shader have also been corrected.

Hydra and Solaris updates

Redshift adds support for Houdini 21.0.559 and 21.0.596 and drops support for 20.5.654 and 21.0.440. The Hydra delegate now supports the Solaris 21.0 statistics panel in the latest Houdini 21.0 production build.

Hydra 2.0 fixes include motion blur limitations, primvars sampling issues, light linking problems, nested instancing errors and live updating of custom light and camera parameters. Support has been added for USD implicit surface primitives, USD mesh lights via the Geometry Light LOP, and updated USD and Alembic procedurals. AOV-related bugs affecting ObjectID, Depth, cryptomatte, deep and Refractions Light Groups have been fixed.

Redshift 2026.3 is a stabilisation release aimed at removing pipeline friction introduced in earlier 2026 builds. As always, new tools and innovations should be tested before use in production.

// Redshift 2026.3.0 Release Notes
// https://support.maxon.net/hc/en-us/articles/Redshift-2026-3-0-2026-02-February-10-2026

The post Redshift 2026.3 fixes displacement headaches first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Arnold is the production renderer from Autodesk, integrated via MtoA, MAXtoA, HtoA, C4DtoA and KtoA into Maya, 3ds Max, Houdini, Cinema 4D and Katana, and increasingly used in USD pipelines.

Arnold 7.4.5 is now available. According to the official Autodesk documentation, this release introduces new shaders focused on non photorealistic rendering, expands point based shading workflows, improves OpenVDB volume perfromance on CPU and GPU, and adds controls to Cryptomatte and lens effects. It also includes API changes, bug fixes and updates to OSL and USD support.

All feature descriptions below are taken from the official Arnold 7.4.5 documentation. Where Autodesk provides measured performance figures, these are cited as vendor benchmarks and are Not independently verified at press time.

Line shader for NPR work

Arnold 7.4.5 introduces a new Line shader. The shader is designed to render line based effects directly in Arnold. According to Autodesk, it can generate outlines, contour lines and stylised strokes across surfaces.

The shader works procedurally and can be driven by surface attributes and shading inputs. The documentation states that it can be combined with other shaders and textures to create sketch style and illustrative looks. Autodesk positions it for non photorealistic rendering workflows and motion graphics style treatments.

The Line shader integrates into Arnold’s standard shading network. It supports typical shader parameters for controlling line thickness, colour and other attributes. The exact parameter list and behaviour are detailed in the official shader documentation. Appearantly, this does not replaces existing toon or contour solutions. It is presented as an additional shading node within the Arnold core.

Nearest Points shader

Arnold 7.4.5 also adds a Nearest Points shader. This shader samples nearby points from geometry or point cloud data and exposes their properties to the shading network.

The shader can read point data from geometry and OpenVDB sources. It computes distances and relationships to nearby points and outputs shading data based on those calculations.

This enables effects such as network-like connections, proximity-based colour changes and graph-style visualisations.

The shader exposes controls for the number of points sampled and the search radius. It is designed to work within Arnold’s existing shading system and can be combined with other nodes. No claims are made to replace external point-processing tools. The feature is described strictly as a shading node within Arnold core.

OpenVDB volume performance

A major focus of Arnold 7.4.5 is performance improvements for volume rendering. On CPU, the volume node now supports OpenVDB grids with mipmaps. Mipmaps are pre-filtered versions of volume data at multiple resolutions. According to Autodesk, using mipmapped OpenVDB grids can significantly improve rendering speed when sampling large volumes.

Autodesk states that in internal test scenes, CPU volume rendering can be betwen approximately 1.5 times and 5 times faster when using mipmapped grids. These figures are vendor supplied benchmarks and are Not independently verified at press time. On GPU, Autodesk reports performance improvements of up to 3.5 times for certain volume rendering scenarios. The documentation attributes this to optimisations in volume sampling and shading. Always remeber that results depend on scene content and volume configuration.

Lens Effects updates

Arnold 7.4.5 updates the Lens Effects imaging node. A new Aperture Dispersion parameter has been added. This parameter controls colour dispersion in bloom effects, simulating chromatic dispersion across highlights.

The Lens Effects node operates as a post process imaging operator within Arnold’s render pipeline. The new control extends its ability to simulate optical artefacts.

Cryptomatte controls

Cryptomatte support has been updated in Arnold 7.4.5. The documentation states that new controls have been added for handling instances in Cryptomatte outputs. These controls affect how instanced geometry is encoded into Cryptomatte IDs. Cryptomatte is commonly used for ID based compositing masks in post production. The new options allow artists to refine how instanced objects are represented in the resulting mattes.

OSL and shading updates

Arnold 7.4.5 includes updates to OSL support. OSL, or Open Shading Language, is used for writing custom shaders. The documentation lists new and updated OSL functions and improvements to compatibility. These changes aim to ensure consistency between OSL and native Arnold shader behaviour. No deprecations are prominently highlighted in the summary documentation, but API level changes are documented for developers.

USD workflow improvements

Arnold’s USD support is also updated in this release. The official documentation references improvements to USD related workflows, including enhancements to how Arnold interacts with USD scenes and Hydra delegates. USD, or Universal Scene Description, is increasingly central to pipeline interchange. Autodesk documents refinements to integration rather than new headline features.

API and developer changes

Arnold 7.4.5 includes API updates for developers integrating Arnold into custom pipelines. The release notes document changes to certain API functions and behaviours. Developers are advised to review the API changes before upgrading production builds.

Platform support

Arnold 7.4.5 is available for Windows, Linux and macOS, as stated in the official documentation. GPU rendering remains supported on compatible NVIDIA hardware under supported operating systems. The documentation does not expand hardware requirements beyond those listed in the system requirements section. Integration plugins for supported DCC applications are updated separately. Autodesk provides corresponding builds for host applications including Maya, 3ds Max, Houdini, Cinema 4D and Katana via their respective Arnold bridges.

Practical implications

For production teams, the most concrete additions are the Line shader, the Nearest Points shader and the documented OpenVDB volume speedups. NPR and motion graphics teams gain native shading tools inside Arnold rather than relying entirely on external compositing or geometry preprocessing. Pipeline engineers should review API notes and test custom plugins before deployment. As always, new tools and innovations should be tested before use in production. Arnold 7.4.5 is available now via Autodesk’s official distribution channels.

// Arnold 7.4.5 Release Notes
// https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_core_7450_html

The post Arnold adds lines, points and faster volumes 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.

For those who don’t know the tool: MoonRay is DreamWorks Animation’s in-house Monte Carlo path tracer, open-sourced in 2023 under Apache 2.0. It drives DreamWorks’ film rendering pipeline and supports hybrid CPU/GPU (XPU) modes. MoonRay integrates with DCCs via its Hydra delegate (hdMoonRay) for tools such as Houdini and Katana. The project includes the Arras framework for distributed rendering and collaboration across clusters.

Light Path Visualiser Enters the Scene

The new light path visualiser in moonray_gui is the most visible change in version 2.34.0.1. It lets artists trace how rays travel through a scene, showing how light interacts with surfaces, volumes, and materials. The visualisation is colour-coded by ray type and can reveal sampling or shading inconsistencies that are otherwise invisible. It also serves as a diagnostic tool for debugging light source or material behaviour.

Platform Updates: macOS Tahoe Joins, Linux Builds Simplified

MoonRay can now build natively on macOS Tahoe, with Sonoma and Sequoia still supported. The renderer also benefits from dependency updates and inculde fixes, easing compilation on a broader range of Linux distributions. The release aligns with both VFX Reference Platform 2024 and 2025, ensuring compatibility with current production libraries and compilers.

New Features Across the Pipeline

Version 2.34.0.1 expands flexibility for lighting and shading setups. Per-lobe lightsets are now available in both vector and XPU modes, allowing finer control of multi-lobe BSDFs. Image maps gain bindable “scale” and “offset” attributes, and SceneVariables documentation for image sizing has been clarified. Performance-wise, MoonRay now shares CPU and memory affinity data between processes using shared memory, improving parallel job efficiency. Timing measurements have switched to a more efficient RDTSC-based method for NUMA [non-uniform memory access] systems, offering more stable profiling results. Artists can also now select lights and cameras for object-space transformations directly in map shaders, simplifying custom shading graph workflows.

Fixes: From Subsurface Scatter to Fisheye Crashes

A long list of bug fixes makes this release notably production-friendly. Key repairs include:

• Fixed a mesh tessellation issue in tiled renders with the FisheyeCamera.
• Resolved DwaTwoSidedMaterial artefacts caused by previous lobe lightset work.
• Corrected crashes when exceeding BSDF lobe limits or loading oversized MeshLights, which now trigger warnings instead.
• Addressed a memory usage spike in vector and XPU modes.
• Fixed missing lightset assignments in vector subsurface scattering and adjusted over-bright subsurface shading on creases.
• Corrected normal direction errors in scalar mode and improved TransformSpaceMap behaviour.
• Fixed adaptive light sampling, volume bounce contributions, and a crash in OpenImageIO 2.4.8 statistics when no images were opened.

Under the Hood: Clean-Up and Refactoring

DreamWorks also restructured several internal libraries. The noise library moved from moonshine/lib/common to moonray/lib/common, simplifying dependencies. The integrator logic for Cryptomatte was reduced in complexity, and redundant intersection path types were removed. Code clean-up continues across lib/rendering/shading, improving maintainability without changing behaviour.

Availability

MoonRay 2.34.0.1 is available now as open-source via the official repository. It can be compiled for Linux and macOS (Tahoe, Sonoma, and Sequoia). GPU rendering requires NVIDIA CUDA/OptiX or Apple Silicon.

Caution Before Production

As with any open-source renderer update, production users should validate the build and test scene compatibility before deployment in live pipelines.

The post Rays Behaving Badly No More: MoonRay 2.34.0.1 Fixes the Path first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Pixar has released RenderMan 27.1, a maintenance update that stabilises and refines the hybrid XPU renderer introduced in version 27. The release extends MaterialX Lama functionality, aligns checkpointing with RIS behaviour, and improves stability across DCC integrations.

XPU: coating and checkpointing refined

The hybrid RenderMan XPU renderer now supports coating behaviour in the MaterialX Lama shading system. In practice, base nodes such as LamaDielectric and LamaGeneralizedSchlick correctly adjust absorption when layered with LamaLayer. This brings XPU into parity with the older RIS renderer for complex layered materials.

The update also fixes multiple shading issues. Subsurface scattering in PxrSurface and PxrDisneyBsdf now supports bump mapping when diffuse front-matter parameters are zero. Several Lama-specific bugs have been resolved, including incorrect subset computation inside combiner networks and misweighted LamaSSS importance that led to dim results. Shader memory use has been reduced by roughly 380 MB on GPU, improving efficiency on multi-layered materials.

RenderMan 27.1 also changes how XPU executes checkpoint commands. They are now triggered after a successful render rather than solely after each checkpoint, matching RIS behaviour and improving automation consistency in scripted pipelines.

Lighting and statistics

The release addresses a lighting artefact in the cylinder light’s radiance estimate function and corrects iteration-based pixel reporting in XPU statistics. The live statistics overview for both RIS and XPU now displays active pixel counts alongside iteration numbers. Data in DCC live stats panels now persists correctly after a render stops.

Blender and Houdini integration

In RenderMan for Blender, a bug that prevented AOVs from rendering correctly across multiple sessions has been fixed. RenderMan for Houdini receives several updates: the args2hda tool now generates valid disable and hide conditions, HdPrman automatically sets frame numbers in USD 25.05 and Solaris for older USD versions, and USD plugins have been moved to the dso directory for consistency.

Platform support and licensing

RenderMan 27.1 supports Windows 10+, macOS 15.x+, and glibc 2.34+ Linux. XPU is available on Windows and Linux with NVIDIA Pascal or newer GPUs. Integration plugins are provided for Blender 3.6+, Houdini 20+, Katana 7+, and Maya 2024+. Licences start at USD 845 (perpetual or floating, including 12 months of maintenance), with a non-commercial edition available for free.

Get more iNformation in the Renderman Wiki here.

The post Checkpoint, fixed: Pixar ships RenderMan 27.1 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Pixar’s RenderMan 27.0 is not a mere update: For the first time since the RIS introduction in 2014, RenderMan’s rendering core has been fundamentally rebuilt. The headline act: XPU, Pixar’s hybrid CPU+GPU architecture, now capable of producing final-frame renders. With multi-GPU support, full compositing pipelines, and feature parity with RIS in most production cases, XPU has stepped from experimental preview to the new backbone of RenderMan’s future.

According to Pixar, version 27 marks the most significant performance and interactivity leap in over a decade. The new architecture combines compute scalability with physically based consistency, while also supporting new aesthetic flexibility through a fully integrated Stylized Looks framework.

XPU: From Preview to Production

RenderMan’s XPU engine now operates as a complete production renderer, supporting both CPU and GPU resources simultaneously. This dual utilisation allows artists to push hardware to its maximum throughput, whether on workstations or render farms. The new final-frame rendering mode eliminates the former division between lookdev and production rendering, streamlining pipelines previously dependent on RIS for the last mile. XPU now supports multi-GPU rendering, with the caveat that all GPUs in use must be identical and contain full scene memory. The engine’s minimum requirement has been raised to CUDA 12.8.1, reflecting its deeper reliance on modern GPU driver capabilities. Pixar confirms that this configuration is the foundation for all future RenderMan development.

Adaptive, Smarter, Faster

Under the hood, Pixar’s engineers have reworked adaptive sampling, aligning it with internal techniques used in Pixar Animation Studios’ own productions. Adaptive metrics such as “relativepixelvariance” and “mse” AOV-based control now run per object, delivering more accurate sampling without inflating render times. Checkpointing, a feature long requested by production supervisors, has been fully implemented. Artists can now save partial renders at defined intervals, resuming from checkpoints without rerendering full frames. This system, combined with interactive denoising, significantly tightens iteration loops in look development. The denoiser itself now outputs timing data, integrates directly with live renders, and can be toggled interactively. Pipeline engineers can expect improved configurability for modern, distributed render farms.

Deep Compositing and AOV Control

Version 27 brings complete deep data workflows to XPU. OpenEXR 3.0 Deep IDs are fully supported, allowing compressed ID manifests to be automatically generated for compositing. Artists can extract object-level data directly from deep renders using Pixar’s new deepidextract utility. Compositing teams gain matte and holdout workflows, expanded AOV handling, and support for the shadows and invshadows LPE prefixes. OpenEXR metadata is now written natively, ensuring compatibility with Nuke and other deep compositing tools. Cryptomatte, while not yet part of the initial 27.0 release, is scheduled to arrive in a dot update, according to Pixar’s release notes.

Geometry, Lighting, and Volume Precision

Geometry handling in XPU 27 has been heavily rewritten to achieve parity with RIS. Nested instancing, long a sticking point, now supports material inheritance and attribute propagation without breaking shading hierarchies. Displacement, motion blur, and volume interactions have been stabilised, with notable improvements in the handling of semi-sharp subdivision creases.

Lighting gains precision as well. Mesh lights are now fully supported, and light filters have been corrected for spline and falloff anomalies. The PxrPathTracer integrator adds new clamping controls (clampDepth and clampLuminance), aligning noise handling across both rendering architectures. Volumetric fidelity benefits from the new interior volume aggregates, enabling complex materials such as murky liquids or translucent crystals. Artists can now fine-tune deep shadow error parameters for exact compositing control.

MaterialX Lama: Early Access, Serious Potential

RenderMan 27 introduces MaterialX Lama, Industrial Light & Magic’s modular shading system, as Early Access inside XPU. The system allows layered material construction using physically accurate combiners. Pixar’s current implementation supports LamaDielectric, LamaConductor, and GeneralizedSchlick nodes with anisotropy, single scattering, and extinction behaviour now properly matching or exceeding RIS accuracy. Full support is scheduled during the 27.x release cycle. Pixar notes that look differences compared to RIS are expected in this early phase and requests feedback from studios integrating Lama in production.

Stylised Looks: Non-Photorealism, Physically Based

The Stylized Looks suite has matured from experiment to production toolset. It now ships as a unified subsystem under XPU, comprising PxrStylizedControl, PainterlyBrush, Lines, Hatching, Canvas, and Toon filters. Each operates as a display or sample filter, allowing NPR (non-photorealistic rendering) effects such as painterly brush strokes, toon shading, curvature-based outlines, and cross-hatching, all integrated directly with RenderMan’s physically based lighting.

The system supports AOV outputs, interactive denoising, and compositing passes. The new PainterlyBrushXPU filter enables procedural brush strokes with depth and lighting awareness. StylizedCanvasXPU and StylizedLinesXPU introduce compositing and in-filter distortion options with up to 96 preset line textures. Pixar’s stated goal: to let stylised rendering coexist with physically plausible shading without breaking pipeline compatibility.

Integration and Pipeline Alignment

RenderMan 27 strengthens its integration with major DCC applications and pipeline frameworks. Solaris, SideFX’s USD-based environment in Houdini, now features deeper RenderMan embedding, including improved UI, native support for OpenSubdiv 3.6.1, and GPU progress tracking in hdPrman. RenderMan LOP nodes have been refactored, and “RenderMan Render Vars” replace the older “Standard Render Vars” for more robust USD conformity.

RenderMan for Blender reintroduces Qt-based UIs via PySide6, restoring the texture manager and preset browser on Blender 4.x. Artists now benefit from native light linking, velocity blur control, and on-the-fly texture conversion.

In Maya, RenderMan’s Texture Manager has been modernised, adopting OpenImageIO for mipmapped texture conversion. Pixar’s proprietary texture format has been replaced by OpenEXR, aligning with the VFX Reference Platform 2024 standards. The legacy txmake utility remains available for backward compatibility but is now officially deprecated.

The Texture Manager now supports ACES-compliant defaults, HiDPI UIs, and multi-selection editing. Pixar warns that lowercase tokens will no longer be recognised; pipelines must adopt the uppercase convention for USD compliance.

Complying with the VFX Reference Platform 2024

RenderMan 27 aligns fully with VFX Reference Platform 2024, standardising on current builds of Python, OpenEXR, OpenImageIO, and USD. For production pipelines, this ensures compatibility with other industry-standard applications and reduces dependency conflicts across render nodes. The change affects texture formats, shader APIs, and compositing metadata. Pixar’s move to OpenEXR for both image outputs and texture caching is particularly significant, replacing proprietary workflows with interoperable standards.

Performance and Statistics

Performance instrumentation across XPU has been expanded, with scene ingestion, GPU allocation, and adaptive ray counters now visible in live statistics panels across DCCs. The stportal interface presents real-time timers, counters, and memory metrics, enabling TDs to diagnose bottlenecks without external profiling tools. RenderMan’s JSON reporting system has been refined for both RIS and XPU, offering standard and detailed modes for automated render diagnostics. Memory tracking now includes deduplication efficiency, critical for large USD scenes.

Future of RIS

While RIS remains functional in version 27, Pixar has confirmed its future deprecation. The renderer continues to support legacy pipelines, but new features including deep compositing, MaterialX Lama, and multi-GPU acceleration, are exclusive to XPU. Pixar recommends transitioning new projects to XPU immediately to ensure feature parity and forward compatibility. The company has maintained RIS only for existing productions requiring deterministic CPU-only rendering or legacy shader behaviour.

Non-Commercial Version – still free.

The free Non-Commercial RenderMan 27 is Pixar’s way of saying, “Go ahead, break it, just don’t charge for it.” The edition now includes full XPU support, right down to final-frame rendering, meaning anyone can experiment with the same hybrid CPU–GPU tech used on Pixar features. It’s designed for personal projects, research, and plugin tinkering, with no watermarks, only a polite request to credit RenderMan if your test project accidentally becomes an internet hit.

Naturally, there’s a catch or two. The licence is strictly non-commercial, locked to two machines, and politely expires every 120 days, because nothing keeps a pipeline sharp like forced renewals. The Stylized Looks suite, Pixar’s NPR playground of painterly brushes and toon shaders, is absent here, reminding users that true artistry still costs a studio licence. Still, for anyone wanting to explore the XPU ecosystem without opening the budget spreadsheet, it’s a generous, production-grade sandbox.

Compatibility, Stability, and What Comes Next

RenderMan 27’s release is a clear signal: Pixar’s renderer is now fully committed to hybrid GPU computing and open pipeline standards. With XPU stabilised for final-frame rendering, Solaris deeply embedded, and MaterialX Lama laying the foundation for unified shading, the software’s architecture is more extensible than at any point in its history. The move to industry formats and the inclusion of non-photorealistic rendering tools reflect Pixar’s recognition that creative flexibility and pipeline efficiency must coexist.

RenderMan 27.0 should be thoroughly tested before deployment in production, especially when adopting early access features such as MaterialX Lama. Pixar’s documentation explicitly requests user feedback to refine those systems during the 27.x cycle.

The post Pixar’s RenderMan 27.0 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

XPU grows up

Pixar has pushed its hybrid CPU/GPU renderer, XPU, into full production status with the beta of RenderMan 27. XPU, introduced as experimental in earlier releases, now supports final-frame rendering. The engine adds interactive denoising for live look feedback, deep compositing outputs, and holdouts/mattes for layered workflows. Checkpointing allows partially saved renders, useful for iterative approval cycles. XPU also gains multi-GPU support, extending performance across several cards, and now runs OSL (Open Shading Language) filters. Limitations remain: no Cryptomatte support, no texture or light baking, no NURBS/quadrics rendering, and reduced performance with thousands of lights. macOS users must wait for a later dot release to run XPU at all.

RIS heads to retirement

RIS, RenderMan’s long-standing CPU-only engine, is still included but officially marked for deprecation. Pixar has not provided a removal version, but signals its intent to transition all users to XPU in the near future.

MaterialX integration

MaterialX, the open standard developed by ILM and adopted by the Academy Software Foundation, arrives in RenderMan 27. XPU can evaluate MaterialX shading graphs, allowing interchange between applications that support the format. This addresses a key demand for studio pipelines that rely on cross-software asset exchange.

Stylized Looks expand

Pipeline features

RenderMan 27 continues Pixar’s effort to fit modern VFX pipelines. The update improves checkpointing and adds output flexibility for deep compositing passes. Support for mattes and holdouts makes it easier to combine live-action and CG layers, or to generate masks for postproduction.

Smaller additions

The release also improves interactive workflows with enhancements to the IPR (Interactive Preview Render). Users can now update shaders and geometry with fewer restarts, reducing iteration time. XPU’s viewport responsiveness has been tuned for lookdev, even on large assets. Another area of focus is light transport and filtering. XPU gains extended support for OSL filters, giving TDs more granular control over pixel output during rendering. This makes it possible to implement customised passes or in-house filtering logic without rewriting the core renderer.

Plugin updates

The release ships with updated plugins for Houdini, Katana, Maya, and Blender. Integration is designed to expose XPU features directly within host DCC applications, keeping lookdev and shot work inside familiar UIs.

Historical context

RenderMan has been Pixar’s in-house renderer since the late 1980s, originally built on the Reyes architecture optimised for micropolygon rendering. RIS, introduced in 2014, replaced Reyes with a path tracer better suited to global illumination. With version 27, Pixar signals the next phase: shifting from CPU-centric RIS to the hybrid CPU/GPU XPU engine, reflecting the industry-wide migration towards GPU acceleration. RenderMan 27 is available as a beta for registered users.

The post RenderMan 27: XPU graduates, RIS retires first appeared on DIGITAL PRODUCTION and was written by Jürgen Firsching.

In nuce: The Foundry, the developer of software for the creative industries, has released Katana 6.0. Katana is a software for look development and lighting. Paul Denhard, Senior Product Manager at The Foundry, is pleased to announce that Katana 6.0 has further streamlined workflows – even in the case of “large volumes of work and tight timeframes.” According to the press release, Katana 6.0 is aligned with the VFX Reference Platform 2022 and USD 22.05.

In toto: New features include the Performance and Material Solo tabs, which are designed to speed up manual tasks and workflows for artists. These and other new features follow below.

Katana 6.0 | Feature Overview

Debug and Optimise Projects With The Performance Tab | Katana 6.0 Tutorial

Katana 6.0 | Optimise Your Scenes and Projects with The Performance Tab

• Performance tab: Thanks to this, artists should have an easier overview of the size of their 3D scenes and be able to correct errors more effectively. A colour-coded heatmap should allow artists to identify the proverbial bottleneck in the node graph more quickly.

Solo Materials to Preview Parts of Your LookDev | Katana 6.0 Tutorial

Katana 6.0 | Preview Your Work With Material Soloing

• Material Solo tab (Material Solo tab): This provides a preview of the look development, allowing artists to better understand how set nodes will affect the final result. An immediate insight into the components of the material setup is provided. In other words, material networks – even complex ones – can be quickly isolated and debugged. Each individual section can be viewed as a preview.

Share and Reuse Work with LiveShadingGroups | Katana 6.0 Tutorial

• So-called LiveShadingGroups are intended to further enhance look development. LiveShadingGroups give artists the opportunity to share projects and assets with each other. This works in that LiveShadingGroups, once set across scenes, automatically update scenes linked to them – as soon as participating artists make changes.

Katana 6.0 | Quality of Life Improvements for LookDev Artists

• The NetworkMaterialEdit material interface allows artists to customise the material interface within the NetworkMaterialEdit node – thus “breaking away from linear workflows”, as the press release states.

Click further: Full details of the new functions can be found at campaigns.foundry.com/products/katana/whats-new . Digital Production reported on the release of the previous version, Katana 5.0 , on 27 December 2021 – at the time, we highlighted compatibility with Nuke, various rendering upgrades and the Universal Scene Description as the most impressive features.

The post The Foundry releases Katana 6.0! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

Redshift 3.0

What are your weekend plans – lockdown or a relaxed run? Are you looking for an excuse to chain yourself to the workstation? Maxon gives you the excuse – and the handcuffs, in the form of the first public demo of Redshift 3.0, the GPU renderer for 3ds Max, Cinema 4D, Houdini, Katana and Maya.

What’s under the bonnet of Redshift 3.0? For example, hardware-accelerated ray tracing for new Nvidia GPUs, as well as the Altus denoiser and the Cinema 4D noise shader. It’s purring under the rendering bonnet, isn’t it? Also supported: tyFlow and FumeFX in 3ds Max and Ornatrix in Maya. Support for Redshift as a viewport renderer – within Houdini’s Solaris dev toolset – is also offered.

More info & availability

What’s left to do? Either download the free demo version of Redshift or check out the new features on the Trello board. Or watch the Redshift Demo Reel 2019 first?

The post Redshift 3.0 | Public Demo first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

Chaos Group and The Foundry have worked well together and present V-Ray for Modo, Nuke and Katana. Information on this will be available at Siggraph tomorrow: At the Foundry booth 601 (right next to the Chaos Group), the heads of both companies will officially announce the whole thing once again (on Wednesday, 13 August, at 10 a.m. local time) and the new functions will be explained as part of the Modo/Mari User Group, which will also meet on Wednesday in the Georgia Ballroom at the Hyatt Regency Hotel (7 to 8 p.m.).

V-Ray for Modo and Nuke are in public beta, V-Ray for Katana is already available – for more information, please contact the Chaos Group at vfx@chaosgroup.com.

V-Ray for Nuke

V-Ray for Modo

The post V-Ray for Modo, Nuke and Katana first appeared on DIGITAL PRODUCTION and was written by Bela Beier.