For those who don’t know the tool: Redshift is a production renderer that plugs into DCCs like Cinema 4D, Autodesk Maya, SideFX Houdini, Autodesk 3ds Max, Foundry Katana, and Blender, so lighting TDs can argue about samples in the app they already love.

The night shift arrives everywhere

So, after sorting through the heap, it is time to talk about Redshift, specifically. Redshift 2026.5.0 adds a night sky representation to the Sun and Sky system across hosts, including stars, moon, and Milky Way, with time and location controls.

That matters less for hero closeups and more for the boring shots that still need to ship: wide establishing frames, background domes, and lighting continuity on sequences that bounce between day and night. And also, to keep the internet sleuths ansd “Actually-s…” at bay.

The same update also includes a fix for the Physical Sun and Sky light where the milky way could render in flipped coordinates. It is the kind of bug that makes you doubt your compass and your life choices at the same time.

OpenPBR takes the default seat in Cinema 4D

For Cinema 4D, OpenPBR becomes the default material, and the default material list in preferences gets updated. The shader model itself comes from OpenPBR, the OpenPBR Surface specification hosted under the Academy Software Foundation umbrella.

In practical terms, the change means new scenes in that host start from OpenPBR unless a user switches the preference. It also comes with a cleaned up material menu that puts OpenPBR up front and pushes older options out of the spotlight.

If your pipeline has older material libraries, this is the moment to check how presets migrate, how template scenes behave, and whether old lookdev assumptions still hold. New tools and innovations should always be tested before use in production.

Texture Displacement gets smarter and less picky

Texture Displacement continues to expand, building on the system introduced earlier as an alternative to vertex displacement. In 2026.5.0, texture-based displacement gains preliminary UDIM and UVTILE support. It also gets mirror repeat mode when smart baking is enabled, plus improved quality when displacement is driven by UV projections.

There is also enhanced auto bump mapping support meant to improve bump mapping quality when used with displacement nodes. This addresses a common pain point where displacement and bump interplay can get noisy or fight each other in shading.

A set of fixes targets stability and interactivity too. The release notes list multiple cases where texture displacement could disappear or show artefacts in interactive preview rendering when using bucket mode, and those issues have received fixes.

One more fix calls out self-shadowing artefacts on objects with extremely high polygon angles when using Texture Displacement. If you have ever seen displacement turn into a crunchy self-shadowed mess on near-planar geometry, that line will feel oddly personal.

Some Cinema 4D specific fixes also land here, including a bug where UDIMs were not correctly rendered when using Team Render, plus a bug that could cause random black images when rendering heavy meshes with deformation blur enabled. Redshift 2026.5.0 also sets a minimum plugin requirement of Cinema 4D 2026.2.

In the middle of all that, one of the most important workflow wins is banal: fewer special cases. The more often displacement works the same way across UV layouts, projections, and preview modes, the less time artists spend building around the renderer instead of using it. Also, please rmember that displacement tends to be the first place where a scene crosses from fine to on fire, so keep an eye on memory and subdiv settings when you roll this out.

AMD ray tracing via HIP RT, marked experimental

Redshift 2026.5.0 adds experimental support for HIP Hardware Ray Tracing, also known as HIP RT. HIP RT itself is an AMD HIP RT ray tracing library designed for applications using HIP.

The release notes call the feature experimental. That is a polite way of saying you should not bet a deadline on it without testing it on your actual scenes, drivers, and farm images.

The same build also mentions improved render startup performance in scenes with high primitive counts when using Hardware Ray Tracing. Together, those notes make a clear point: hardware ray tracing paths continue to expand, and more of the heavy lifting is expected to land in that codepath over time.

Windows on Arm joins the CPU party

Redshift 2026.5.0 adds native Windows Arm64 support for Redshift CPU in Cinema 4D, ZBrush, and via the command line renderer. That is specifically CPU rendering, not GPU rendering. For the broader platform context, Windows on Arm covers Arm64 devices running Windows, including systems where native Arm apps run without emulation while other binaries may run under emulation.

If you are eyeing Arm based Windows laptops for travel kits or lightweight previs work, this change removes at least one hard block for CPU rendering workflows in those supported routes. It does not magically turn an ultraportable into a render node, but it does make it a more honest option for tests, turntables, and emergency output.

Bottom line for production

None of that removes the usual responsibility from leads and TDs. Update one step at a time, validate looks against show frames, and test your farm and plugin versions before you flip defaults for everyone. That advice feels boring, right up until it saves your weekend.

https://www.maxon.net/en/redshift

The post Maxon ships Redshift 2026.5 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the thing: OpenPGL plugs into path tracing renderers to guide sampling. It already shows up in Blender via Cycles, and now lives under Academy Software Foundation governance for broader adoption.

A new home for guided rays

OpenPGL just became a hosted project under the Academy Software Foundation. It enters at the sandbox stage, which is the earliest entry point for young projects and comes with a stated goal of graduating to incubation within one year.

The project targets a specific kind of pain that every lighting TD knows by feel: path traced frames that need more samples because the sampler keeps spending effort in the wrong places. OpenPGL focuses on path guiding, an importance sampling strategy that uses additional information about a scene’s light distribution to make better sampling decisions. The result is higher rendering efficiency because the renderer spends more samples where they matter.

Path guiding has a deep academic history, but production teams rarely get value from a PDF alone. Integrating path guiding research into a production renderer can be tedious, and the implementation details often become a long-term maintenance tax. OpenPGL positions itself as a production-ready open source library aimed at lowering that cost by offering well-tested, robust implementations of state-of-the-art path guiding methods.

What OpenPGL actually does in a renderer

OpenPGL learns a representation of a guiding field during rendering and updates it on a per-frame basis using radiance and importance samples generated during rendering. During path generation, the renderer can query the guiding field at vertices along a path to get a local distribution that can guide sampling decisions, including which directions to pick next.

The practical promise is simple: better sampling quality, less noise, and more efficient renders for the same sample budget. The project also carries an explicit caution flag: its current versions are still pre v1.0, the API is still in flux, and it should be used with caution in production related environments. That is a polite way of saying the interface may change under you, so build your integration like you expect to revisit it. A lot. any times. Remember what you did for USD.

There is also a performance angle baked into the design. The implementation is optimized for recent Intel processors with SIMD instruction support listed as SSE, AVX, AVX2, and AVX-512. OpenPGL also states support for Linux, Windows, and macOS.

If you are the sort of person who reads build flags for fun, OpenPGL includes a CMake superbuild option that pulls dependencies and builds a full install directory. It can also build extra tools named openpgl_bench and openpgl_debug when enabled.

Who is already using it

OpenPGL is not arriving as an untested science project or white paper. It is already integrated into several big-name production renderers, including Blender’s Cycles, Chaos V-Ray, SideFX Karma, and Disney Animation Hyperion.

Disney Animation describes OpenPGL as an important building block in the second generation path guiding system of its Hyperion renderer, calling out a simple API and faster iteration on production challenges. The statement also says the studio used a new path guiding system using OpenPGL in the production of Zootopia 2, including shots with difficult lighting setups and complex volumetrics.

Illumination Studio Paris is using OpenPGL to bring advanced path guiding techniques into its production renderer in a robust and practical way, citing more efficient handling of complex lighting, reduced need for labor-intensive hacks, and more freedom for natural lighting setups. The statement also says OpenPGL proved especially valuable on its latest production, The Super Mario Galaxy Movie, for tackling challenging lighting scenarios.

Chaos describes performance gains in production scenes with complex lighting and calls the integration into V-Ray relatively straightforward. But V-Ray always has all the tools in it.

Governance, now with more grown-up shoes

As a sandbox project, OpenPGL is set up for open community participation under the foundation’s hosted-project framework. Separately, the Technical Advisory Council meeting notes for the project proposal capture additional context around the move, including that the proposal presentation was delivered by Sebastian Herholz, listed there as ex-Intel and soon Blender, and that the sponsor is Kimball Thurston at Weta.

The same meeting notes also include examples discussed in the proposal materials, such as comparisons showing less noisy results with path guiding enabled at the same samples per pixel, and an example that describes a V-Ray timing comparison of 50 minutes with path guiding off versus 34 minutes with path guiding on. Those examples are presented as part of the proposal materials, not as independently reproduced benchmarks here, so treat them as directional evidence rather than a guarantee.

Licensing, access, and the practical reality check

OpenPGL is released under the permissive Apache Software Foundation Apache 2.0 license. The code is available on GitHub, and the repository labels the current release as v0.7.1. The project is distributed as open source software under its stated license.

If you are considering bringing it into a pipeline, the most important detail is not the headline. It is the warning label: pre v1.0 and API changes are on the table. Plan for integration work, version pinning, and regression testing across scenes that stress your sampler. So, don’t put it into a production pipeline, and if you are writing your own render engine, please, be careful.

https://www.awn.com/news/academy-software-foundation-adds-openpgl-new-hosted-project

https://github.com/openpathguidinglibrary/openpgl

https://www.intel.com/content/www/us/en/developer/articles/technical/open-path-guided-rendering-made-easier.html



https://www.intel.com/content/www/us/en/developer/videos/path-guiding-with-blender-and-intel-open-pgl.html

The post OpenPGL joins ASWF first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Milo is the real-time rendering companion to Silo from Nevercenter, designed for fast lighting and lookdev directly from models edited in Silo. It runs as a linked app, updates automatically on save, and ships with the same perpetual licence.

Unreal Engine upgrade does the heavy lifting

Nevercenter has released Milo version 2026.0.0, a substantial technical update centred on a full migration to Unreal Engine 5.7. According to Nevercenter, the engine upgrade delivers significant improvements in both rendering quality and performance, following systematic optimisation across the renderer.

In a video walkthrough accompanying the release, Nevercenter founder Tom Hudson demonstrates real-time raytracing running on an Nvidia RTX 3060, (a five-year-old GPU), with lighting rigs adjusted interactively at high frame rates. Hudson states that comparable scenes in previous Milo versions ran significantly slower on the same hardware, particularly when raytracing was enabled.

Raytracing and pathtracing split by platform

Rendering features now diverge more clearly by operating system. On macOS, Milo 2026.0 adds real-time raytracing support. Nevercenter states that this mode is broadly equivalent to the raytracing implementation on Windows, with improved shadow quality and lighting fidelity compared to earlier raster-only Mac builds.

On Windows, Milo gains a pathtracing mode intended for final-quality output rather than interactive navigation. Pathtracing is described by Nevercenter as physically based and progressive, refining the image over time when the camera remains still and restarting when the view changes. Hudson notes that lighting interpretation differs slightly from raytracing and raster modes, requiring manual adjustment of ambient levels or lighting rigs when switching between modes. Pathtracing is not available on macOS, due to Unreal Engine limitations on that platform (for now at least).

Soft shadows without raytracing

One notable rendering change applies across all platforms and quality modes. Soft shadows are now supported even when raytracing is disabled, for example, the Ring Light preset, which previously produced hard-edged shadows in raster mode.

In Milo 2026.0, raster mode preserves softer shadows for certain light types, while others such as the Sun rig continue to produce harder shadows by design. Nevercenter positions this as a quality improvement for users working without raytracing enabled, including those on lower-power systems.

All built-in lighting rigs have been updated and equalised. Nevercenter states that these presets now behave more consistently across raster, raytracing and pathtracing modes, and respond more smoothly to interactive adjustments.

Separate display and render quality settings

Milo 2026.0 introduces independent quality settings for display and render output. Users can navigate scenes in raster or raytracing mode while rendering final output using raytracing or pathtracing. This is a workflow feature intended to maintain interactivity in heavier scenes while still enabling higher-quality final frames. The render quality can be set to follow the display mode or overridden per output. Hudson notes that raytracing performance is now fast enough on many systems, including Apple Silicon machines such as the MacBook Air M2, that users may choose to stay in raytracing mode full time.

File handling and Silo synchronisation tweaks

Several small but practical workflow changes are included. Milo now supports drag-and-drop loading of model files directly into the application. Nevercenter also states that support for loading additional file formats has been added, and Integration with Silo has been refined . Objects set to wireframe or ghost shade mode in Silo are now automatically hidden in Milo when the file is saved. Nevercenter describes this as a convenience feature to exclude alternate or work-in-progress geometry from renders without manual layer or visibility management.

As in previous versions, material changes saved in Silo continue to update automatically in Milo, including adjustments to specular values that affect surface shininess in the renderer.

VR quietly exits

VR support has been removed entirely in Milo 2026.0. Nevercenter states that the feature was used very little and became increasingly difficult to maintain alongside new rendering features. Hudson describes the removal as a compromise to prioritise rendering quality and performance. Nevercenter does not rule out reinstating VR support in the future if user demand is strong, but no roadmap or commitment is provided.

What stays the same

Existing Milo features remain intact. These include turntable rendering and live spin previews, depth of field controls, wireframe overlays, adjustable background modes including sky, gradient, solid colour and image backgrounds, and line-art style rendering. Nevercenter emphasises that these features benefit indirectly from the performance improvements, remaining responsive even with higher-quality lighting enabled.

Nevercenter also highlights continued compatibility with its photo editing application CameraBag as part of the broader workflow, although no changes to that integration are described in this release.

Licensing and availability

Milo is not sold separately and continues to ship as part of the Silo licence. Nevercenter sells Silo as a perpetual licence, with Milo included at no extra cost. Milo 2026.0.0 is available to all current Silo users.

Supported platforms are Windows 10 or newer and macOS 12 or newer, including Apple Silicon systems. Hardware requirements for raytracing and pathtracing depend on GPU capabilities and operating system support, as defined by Unreal Engine.

Production notes

Milo 2026.0.0 represents a technically significant update, driven largely by its Unreal Engine 5.7 foundation and a focus on renderer performance. While Nevercenter demonstrates strong interactive results, particularly with raytracing enabled, artists should test the new version carefully on representative scenes and hardware before adopting it in production workflows.

// Nevercenter Milo 2026.0 release notes
// https://nevercenter.com/silo/features/#release_notes

The post Nevercenter speeds up Milo 2026 and drops VR quietly 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.

ZEISS has opened registration for the closed BETA phase of CinCraft Virtual Lens Technology, a new plugin that brings real-world lens characteristics into digital compositing. The software is designed for Nuke and targets VFX professionals who want to achieve authentic optical effects without relying on filmed reference plates.

Part of the expanding CinCraft ecosystem, the Virtual Lens simulates how physical lenses behave — from cat-eye bokeh and focus fall-off to chromatic aberration and distortion. The technology uses raytracing principles and GPU acceleration to reproduce these artefacts in real time, making it possible to apply consistent, lens-true effects across shots directly within a 2D workspace.

Artists can select from a digital library of lenses in the same way they would rent optics from a camera house, allowing postproduction teams to match footage from various sources or stylise shots without compromising realism. ZEISS positions the tool as a bridge between production and post, closing the gap between on-set optics and digital finishing.

The closed BETA runs from December 2025 through February 2026, and participants will receive access to the Nuke plugin along with direct feedback channels to the ZEISS development team (Tell them “Hi!” From the Digital Production Team when you do ;) ). Applications are open now via zeiss.com/vlt-closed-beta.

The move expands ZEISS’ footprint in virtual production and post workflows. With products like CinCraft Scenario and CinCraft Mapper, the company has already established a digital backbone for lens data and camera tracking. The new Virtual Lens Technology extends that legacy into compositing — where glass meets pixels, and optical physics go fully virtual.

Official BETA Registration: zeiss.com/vlt-closed-beta

Virtual Glass: ZEISS Enters the Simulated Optics Game

The post ZEISS CinCraft Virtual Lens Enters BETA: Real Glass, Virtual Magic first appeared on DIGITAL PRODUCTION and was written by Bela Beier.