For those who don’t know the tool: RenderMan from Pixar is a production renderer used across VFX and animation. It integrates with basically all DCC apps and USD pipelines.

Pixar has released RenderMan 27.2, the latest update to its production rendering system. According to the official documentation and release notes, the update focuses on improvements to USD workflows, XPU rendering, and core stability. RenderMan is developed by Pixar and is used in feature animation and VFX production. The 27.2 release follows the established 27 series architecture.

USD and Hydra workflow updates

RenderMan 27.2 continues to refine its USD centric rendering path. USD serves as the backbone for scene descriptions in many production pipelines, and RenderMan’s Hydra delegate enables interactive and final-frame rendering of USD stages within host applications. The update includes adjustments to how USD stages are translated and synchronised. Changes affect the evaluation and propagation of attributes from USD primitives into RenderMan’s internal scene representation. This includes refinements to light, material and geometry handling when rendering directly from USD.

Behaviour between Hydra-driven rendering and traditional scene translation paths has been aligned in several areas. Parameter evaluation and state updates have been corrected to reduce discrepancies between USD and non-USD workflows. OpenPBR support is extended within USD contexts. OpenPBR is an open material model designed for renderer-agnostic material definition. RenderMan 27.2 improves the mapping and interpretation of OpenPBR parameters, ensuring more consistent shading results when using USD-defined materials.

Light handling in USD scenes has been refined, including updates to parameter interpretation and light linking behaviour. Attribute inheritance and override cases have also been corrected in specific scenarios.

XPU feature coverage expands

RenderMan XPU, Pixar’s hybrid CPU GPU rendering architecture, receives additional feature support in 27.2. XPU is designed to distribute rendering workloads across CPU and GPU devices in a single render session. In earlier 27.x builds, some shading nodes and features were restricted to RIS, the CPU based renderer. The 27.2 update brings further parity between RIS and XPU.

Additional shading nodes and material features are now supported in XPU. Parameter handling and default values have been aligned more closely with RIS, reducing behavioural differences between the two modes. Updates also affect integrator behaviour and light transport handling in XPU. Certain light types and rendering options now behave consistently across CPU and hybrid modes. Texture evaluation and displacement workflows have been corrected in XPU, addressing cases where results diverged from RIS. This includes fixes to shading artefacts and inconsistencies in displacement evaluation under specific configurations.

Shading system refinements

RenderMan 27.2 introduces updates across its shading and material system. Changes affect specific shader nodes, parameter ranges and default values. In several cases, adjustments were made to ensure consistent evaluation between RIS and XPU.

OpenPBR integration continues to evolve, with improved correspondence between OpenPBR inputs and RenderMan’s internal shading representation. This reduces mismatches when exchanging materials through USD based pipelines.

Layered material evaluation has been corrected in edge cases involving texture lookups and attribute overrides. Procedural shading nodes receive fixes addressing order of operations and attribute inheritance issues. Arbitrary Output Variables, or AOVs, are also affected. The update corrects output behaviour in certain configurations, ensuring that custom render passes produce the expected data for compositing workflows.

Geometry and motion updates

Geometry handling has been refined in 27.2. Subdivision surface evaluation has been corrected in specific cases, particularly when driven by USD scene data. Instancing behaviour and attribute propagation across instances have also been updated to ensure accurate rendering results.

Motion blur evaluation receives fixes addressing timing and interpolation of animated attributes. These corrections affect both geometry deformation and transformation blur under certain configurations. Displacement workflows have been adjusted, improving consistency in how displacement is evaluated across rendering modes. This reduces visible discrepancies between CPU and hybrid renders.

Volume rendering and lights

Volume rendering receives targeted corrections in sampling and shading behaviour. These address edge cases that previously resulted in artefacts or incorrect density evaluation in particular setups. Lighting workflows are refined in both USD and non USD contexts. Light parameter interpretation, linking and shadow behaviour have been corrected where inconsistencies were identified. These changes contribute to more predictable lighting results when switching between RIS and XPU or between traditional and USD based scene translation.

Incremental

RenderMan 27.2 is an incremental update focused on expanding USD and XPU coverage, aligning behaviour between rendering modes, and correcting shading, geometry and lighting edge cases. There are no architectural overhauls in this release. Instead, the emphasis is on feature parity, correctness and stability across established workflows.

Facilities relying on USD centric pipelines or actively deploying XPU will find broader feature support and fewer fallback scenarios. As always, new tools and innovations should be tested before use in production.

// RenderMan 27.2 documentation
// https://rmanwiki-27.pixar.com/space/REN27/726761480/RenderMan+27.2/

The post RenderMan 27.2 adds USD and XPU updates first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

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: 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.

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.