For those who don’t know the tool: Pilgway makes 3DCoat for sculpting, retopology, UVs, painting and rendering. It connects to Blender, 3ds Max and Houdini (and LightWave) via applinks. 3DCoatTextura is the texture-focused sibling.

GPU paint, finally with nodes

3DCoat 2026 is now in public beta for Windows, and the big change is GPU Per-Pixel Painting. The new system adds a procedural Node System for UV-based, non-destructive texturing and lets artists create materials, masks and effects in a visual Node Editor. Parameters such as rust intensity, base color, glossiness and scratches remain editable during work, with real-time viewport feedback on the 3D model.

For artists who have spent years painting a layer, committing to it, regretting it, duplicating it, hiding it, naming it “final_final_02_nowforreal_b”, and then crying softly , this is the headline feature. The workflow moves more of the material logic into editable graphs. The development thread labels the build as an early beta and says it is not recommended for production environments. Believe the developers when they say that!

What the Node System does

The system uses GPU nodes and dynamic compilation into optimized shaders based on NodeGraph Language, or NGL. Procedural operations, mathematical operations and noise generators run directly on the GPU. That matters for texture artists because procedural work can become very chatty. Every mask, noise, curvature blend and dirt pass adds another little gremlin to the stack.

The documentation lists a full Node System with Node Editor, Node and Object Inspectors, Node Graph, NGL, GPU Nodes, Filters, Masks, Materials, Modifiers and Volumes. The GPU Texturing documentation also lists Per-Pixel Painting and PBM Channels.

The docs describe PBR texturing in 3DCoat around Albedo, Depth, Glossiness and Metalness channels. Painting can modify multiple material channels with one brush stroke. The new node system now sits beside that painting logic, rather than replacing the idea of channel-based texture work.

New smart materials, new smart masks

The 2026 beta introduces NGMaterials, NGMasks, NGModifiers and NGFilters. NGMaterials are procedural smart materials. NGMasks generate procedural wear, dirt and scratches. NGModifiers and NGFilters handle geometry deformation and procedural post-processing of current layers. The new materials support approximately 30 channels.

Procedural texturing in a painting app is always a balancing act. Artists want control without turning every barrel, robot arm or old pipe into a PhD in graph management. The Object Inspector tries to keep that sane. Parameters can be pinned from the node graph to general object or layer controls, so a material can expose useful sliders without making the artist dive into the full graph every time.

The UI adds a Node Editor, Node Inspector and Object Inspector. Node header colors are now category-based in the 2026-03 NS Beta. New nodes are created at the position where the right mouse button opened the menu, not where the cursor happens to sit when the menu action finishes.

Layers still matter

The new graph workflow does not remove the old layer habit. The beta adds the ability to select multiple painting layers, move selected layers within the painting layer tree, and group, hide, unhide, duplicate or delete them.

In GPUPPP mode, layer masks use brightness rather than relying exclusively on transparency. Normal Map Support appears in node-based materials in the 2026-03 NS Beta. A crash when clearing the Node Graph in the Node Editor has been fixed, and rectangle or CTRL selection of multiple nodes has also been fixed.

The 2026-02 preview also allows image reading and writing formats to be replaced via Python extension. Objects created by C++ functions from Python scripts will not be garbage collected by Python, avoiding double freeing.

Fabric, fur and soft displacement

The 2026-03 NS Beta adds a Soft Displacement property. The changelog describes it as a displacement effect designed to work with a normal map. It shifts vertices without affecting shading, reduces its shadow impact by half, and uses the normal map to define pixel orientation for shading.

SoftDisplacement combined with Sheen can simulate fur, while FWSNormal defines its direction. For PPP texturing, Show Displacement Mesh must be enabled and tessellation must be configured.

Retopo and modeling also get crumbs

The headline belongs to 3D texture painting, but the beta also touches retopo and modeling. The 2026-03 NS Beta adds an option in the Retopo and Modeling Room: Switching Pen Mode to Rectangle After the Select Transform Activated. Polygon Tree has been improved for speed with large files.

The Sculpt Room gets speedups for Blob tool filling in Smart Hybrid and a new lasso placement option for the Blob tool in Smart Hybrid. Live booleans get a crash fix when unghosting. STL import fixes address overly small scale on import.

3DCoatTextura’s learning mode keeps saving and loading in the internal .3b format, with a limitation of 10 layers and render watermarks. OBJ export remains available with limits: 4000 triangles from the paint room and texture export up to 512 by 512 without watermarks, or higher resolution with watermarks. Commercial use is not allowed for that free learning-mode output.

Pricing, because artists own wallets

The official 3DCoat buy page lists 3DCoat 2025 Individual Node-locked at €379, VAT not included. It is a permanent personal license, allows commercial use, works as a platform-independent license and includes 12 months of free updates.

The same page lists subsequent updates at €45 from month 13 onward after purchase, or €90 from month 25 onward if the €45 upgrade was not made, with another 12 months of free updates.

Bottom line

The best news is not just “nodes”. The useful news is that the system connects to painting layers, masks, smart materials and viewport feedback. That is where texture artists actually live.

The caution flag is equally clear. The build is beta, Windows-only in its current public form, and explicitly not recommended for production environments. Test it, break it, report the boring bugs, and do not bet a delivery on it yet. The graph may be shiny, but the deadline goblin remains undefeated.

https://3dcoat.com/forum/index.php?/topic/34175-3dcoat-2026-gpuppp-development/

The post 3DCoat 2026 gets GPU nodes first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Blender uses Blender Cycles for path-traced rendering, and viewport denoising helps lookdev stay interactive while lighting and materials evolve.

The news, minus the confetti

NVIDIA says Blender Cycles will integrate DLSS 4.5 Ray Reconstruction as a new denoiser and ship it with Blender 5.3 in the fall. The goal is a more interactive viewport while keeping a “near-final” look in real time.

DLSS Ray Reconstruction targets ray-traced and path-traced content and replaces traditional hand-tuned denoisers with an AI model that reconstructs pixels in noisy areas where rays were not sampled. It also unifies denoising and Super Resolution into a single model that uses temporal and spatial engine data to rebuild higher fidelity images. Usually, that is for games – you need all the pixels and all the fidelities for veggie-mode in Microsoft Flight Simulator (Don’t Judge, the Dune expansion is great!) Here is a list of all Games that have that, and in that list, you can even spot Redshift, Marmoset and Keyshot. Strange calling those “Games”, but who hasn’t lost to a renderer?

The same announcement says DLSS 4.5 Ray Reconstruction arrives in August for games, and it is also coming to Blender 5.3 in the fall. That timeline matters for anyone planning tool rollouts around seasonal show crunch. Prep first,so you don’t have a bad surprise up ahead.

What changes inside Cycles

Cycles already has an integration path via NVIDIA OptiX. The new piece is DLSS 4.5 Ray Reconstruction as another denoiser option, layered on top of the existing OptiX integration.

If you spend your days in a path-traced viewport, denoising is not a luxury feature. It is the thing that keeps lighting decisions moving. A denoiser that keeps interaction up while pushing the look closer to final could reduce the familiar loop of tweak, wait, squint, tweak again. This sits squarely in the Blender Cycles ecosystem: you still light and shade the same way, you still render the same way, but the viewport becomes less of a tax on iteration.

The longer arc from hacks to shipping builds

Back in February 2026, Blender artist Blake Propst tested a Blender 5.1 build with DLSS on an RTX 3090, with reports of numerous bugs and visual issues. A patch also existed that added an option to use DLSS Ray Reconstruction for viewport denoising in Cycles, and users were encouraged to test Blender 5.1 beta and report issues toward a stable release.

Blender With DLSS!
byu/bbcool2002 inblender

That earlier phase sounded like classic early integration energy: exciting demos, messy edges, lots of caveats, and a very human amount of duct tape. It did prove one thing, though: artists wanted it badly enough to put up with rough builds, because interactive path tracing is still a wrok in progress on most desks. Now the situation shifts from experiments to a shipping target in Blender 5.3.

What DLSS 4.5 Ray Reconstruction claims it does

DLSS 4.5 Ray Reconstruction uses a second generation transformer model. It is improving image quality in ray-traced and path-traced content, and the announcement lists changes such as higher compute capability, more parameters processed while maintaining similar performance to the previous model, better temporal stability, and clearer motion in ray-traced and path-traced scenes. For artists, the practical question is not whether the model sounds clever. The practical question is whether it behaves well under production pressure: animated textures, fast camera moves, thin geometry, alpha heavy foliage, refractive messes, and the kind of lookdev that loves to change one variable per second.

Viewport denoising is where time disappears

A big chunk of render pain is not final frames. It is the time you spend waiting for a viewport to become readable enough to make the next decision. A clean enough image lets you judge lighting ratios, contact shadow behavior, glossy breakup, and whether your material values drift into plastic. A noisy image forces you to wait, or worse, to guess.

The boring parts you still need to know

Pricing is not specified in the sources – propably will be part of drivers or blender itself, so should be free. Read the T&C before downloading, though.

Hardware requirements are not spelt out for Blender beyond the general statement that DLSS Ray Reconstruction works on all GeForce RTX GPUs. The Blender sources mention testing on an RTX 3090 and as part of an RTX focused stack, but they do not provide minimum GPU or driver versions for the Blender 5.3 integration. We’ll see.

https://www.nvidia.com/en-us/geforce/news/computex-2026-nvidia-geforce-rtx-announcements/

The post NVIDIA brings DLSS denoising to Blender 5.3 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Motion designer Mike Gaynor built Caddis over four months in nights and weekends, and pitched it as the layer timeline you already know paired with a node graph inside every single layer.

Work starts in a familiar stack of layers, with keyframes and timing edits on a timeline. Select a layer and its node contents appear in a graph panel beside the timeline and viewport. The idea is to avoid choosing a single paradigm when motion work often lives between both. Inside that per-layer grahp, the beta already includes more than 100 nodes to wire together. Nodes can drive parameters directly, with examples like linking rotation to scale, scale to audio, and audio to color.

Caddis Layers can stay simple, or turn fully procedural

A layer can stay as basic as one line of text, or expand into a fully procedural build with fields, shapes, video, and audio flowing through it. The demo frames it like patching a modular synth, with links between values, movement, and math. The product site leans into the same concept with a promise of visual logic in place of expressions, and a workflow where every parameter becomes something you can wire, modulate, or replace. It also positions the node graph as the home for compositing work like blending, masking, and mattes. Color tokens appear in the demo as a way to recolor a whole project in one click. The demo also shows saving subgraphs as recipes, then reusing or sharing them as a single file.

Responsive comps, plus GPU-native rendering

The demo says designs can be responsive, showing a resize from 16 by 9 to 9 by 16 with the layout adapting on its own. Caddis describes itself as a native desktop app on a modern GPU pipeline. The website calls out GPU-native rendering, aiming for a responsive viewport while iterating, and exports without leaving the tool. Treat that as a marketing claim until your own workstation agrees. Either way, new tools and innovations should be tested before use in production, ideally on real shots, real deadlines, and at least one truly cursed client change request. Beta is coming, so we obviously haven’t tried it yet – sign up as well, we’ll learn together what actually appears when Caddis comes out.

Import and export reality check

Caddis positions itself as an alternative rather than a drop-in replacement for After Effects and does not import After Effects projects. Instead, it works by importing media and rebuilding comps inside the app. On export, the product site lists standard formats including Apple ProRes, MP4, and image sequences including H.264 and ProRes, plus PNG and OpenEXR image sequences, and standard web formats. The demo additionally names WebM and GIF, plus PNG sequences, as native.

Caddis Pricing, beta status, and platform notes

Caddis is free during beta. The product site lists a $99 launch price for early adopters and $129 regular pricing, positioned as a one-time purchase with no subscription. The software should be compatible with macOS 12.0 or later, with a Windows version due shortly after launch. If you plan to roll it into a pipeline, assume the usual early-tool homework: bake out deliverables, double-check colour management expectations, and confirm the layer graph behaviour does not change between beta waves.

https://www.caddis.app/

The post Caddis mixes layers with nodes per layer first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Paradigm is a GPU liquid solver that runs inside Houdini, alongside Axiom, using node based workflows for VFX liquid setups.

What 1.0 actually changes

Paradigm 1.0 targets GPU accelerated liquid simulation in Houdini, and the developer describes it as a “hybrid that can be called a FLIP solver while borrowing ideas from SPH”, whatever that means. It is supposed to be faster and more accessible than Houdini native liquid tools.

Version 1.0 ships as a sequence of point releases that stack up into something production artists can actually evaluate. The current notes focus on simulation stability, faster solvers, better sourcing, more outputs, and a Tank workflow aimed at open water setups. If you live in Houdini, this is the kind of list that determines whether you can keep a shot moving or spend the week explaining why it will be ready next week.

Sourcing gets less crunchy

The 1.0.153 to 1.0.175 updates bring a major round of sourcing work. Particle emission from source shapes improves, with spacing and layout described as more random and even, and with less repetition. A separate Particle Source node arrives to control emtoion timings in a way described as similar to source shapes.

Read more: Theory Accelerated shifts Paradigm 1.0 for Houdini

Sourcing can now push more than just positions. The solver can output particle attributes like color, temperature, viscosity, and rest as optional outputs, and it also adds age and life attributes plus lifespan controls to remove particles that age past their life value. It can also output churn, described as the magnitude of the curl of the velocity field, as an optional field.

The system also supports defining extra arbitrary particle attributes by defining them in the output tab of the solver node. Source VDBs can affect particle attributes, for example by sourcing a temperature volume source to make particles hotter. Temperature and color attributes can diffuse and dissipate. A relax force is described as now working properly and as fully deterministic. All of that translates into a much clearer story for lookdev and downstream controls. You get more handles, more outputs, and fewer excuses to bake everything into a single sim and pray.

The performance pass: SDF, advection, sorting

The 1.0.176 to 1.0.219 updates lean hard into speed and numerical behavior. A much faster SDF creation algorithm lands, plus changes to advection that make it faster by considering the SDF collision value when stepping forward. Adhesion becomes more accurate by using the collision SDF gradient for directions.

Particle handling also gets a leaf-based sorting method described as greatly improving the performance of grid sampling. The solver can better predict future resource needs when reinitialising, called Acceleration in the Advanced to Solver tab. There are also new filters for the output surface SDF, specifically erode and dilate filters, plus additional filtering options for the output surface SDF as a concept in the earlier 1.0.153 to 1.0.175 set. The end result is still an SDF output, not a finished mesh.

If you want a mesh, you still need to convert the surface SDF to a mesh using the VDB Convert node in Houdini. That’s cool for shot work, because it keeps the meshing and any post-smoothing in familiar Houdini territory, with all the usual caveats about voxel size, narrow features, and meshing time. You know the drill.

PCG everywhere: viscosity and pressure style steps

Viscosity gets a major upgrade in 1.0.176 to 1.0.219. It is described as much faster, with a new PCG-based solver. On the control side, multiple control ramps arrive for viscosity and gravity, and gravity and drag can be driven with control ramps in the earlier update set. Viscosity can be driven with a viscosity or temperature particle attribute, and there is collision conductivity for temperature diffusion plus the ability to source collision temperature for melting or freezing effects when particles touch a collider when using viscosity.

In practical terms, these controls push Paradigm closer to how artists like to art-direct liquids. You can tie behaviour to attributes, and you can do it without building a separate rig of custom forces for every shot. Also, a speed limit force bug gets fixed, where values could clamp incorrectly and produce a lower speed limit than expected. That is not glamorous.

Tank workflows and open water domains

Paradigm 1.0 adds a Paradigm Tank node for creating open water. These domains can be animated to have a moving container. Later updates describe the tank node as more stable and efficient at different scales.

For artists, that sounds like fewer edge cases and less time spent re-scaling a scene just to make the container behave. It also points to a workflow that is intentionally separate from classic boxed FLIP tanks, which feel like they belong to a different decade of fluid tools. And yes, I am thinking in decades; I am old.

Outputs, fields, and other useful knobs

The 1.0 notes mention more efficient sinks. Output field precision issues that could cause garbled outputs get fixed. Source shape noise can optionally cull source particles instead of just source values. Some blend modes get fixes when sourcing with source shapes.

None of this removes the need for real pipeline testing. New tools and innovations should always be tested before use in production, especially when the toolset is still evolving across frequent builds and wet behind the ears. (Obvious joke. Watersim. Wet. I need more coffee.)

What it does and does not include

Paradigm does not include narrow-band support yet. It does not currently have reseeding, though it is something likely to be added. A white water solver is in development, and the suggested current approach is to use Paradigm with Houdini’s white water solver.

Ocean spectrum workflows are described as not officially supported. The FAQ describes a possible approach using custom sources if the spectrum is converted to velocity fields and mask, with a desire to add full support for ocean spectrum in the future. That future support is not confirmed.

Compatibility and system requirements

Production builds of Houdini 20.0 and higher are supported. Daily builds are not supported. Windows, Linux, and macOS are supported. Nvidia and Apple GPUs are recommended, and any device that supports OpenCL 3.0 should work. Due to issues with drivers, some GPU may not be supported.

Pricing, licensing, and the parts people actually ask about

Paradigm Indie is $99 as a node locked license and can only be used with Houdini Indie. Paradigm Commercial is $199 as a node locked license and can be used with Houdini Core and FX.

Each node locked license includes one year of maintenance that renews annually, plus a perpetual license for all builds released during the maintenance period. A node locked license can be used on two devices at a time, with a maximum of two licenses per studio. Floating licenses exist for Paradigm Commercial via contacting sales.

The FAQ also states that Paradigm is free to use with Houdini Educational and Apprentice licenses, matching the vendor’s approach for Axiom. During the open beta for version 1.1, it is also free to use with no license or login required, with builds lasting 30 days from the date of publishing. The 1.1 open beta is scheduled to start in early May 2026. There is no release date, and the estimate given is 2 to 3 months, described as just an estimate.

If you are planning to integrate this fluid into a pipeline, test the licensing workflow, expiry behaviour, and Houdini version constraints in your actual studio environment. Then test again on the machine nobody loves, because that is the one that will end up simming the hero splash.

Where this sits in a broader Houdini sim stack

Liquid Thinking: Paradigm Brings GPU Speed to Houdini

Paradigm is a separate solver from Axiom, and the FAQ states there is no two-way coupling between the two. That does not stop you from using them in the same Houdini project, but it does mean you should not expect an automatic handshake between liquid motion and volumetric effects. You can still do the usual tricks using exported fields and caches, but the coupling is a pipeline job, not a one-click feature.

Axiom 4 for Houdini: Faster GPU Pyro With Better Collisions

This is also where expectations need to stay grounded. Paradigm outputs a surface SDF with filtering options, and Houdini converts that to a mesh. White water comes from Houdini’s own white water solver for now. Narrow band and re-seeding are not there yet. If your shots require those features, treat 1.0 as a serious tool that still leaves some work for you.

If you adopt it, run a focused test pass: emission behaviour, collisions with temperature effects, viscosity art direction, SDF meshing quality, and driver stability under OpenCL.

https://www.theoryaccelerated.com/paradigm

https://theoryaccelerated.notion.site/paradigm-1-0-whats-new

https://theoryaccelerated.notion.site/paradigm-1-faq

https://www.theoryaccelerated.com/axiom

The post Theory Accelerated shifts Paradigm 1.0 for Houdini first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: OctaneRender is a GPU renderer with DCC plugins like Blender, Cinema 4D, and Houdini. It ships via Studio+ and has a macOS stepsibling called Octane X.

Virtual textures, now allowed on the farm

OTOY shipped OctaneRender 2026.3 with a headline change that matters to anyone who has ever watched a heavy lookdev scene bully a GPU: network rendering now supports virtual textures. Virtual textures arrived earlier in the 2026 cycle, and 2026.3 extends that system beyond the local box so you can run the same approach in distributed jobs instead of treating it like a workstation-only party trick.

If your pipeline leans on huge texture sets, this is the kind of change that can reduce the amount of manual babysitting around what fits where. It does not magically fix bad asset hygiene, but it can remove one common excuse for why a scene behaves differently on an artist’s machine versus a render node. The release notes also call out a reduction in time to first sample in render nodes when scenes contain large image counts, which pairs naturally with the idea of texture-heavy shots that take too long just to begin doing anything visible.

One practical footnote: the release notes explicitly say that virtual textures are not supported for texture displacement. That line sits inside a crash fix description, but the constraint itself matters. If your assets rely on displacement driven by high-resolution maps, you still need to plan for the old reality there, even while the rest of the texture stack gets more flexible.

Trace sets, shadow catchers, and other production glue

2026.3 continues to sand down workflow edges around features introduced earlier in the 2026 line. Trace set visibility rules can now also apply to shadow catchers, which sounds small until you are trying to art-direct what reflects in what while keeping plate integration sane. Shadow catchers often sit at the intersection of lighting cheats and comp expectations, so anything that reduces the number of special cases usually pays back quickly.

There is also an update to USD import preferences: you can override point instances so they can be used to instance other external geometries. That is a very specific knob, but pipelines that move a lot of set dressing through USD tend to accumulate a lot of “why does this instance not behave like that instance” questions. Having an explicit override in the import preferences at least gives TDs another lever that lives in the tool instead of in an external patch script.

The same release adds support for importing float and colour primvars from USD curves, and it fixes an issue where motion blur was not visible when using USD curves. If you push curves for hair, cables, trails, or procedural motion guides, this is the kind of boring detail that stops being boring the moment it breaks a shot.

For readers tracking platform standards, this is another reminder that renderer updates are increasingly about interchange stability as much as raw features. You still want speed, but you also want fewer surprises when assets cross DCC borders.

MaterialX displacement support gets more real

The 2026.3 release adds MaterialX import support for displacement shader sub graphs. It also fixes a handful of MaterialX-related issues, including proper operation for TransformNormal and TransformPoint, errors when loading scenes with Time and Frame nodes, alpha blending in HexTiledImage for color4 outputs, and import issues around bi-tangent inputs that could break normal mapping.

If your studio has been treating MaterialX as “great in theory, wobbly in practice”, this is a concrete step toward the practical side. A step, not the finish line! Not even for Scandinavian Studios! It does not claim perfect parity with every other tool, but it does show attention to the unglamorous parts: node correctness, error spam, and consistent interpretation of common transforms. A separate behavior tweak affects anisotropy: rotation in Standard Surface now matches OpenPBR and other renderers, and existing scenes are not affected. Hopefully

NRC memory use drops, plus a grab bag of fixes

OTOY says memory usage has been reduced when using the Neural Radiance Cache, referred to as NRC. The same notes mention fixes for render artifacts when using volume media in combination with NRC, plus a crash fix when rendering starts while virtual textures compile and are used in texture displacement, with the earlier reminder that virtual textures do not support texture displacement.

There is also a long list of resolved issues touching a lot of interchange formats and stability landmines: fixes for Alembic loading with materials saved as non-constant FaceSet objects, multiple FBX importer and exporter issues around vertex attributes and vertex animations, crashes on unsupported or invalid SPZ files, and potential application crashes upon initialisation on Windows and Linux.

A small but very real quality-of-life fix: empty file name nodes no longer get replaced with the directory of the containing OCS file, and they stay empty. That is the sort of bug that creates invisible path issues that only show up in a farm run at 3 a.m. on a Saturday night, while you are trying to remember what these things called “Weekends” were, the strange people in the group called “Friends” on Discord are blabbing about. Random example.

Drivers, OS baselines, and what your IT team will ask

The release notes list two explicit minimums. The minimum NVIDIA driver version required is R555, and it is R572 for GeForce RTX50 series. The minimum version of macOS required is 14.5.

Lua API tweaks for pipeline tinkerers

2026.3 includes Lua API changes that target data handling and introspection. Several octane.node functions now accept raw C arrays for cases where the API expects an array, and there are new helpers for querying animator types and retrieving animator data as a raw C array. It also states that for non-array attributes, you are allowed to set animators with different channel counts from that of the attribute type.

If your facility uses Lua to automate scene setup, tool integration, or pipeline hooks, or just is full of Autohotkey-Nerds (My People!) these are the kind of changes that can reduce wrapper code and make scripts less fragile. It is not the most glamorous section , but it is often where studios quietly win back hours.

Pricing and availability

OctaneRender 2026.3 is available via downloads linked from the release notes, including standalone builds for Windows, Linux, and macOS, plus node builds for Windows and Linux, and demo downloads for Windows and Linux.

Pricing is subscription-based via Studio+. The OctaneRender Studio+ subscription is 24€ per month billed monthly, and 20€ per month billed yearly for an annual subscription. There is also an OctaneRender Offline USB Dongle for 49 euros.

Even if the feature list sounds perfect for your exact setup, treat it like any other renderer update: test it on your own scenes, with your own texutres, on your own farm, before you let it anywhere near a delivery schedule.
https://render.otoy.com/forum/viewtopic.php?t=85624

The post OctaneRender 2026.3 adds virtual texture netrender first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

For those who don’t know the tool: V-Ray runs inside Autodesk 3ds Max and Blender and many other DCCs, with V-Ray GPU as the hybrid GPU and CPU engine alongside CPU rendering.

AMD is back on the render menu

After a long stretch of one-vendor reality for GPU finals, Chaos reinstated support for GPU rendering on AMD hardware in V-Ray GPU by implementing HIP as a render backend in V-Ray 7 Update 3 for Autodesk 3ds Max. The change lands in the V-Ray 7 Update 3 build for 3ds Max, (build version 7.30.02).

This matters because V-Ray GPU previously supported AMD through OpenCL, and that path wound down with the V-Ray Next era in 2018. In production terms, many shops treated V-Ray GPU as effectively tied to NVIDIA backends for years, even if the CPU engine remained fully cross platform. Support for HIP is also expected to roll out to other V-Ray integrations, including V-Ray for Blender.

What exactly changed inside V-Ray GPU

V-Ray GPU now exposes HIP as a backend option in the 3ds Max integration, alongside CUDA and RTX modes. HIP is designed to let developers target both AMD and NVIDIA from a single code base using a CUDA-like programming model, and it sits within the broader ROCm stack. On AMD, V-Ray GPU runs through HIP, and the team also opened HIP RT as the ray tracing acceleration path. HIPRT remains a work in progress in V-Ray GPU. In other words, this is not a checkbox labelled “AMD” that secretly does CPU. It is a new backend that runs V-Ray GPU on modern Radeon hardware, with the HIP path delivering the strongest and most consistent AMD results in the current test set.

Supported GPUs, drivers, and the fine print you actually need

The supported AMD generations for V-Ray GPU via HIP currently include RDNA2, RDNA3, RDNA 3.5, and RDNA4, across consumer Radeon and selected Radeon Pro products. The recommendation is RDNA3 and above. The minimum supported driver listed for AMD is AMD Software Adrenalin Edition 26.2.2.

A concrete example used for testing is the Radeon RX 9070 XT, a consumer GPU with 16 GB of GDDR6 memory, a 256 bit memory interface, and up to 640 GB per second of memory bandwidth. AMD announced the card at a €799, while retail pricing varies by board partner and region. Currently, you can get variants around 650€.

If you want to map that to pipeline decisions, the takeaway is that the minimum bar is no longer latest flagship only. The supported list includes multiple generations and both consumer and workstation lines, with a driver baseline you can actually put into an IT image.

Performance: competitive, then weirdly spicy in out-of-core

The performance story splits into two very different conversations: in core scenes that fit in VRAM, and out of core scenes that push textures into system memory.

Across the current test scene set, results are described as solid overall, with most scenes rendering without issues and output matching expected results. The RX 9070 XT is described as delivering competitive performance for a 16 GB consumer GPU, while the RTX 5080 stays ahead in most in core cases.

Then the out of core path shows up and flips the mood.

V-Ray GPU has a Use System Memory for Textures option that moves texture memory pressure into system memory. That matters when your scene does not politely fit into VRAM and you do not want a last minute downres exercise.

In the out of core scenes tested, the RX 9070 XT is not just competitive but clearly faster in several cases, with the largest gaps reaching multiple times faster in the current dataset.

That is the part to pay attention to if you live in archviz city blocks, hero characters with absurd texture stacks, or anything where the phrase texture budget is usually followed by laughter and then silence.

HIP and HIPRT: what artists should take from that alphabet soup

HIP is the enabling layer that makes AMD execution possible in V-Ray GPU. HIPRT is a separate ray tracing library for HIP aimed at ray tracing acceleration.

In the current state, HIP delivers the best AMD results, and HIPRT remains under active evaluation and not production ready. The implication for day-to-day users is simple: backend choice still matters, and the fastest mode on one vendor does not automatically exist on the other in the same way today. That is also why you should treat this update as you would any other new render backend. Test it on your own scene types, your own noise tolerances, your own texture formats, and your own deadline pressure, before you let it touch finals.

Workflow impact: more options, more responsibility

The practical upside is hardware flexibility. Some teams already sit on Radeon cards, and some freelancers shop by VRAM per euro. Bringing AMD back into the V-Ray GPU conversation adds some choice again, especially in that midrange 16 GB bracket that appears in purchasing approvals. The practical downside is that a new backend tends to surface edge cases. Output matching is described as consistent in the tested scenes, but you still need to validate your own shading networks, your own IPR expectations, and any pipeline automation that assumes a specific engine string.

If your pipeline uses Blender for lookdev or layout, it is also worth noting that HIP is not foreign there. Cycles already supports HIP as a GPU backend option on Windows and Linux, which at least reduces the surprise factor when artists see the acronym in preferences.

The boring conclusion that saves productions

That is enough to make a lot of workstation build spreadsheets suddenly look different, adn enough to justify real evaluation time in a studio where GPU rendering is not a side hobby.

https://blog.chaos.com/amd-gpu-rendering-vray
https://documentation.chaos.com/space/VMAX/707559558/7.30.02

The post Chaos restores AMD GPUs in V-Ray first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The problem NanoGS tackles

3D Gaussian splatting can look like magic right up until it starts behaving like a tax audit. Big captures mean millions of splats. Millions of splats mean constant sorting work, a lot of memory pressure, and a very real risk that the renderer spends time drawing things the camera never sees. NanoGS targets that exact pain: rendering large-scale Gaussian splatting files in real time, while handling video memory pressure, sorting huge splat counts efficiently, and drawing only what the screen needs.

The approach focuses on a set of optimisation techniques: Nanite-style LOD clusters, screen-space error LOD selection, splat compaction, a global accumulator, and GPU radix sort. The headline promise is straightforward: large-scale Gaussian splatting scenes should render efficiently, with an emphasis on keeping memory usage low. That is a marketing claim.

Supported engine versions and what you actually install

NanoGS lists support for Unreal Engine versions UE5.6 and UE5.7. The workflow stays inside the familiar plugin lane. You download the plugin from the releases page, place it into your project’s Plugins folder, then import a PLY file using the plugin import button. That import creates a Gaussian Splat Asset, which you can drag directly into a level for rendering.

There is also an asset action to enable or disable Nanite if needed. It is an unusual sentence to write about splats, but that is the point: the tool is trying to make splats behave like a native citizen in the realtime world.

The controls that decide whether it feels stable

The plugin exposes settings grouped by intent. They map cleanly to the trade-offs most realtime teams already juggle: quality, performance, and final look. On the quality side, SH Order adjusts spherical harmonics quality. On the performance side, Sort Every Nth Frame changes how often splats get sorted. Enable Frustum Culling turns frustum culling on or off. LOD Error Threshold sets how sensitive LOD cluster switching should be. On the rendering side, Opacity Scale adjusts splat opacity, and Splat Scale adjusts splat size.

These are not vanity sliders. Sorting frequency can be the difference between a stable camera move and a shimmering mess. Culling can be the difference between a scene that fits and a scene that explodes memory. LOD sensitivity can be the difference between crisp detail and visible popping. And opacity and scale are the levers that decide whether the splats read as a coherent surface or as a cloud of regret.

About one third into your first test session, you will probably notice the same thing most teams do: the scene can look fine at rest, then fall apart during motion if sorting gets too infrequent. That is when you stop guessing and start dialing.

Debug commands that make problems obvious

NanoGS includes console commands designed for inspection and stress testing. gs.ShowClusterBounds 1 enables a Nanite cluster preview, and setting it to 0 disables that preview. gs.DebugForceLODLevel can force rendering at a specific LOD cluster level for debugging, with values like 1, 2, 3, 4 and so on.

Then there is the one that will get used the most in anger: gs.MaxRenderBudget. It limits the maximum number of visible splats after culling to save memory. The default is no limit, using 0. You can set a maximum cap such as 3,000,000. When the cap is active, the culling starts from splats far from the camera.

If you are trying to ship anything on fixed hardware budgets, this kind of explicit cap is refreshing. It makes the failure mode predictable. It also makes it easier to have honest conversations with art and production, because the tool draws a hard line instead of pretending everything will fit if you just believe harder.

Best practice: do not feed it one giant splat brick

NanoGS calls out a best practice that will sound familiar to anyone who has ever fought streaming, culling, or draw lists. A single big chunk of gaussian splatting file does not help performance optimization. Splats outside the camera view cannot be culled effectively. And if everything stays in one chunk, all splats stay engaged in sorting all the time.

The recommended format is to slice a large splat file into smaller pieces. Examples given include individual props for cinematic scenes or tiles for geo-spatial data. The repository includes a simple tile slicer written in Python to support that workflow.

Proof of concept, not a miracle

NanoGS is described as a proof of concept, with a clear warning not to expect perfect results. Issues can be reported on the project page. That framing matters for production teams because it sets the correct expectation: you are evaluating a technique and an implementation, not adopting a finished commercial renderer. The good news is that the tool is built to be tested, with the kind of switches and debug views that make evaluation less mystical.

New tools and innovations should always be tested before use in production, especially when they touch core rendering paths and memory budgets.

Release, license, and what it costs

NanoGS is released under the MIT license.

The repository lists v1.0.1 as the latest release, dated March 20, 2026.

The plugin is free.

https://github.com/TimChen1383/NanoGaussianSplatting

The post NanoGaussianSplats for UE5 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Redshift is a GPU renderer built for fast lookdev and final frames. Vectorworks is a BIM (Building Information Modeling) and CAD hub where buildings get drafted and organised.

Architectural visualisation pipelines love a clean handoff, but they hate the part where you wait for it. Redshift for Archviz positions itself as a single-environment loop: preview inside your BIM tool, iterate while the model still feels editable, then render without rebuilding the whole look in a second app.

The core pitch is direct integration with Vectorworks, aimed at letting artists and designers stay in the same workspace while moving from real-time previews to final renders. The platform targets the usual ArchViz pressure points: quick iterations, look development that stays consistent from draft to final, and visuals that survive client meetings without the dreaded “we will render it later” disclaimer. Maxon describes this as an expansion of the same rendering technology used in its existing ecosystem, tuned for real-world, real-time architecture design workflows

Real-time lighting that behaves like a grown-up

In the feature set, the real-time preview leans hard into lighting, materials, and environment response. The toolset includes controls to change the time of day, sun position, and cloud cover, to show how natural light interacts with the design as you adjust conditions.

Cloud cover control is quite precise, spanning conditions from clear to fully overcast, specifically to visualize how clouds affect natural light, shadows, and the overall mood of an architectural render. That kind of environment knob matters because it ties directly to decision-making. When lighting direction and softness update instantly, material choices stop being theoretical and start becoming compositional tools.

Assets, materials, and the eternal fight against empty rooms

The content side is framed around libraries that help you get to “inhabited space” faster. A growing asset library includes materials, lights, and ready-to-use assets intended to speed up scene building while keeping physical accuracy and visual consistency.

On top of that, the feature descriptions call out drag-and-drop population of interiors and exteriors with a selection that includes furniture, vehicles, realistic plants, and people, and these assets interact naturally with surfaces.

Material coverage is physically correct, spanning concrete and metal through glass, wood, and textiles, with the promise that materials react naturally to light and environment. The workflow emphasis stays on applying, adjusting, and previewing changes in real time, so look development can happen while you are still shaping the design.

Mac and Windows parity, right from the start

Platform coverage is plain: Redshift for Archviz is available for Windows and macOS, andfeature parity across both platforms from the outset. That matters whether you bounce between machines in a studio or your clients do. It also matters if your pipeline includes artists who bring their own gear and do not want a surprise feature gap halfway through a project.

The Cinema 4D escape hatch for the fancy stuff

When a still image turns into a walkthrough, you need more than a preview window. The workflow includes the ability to send a project to Cinema 4D with a simple click, with the intent of enabling more advanced architectural visualisation work, including procedural animations and simulations.

The FAQ describes export from the Redshift for Archviz plugin to Cinema 4D, and states that geometry, materials, cameras, and basic lighting generally transfer well. Once in Cinema 4D, refining scenes, materials, and lighting with a higher level of control is as usual, and then extending the project with animation and simulation.

This is a practical bridge for teams who want the speed of in-app previs but still need a DCC stage for shot craft, camera choreography, or heavier scene management. It also keeps the promise of visual continuity: the same scene, lighting, and materials across preview and final output.

Installation and the beta-shaped reality

The tooling around installation is explicit enough to be useful. The install notes state that the current availability is for Vectorworks, with Revit and Archicad coming soon.

For the Vectorworks side, the guide references installing Vectorworks 2026 using default settings, downloading and signing into the Maxon App, installing an AEC Viewer, then activating the plugin inside the host application by customising the workspace and adding the Redshift entry from the Rendering category. Launch is a Auto Synch button inside the host environment. Use requires creating a MyMaxon account and accepting an EULA. The subscription bundle (Plans and Pricing) supports multiple instances with up to eight GPUs on a single computer.

Because this is new workflow territory, treat early adoption like you treat any new renderer, plugin, or bridge. Run a proper test scene, push the corner cases, and validate the round-trip before you bet a deadline on it. Do that before you put it into production.

What this means for working artists

The practical story is simple: real-time previews inside a BIM host, asset and material libraries geared at architectural scenes, cross-platform support on Windows and macOS, and a pipeline bridge into Cinema 4D for animation and simulation.

If you live in the overlap between design and storytelling, this kind of integration can reduce handoffs and shorten iteration loops. If you live in the overlap between client expectations and physics-based lighting, real-time environment controls can turn “maybe” into “yes” quickly.

Just remember the unglamorous part: new tools and innovations should be tested before use in production, even when the marketing copy sounds like it was written by a very confident sunbeam.

https://www.maxon.net/en/article/maxon-introduces-new-real-time-rendering-and-cinematic-previews-solution-for-architects

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

InstaMAT Studio is out now – a layer-based painting and node-based authoring tool in the same general category as Substance 3D tools like Substance 3D Painter, Substance 3D Designer, and Substance 3D Sampler, with integrations into common DCCs and engines including 3ds Max, Blender, Maya, Unity, and Unreal Engine.

What changes in 2026 is the set of levers available for high-precision, iteration-friendly detailing. Curves Brushes move detail painting toward an editable, control-point workflow. Lazy Stroke helps freehand lines behave. Radial symmetry adds a new patterning tool. Masking and mesh filters expand geometry-aware selection and effects. The new toolbar and hotkeys aim to keep artists in flow instead of chasing settings panels.

And yes, your first experiment should probably be those curve-driven panel lines that always look great right up until the model changes. This time, the system is explicitly designed so the detail survives that upstream change.

Curves Brushes: strokes that stay alive

Curves Brushes let you create editable curve paths on the mesh, using control points rather than a one-and-done freehand stroke. Those curves remain editable after creation, including moving and refining control points, and transforming an entire curve as a unit by translating, rotating, or scaling the path.

A single curves layer can hold multiple curves, and their painting sequence can be reordered. Curves can also be set to erase instead of paint, and they can be closed to form continuous shapes from end point to end point.

Control points support different point types, including linear, symmetrical, smooth, and cusp, with a Joint Smooth setting to control how sharp or fluid the transitions are between segments. Each control point also supports per-point settings for radius, falloff, flow, and rotation, enabling effects such as tapering and gradual fading along the curve.

Curves can orient brush strokes along the path, so details follow the curve’s flow rather than fighting it. Curves also support dynamics for randomised size, flow, rotation, and position to add variation without manually wiggling your wrist into submission. The Curves workflow uses a GPU-accelerated 3D painting engine and does not rely on mesh UVs. The stated result is that curves remain intact even when topology or UV layout changes, which is framed as especially useful for repeating high-precision details such as panel lines, seams, stitches, and decorative elements.

Lazy stroke smoothing, now built in

Alongside Curves, InstaMAT 2026 adds Lazy Stroke, a brush-smoothing feature designed to dampen shaky-hand input and cursor jitter. When enabled, the brush follows the cursor with a delay set by a configurable radius, producing smoother lines for precision freehand painting. The feature is positioned for tasks such as smooth linework, organic patterns, and fine-detail passes where jitter becomes visible in the final maps. If you have ever zoomed in to paint one confident line and instead produced a seismograph reading, Lazy Stroke is aimed squarely at that moment. Try it, then decide if it belongs in production.

Symmetry upgrades: radial joins planar

Radial symmetry painting is new in InstaMAT 2026, enabling repeating brush instances around a central axis. The symmetry axis can be set to X, Y, or Z, the number of repeated instances is configurable, and the angle span can cover full 360 degree patterns or partial arcs. The plane origin is also customizable, allowing the symmetry center to be placed where it is needed on the asset.

Planar symmetry painting is also described as significantly improved. The symmetry plane can be offset to a custom position on any of the three world axes, plane visibility can be customised, and there is an option to mirror the brush on the opposite side of the plane. Symmetry accuracy is described as improved even when painting on meshes that are not exactly symmetrical, targeting the real-world scenario where characters and props have small asymmetries and deformations.

Masking: normals, submesh size, and raytraced AO

InstaMAT 2026 extends its mask set with new workflows aimed at isolating geometry features without hand-selecting everything. The new Mesh Normal Mask can isolate parts of a mesh based on polygon normals and an angle tolerance. The workflow is click-based: click a region, and the mask selects surfaces with similar normal directions. Multiple chosen areas can be defined within a single mask, and tolerance can be adjusted per point. The mask is described as UV independent and stable across topology or UV changes.

The Mesh Submesh Mask can mask submeshes by size and distance, targeting scenes with many similarly sized objects where manual isolation is tedious. There is also a Mesh Ambient Occlusion Mask described as using raytracing to generate occlusion-based selections for isolating crevices, corners, and recessed areas.

Mesh filters and nodes: mirror, bevel normals, drips, and smoothing

A batch of mesh-oriented effects and nodes are listed as part of the 2026 update. Mesh Laplacian smoothing arrives as an option in the Mesh Smooth node, described as producing a more unified surface while better preserving mesh volume compared to traditional smoothing methods that can shrink geometry. The described use cases include cleaning scan data, removing photogrammetry noise, and refining sculpted details while preserving silhouette.

Mesh Mirror can mirror decals, masks, and entire layers, and it can be applied to a layer group to mirror complex effect and mask combinations.

Mesh Bake Bevel Normals is a node for beveling low poly asset edges using a GPU-accelerated bevel normals baker, with procedural masking for selecting which objects or edges to bevel. The behavior is described as procedural, so bevel placement remains correct if the input mesh topology or UVs change.

Mesh Directional Blur is presented as a way to create leak and drip effects by blurring in a specific direction in 3D space, keeping directionality consistent across the mesh surface regardless of UV layout or texture resolution. It includes distortion and falloff controls.

Additional mesh features listed include Mesh Solidify for solidification to prevent rendering artifacts, Mesh Sharpen for definition and detail clarity, and a Mesh Stylized Filter for non-photorealistic texturing options.

InstaMAT UI and workflow: less hunting, more painting

InstaMAT 2026 introduces a dedicated painting toolbar intended to centralise common controls. The toolbar provides quick access to brush and curve settings, including radius, flow, rotation, Lazy Stroke radius, symmetry, and curve-specific controls. It is described as dynamic, updating based on the active layer type so only relevant options are displayed.

There is also a dedicated brush rotation hotkey, described as Cmd or Ctrl+Shift with a left-mouse drag, to rotate the brush, aiming to reduce interruptions during stroke work.

Viewport and gizmo changes include planar translation gizmos for moving a mesh, effect, or mask along two axes at once, plus custom viewport wireframe settings for width and color, and a viewport shortcut overlay that displays hotkeys while painting, using curves, and using the paint projector.

Mesh import settings add options to configure mesh up axis and coordinate system handedness for asset texturing projects.

Integrations: Blender, Unreal, 3ds Max, Maya

The release notes list updates for several integration plugins tied to the latest https://docs.instamat.io/en/Products/InstaMAT_Studio release.

InstaMAT_for_UnrealEngine lists support for Unreal Engine 5.7.3, plus fixes for crashes when creating invalid graph instances, and fixes for broken materials and mesh orientations for Scene outputs. Library previews are added for Mesh-type Graphs and Graph Instances.

Blender integration notes include support for the latest Studio release, improved performance when setting mesh as a graph input, improved performance when resetting graph instance inputs, and fixes for plugin stalls when creating faulty graph instances. Library grid UX is adjusted with fixed cell width, and search results quality is described as improved.

3ds Max integration notes list support for the latest Studio release and a fix for the plugin getting stuck when creating faulty graph instances, plus window icons changed to match the main menu.

Maya integration notes list support for the latest Studio release, improved mesh-as-input performance, fixes for plugin stalls on faulty graph instances, and a fix for incorrect exported textures when using the export dialog window.

InstaMAT Licensing and pricing: what the numbers say

InstaMAT licensing is split across tiers with revenue or funding caps stated for some options. The Pioneer license is free and fully featured with commercial-use rights, with availability limited to individuals or businesses with annual revenue or total funding less than 100,000 US dollars, and it requires attribution.

The Indie license is available for individuals or businesses under 250,000 US dollars in annual revenue or total funding, with an option at 8 US dollars per month billed annually, and a perpetual Indie price shown at 489 US dollars. For Pro, the pricing page lists a Pro subscription shown at 36 US dollars per month billed annually, and a perpetual Pro license shown at 989 US dollars.

If you are evaluating the tool for a pipeline, test it against real assets, real render targets, and real deadlines before it touches a production branch. New tooling should earn trust with results, not promises.

Finally, keep an eye on how the new mesh filters slot into your existing material graph habits. Directional blur for drips in 3D space, procedural bevel normals, and AO-based masking can remove steps that otherwise happen in separate tools. If it holds up, it reduces context switching. If it does not, at least you learned it on a duplicate branch instead of the hero asset.

Also, do not skip the boring step: validate exports, naming conventions, and texture packing against your engine ingest rules before you fall in love with a shiny new brush. The most dangerous bug is the one that looks like a style choice until delivery day.

InstaMAT Test: Painting, Procedurals and Pasta

The post Abstract ships InstaMAT 2026 Curves Brushes first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

For those who don’t know the tool: tyFlow is a particle and simulation plugin for 3ds Max. It is commonly used for particle effects and procedural simulation within pipelines. The tool expands 3ds Max application simulation features with node-based operators and GPU-accelerated modules.

A CUDA fluid solver arrives

The 2.000 release of tyFlow introduces a new GPU fluid simulation solver named ZENITH. According to the official release notes, the solver runs on CUDA and integrates directly with the tyFlow simulation environment.

The update also introduces twenty new operators for the Inferno module. Inferno is tyFlow’s internal system for simulation tasks, including volumetric and fluid workflows. The release notes confirm that the operators are designed to support the new GPU fluid pipeline introduced with ZENITH.

CUDA modules distributed with tyFlow have also been updated. The package now includes machine learning models intended for fluid up-rez and compression. These models ship inside the CUDA module package together with a defined installation location described in the included documentation. The release raises the minimum supported CUDA version to 12.8. Users are instructed to ensure that GPU drivers are updated accordingly.

Updated CUDA modules

The updated CUDA modules are a central part of the release. The vendor states that the package now bundles machine learning models used for fluid up-rez and compression. Fluid upres workflows typically reconstruct higher resolution detail from a lower resolution simualtion. The release notes do not specify the training method, dataset, or inference process used by these models. No benchmarks or performance figures are provided.

The CUDA modules also now require installation in a specific location. Users are directed to the README documentation included with the CUDA module package for installation details. The vendor also updated the CUDA cub and thrust libraries used internally by tyFlow. According to the release notes, the update addresses rare CUDA crashes during Multifracture operations. (Multifracture is tyFlow’s system for procedural mesh fracturing used in destruction simulations.)

Twenty Inferno operators

The release introduces twenty new Inferno operators designed to work with the new GPU simulation capabilities. Inferno operators in tyFlow provide node based controls that modify simulation behaviour or generate simulation data. The addition of twenty operators suggests a significant expansion of the Inferno system.

New operators for general workflows

Outside the Inferno system, the release adds several new operators and modifiers for tyFlow workflows. A new Global operator has been added. The official documentation referenced in the release notes is required to understand its full functionality.

The update also introduces a MAXScript operator. MAXScript is the scripting language used inside 3ds Max. The operator presumably enables scripting access within tyFlow simulations, although the exact capabilities are not described in the release notes.

A new tyMeshBlend modifier has also been introduced. The modifier blends normals where meshes intersect. This behaviour is typically used to reduce shading artifacts where two meshes overlap or intersect.

Another addition is a new SDF shape mode for the PhysX Shape and PhysX Collision operators. SDF stands for signed distance field. According to the release notes, the new mode allows more accurate concave collisions.

Signed distance fields are commonly used to represent complex shapes in simulation because they encode the distance to the nearest surface point in volumetric form.

tyCache improvements

The release expands tyFlow’s caching capabilities. The tyCache modifier can now cache spline data. Previously, the system primarily cached particle and mesh data. The Export Particles operator now supports subframe export of tyCache data. Subframe data enables simulation playback at time steps smaller than a single frame. This is typically required for accurate motion blur in rendering workflows. The tyCache object also now displays PhysX bind connectivity.

Mesh and material improvements

Several modelling and mesh related updates are included in the release. The multifracture, tyBoolean and tyWeld modifiers now include UVW seam weld options. A new Merge mat IDs mode has been added to the tyMaterial modifier. The same option is also available for the tyMesher object. According to the release notes, the feature merges and concatenates material IDs across instanced objects and generates a compatible multi material with the new ID layout. This behaviour can simplify material management in procedural setups where multiple objects share or generate different ID sets.

UI and usability changes

The update includes multiple interface adjustments aimed at improving usability inside the tyFlow editor. Comboboxes, checkboxes and radio buttons now display non-default values in blue. Previously, this behaviour was limited to numeric spinner controls.

Large dropdown comboboxes now include a text entry field at the top of the list that allows users to search items using fuzzy matching. The release also introduces a Houdini-style value stepper dialog. Middle Mouse Clicking any spinner control opens a dialog that allows incremental changes across multiple orders of magnitude.

Export and procedural variation

The Export Particles operator now supports exporting ranges for tySwitcher indices and reseed values. According to the release notes, this allows permutations to be exported from the same operator during a single export operation. Exported object names and layers now also support symbol replacement variables such as $tySwitcherIndex and $tySeedIndex. These variables allow procedural naming during export operations.

OpenVDB update

The OpenVDB SDK used by tyFlow has been updated to version 13. OpenVDB is an open source library widely used in volumetric workflows. It provides sparse volumetric data structures for storing grids such as smoke, fire or fluid simulation volumes.

Practical implications

The most significant change in this release appears to be the introduction of the ZENITH CUDA fluid solver and the expansion of the Inferno operator set. However, the official release notes do not provide technical descriptions, performance data or architecture details for the solver. GPU fluid simulation inside particle frameworks can reduce iteration times when compared to CPU grid solvers. Whether this holds true for ZENITH cannot be determined yet – so it is time to have a good long playing session with Tyflow!

Users interested in adopting the new system will likely need to examine the updated CUDA modules and example scenes to evaluate real world behaviour. As always, new tools and innovations should be thoroughly tested before use in production.

// https://pro.tyflow.com/

The post tyFlow 2 adds CUDA fluid solver and 20 Infernos 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.

If you don’t know the tool: Sequoia is a Windows only high end DAW from Boris FX for mastering, broadcast and audio post. It focuses on object-based editing, precise routing and reliability rather than trend chasing.

Boris FX has released Sequoia 2026, marking the first major version since the DAW joined the company’s product portfolio. The update focuses on video playback, external control and performance reliability rather than new creative paradigms.

The release targets audio post production, mastering and broadcast environments where Sequoia is typically used alongside picture and external hardware systems. Boris FX describes the update as a consolidation release that combines visible workflow enhancements with under-the-hood engine improvements.

GPU-accelerated video, properly integrated

The most significant change in Sequoia 2026 is a new, fully GPU-accelerated video engine. Boris FX states that the engine supports NVIDIA, AMD and Intel GPUs and is designed to improve playback stability and responsiveness when working to picture.

The engine introduces native decoding for AVC, HEVC and AV1, and adds native Apple ProRes support without requiring external transcodes. Boris FX also states that the video engine provides full resolution monitoring without preview downscaling and supports frame rates up to 60 fps. These performance claims are vendor statements and not independently verified at press time.

The company positions the new video engine as a practical requirement for modern audio post-production, rather than a feature expansion, citing smoother playback and reduced friction when working with contemporary picture formats.

Audio engine refinements for dense sessions

Sequoia 2026 includes updates to its VST3 based audio engine. Boris FX states that multicore CPU distribution has been improved, with smarter allocation across cores and reduced processing load from high latency plugins and AUX sends.

The company also highlights strengthened engine testing and error handling, intended to improve playback reliability during complex mastering and mixing sessions. Additional changes include an updated plugin buffer dialog and overload and noise protection refinements.

A new one click export option allows users to bypass active effects chains during rendering, enabling clean reference exports without altering project setups. These changes are presented as safeguards for critical production and mastering work rather than new functionality.

OSC support and external control

Sequoia 2026 adds native support for OSC, Open Sound Control, enabling remote triggering of recording, editing, mixing and transport functions over a network. Boris FX explicitly references use with broadcast consoles, large format desks, StreamDeck devices and OSC capable applications. The feature is aimed at multi room studios and facilities where DAW control is distributed across operators or locations.

The available documentation does not specify command coverage, mapping depth or latency characteristics. But there is an OSC monitor to check outgoing and incoming strings, and you can use the search field to display the menu ID. The program help contains some examples and suggestions. Facilities planning to rely on OSC control should verify behaviour against their specific hardware and network setups.

Soundly integration inside Sequoia

The release integrates the Soundly cloud-based sound effects library directly into Sequoia. Users can browse, search and preview sounds from within the application and transfer assets directly into projects. According to Boris FX, the library includes thousands of sound effects, Foley recordings, atmospheres and field recordings at multiple sample rates. Organisational features include tagging, favourites and custom libraries.

Routing and fades, incrementally improved

Sequoia 2026 introduces an enhanced FX IO Matrix. The updated matrix allows more detailed multichannel routing through plugins, including channel remapping, side chain setups and a Thru mode for distributing mono or stereo effects across surround and immersive buses.

The Crossfade Editor has also been revised. Boris FX describes improved visual context, quicker access to fade shapes via object handles, real time preview of fade curves and looped auditioning without interrupting playback. These changes are aimed at dialogue, classical music and broadcast editing workflows where precision matters. The underlying object based editing model remains unchanged.

Official onboarding and training material

Alongside the release, Boris FX has published an official introductory walkthrough video. The material focuses on interface navigation and foundational workflows rather than documenting new 2026 features. The walkthrough covers the Arranger, object-based editing, the Object Editor, track-based workflows using the Track Editor and Mixer, VST instrument handling, ASIO driver configuration, project creation, recording and export. It is positioned as an entry point for new users and a refresher for existing ones.

Pricing and availability

Sequoia 2026 is available immediately. It remains a standalone DAW offered via subscription, perpetual licence and upgrade and support plans. Pricing starts at 595 US dollars per year or 95 US dollars per month, according to Boris FX. Customers with an active Sequoia or Boris FX Suite subscription, or a current Sequoia upgrade and support plan, receive the 2026 release as part of their existing entitlement. As always, new releases should be tested carefully before use in real production and mastering environments without assumptions.

The post Sequoia 2026 gives audio post a video engine first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t now the tool: HydroFX is a standalone GPU-based FLIP liquid simulator from Storm VFX, designed to generate water simulations for downstream use in DCC tools via Alembic, USD and OpenVDB. It does not render, shade or composite anything itself, and it does not try to be clever about it.

A standalone solver, not a Swiss army knife

Storm VFX has released Storm HydroFX 1.0, a commercial version of its GPU-based FLIP fluid simulator previously available in beta form. The software is positioned as a focused standalone application for liquid simulation, rather than a general-purpose dynamics system or a host-integrated plugin.

HydroFX implements a custom FLIP solver designed specifically to run on NVIDIA GPUs using CUDA. The solver runs entirely on the GPU, with the stated aim of providing faster iteration times compared to CPU-based fluid solvers. This performance claim is made by the developer and is not independently verified at press time. HydroFX runs on Windows only. No macOS or Linux versions are listed on the official site or the commercial product page at the time of writing.

Import, simulate, export, repeat

HydroFX is intended to sit between layout and lighting in a conventional VFX pipeline. Users import static geometry in Alembic or OBJ format, which can act as emitters, colliders or force drivers. Simulation parameters are adjusted directly through a node-free interface that mirrors the design language of Storm VFX’s main Storm application.

Simulation output can be exported as particle caches in Alembic, USD or PRT formats. Storm HydroFX 1.0 also supports exporting liquid surface meshes, allowing the simulated water to be rendered in external DCC applications or real-time engines. OpenVDB output is available for preview surfacing and volumetric workflows. Cache sizes for playblasts / preview can be reduced by exporting only surface particles rather than full particle sets. .

Whitewater, foam and other small things that float

HydroFX 1.0 includes built-in systems for foam, bubbles and spray, collectively described as whitewater. Whitewater can be simulated as part of the main solve or as a separate system, and can be exported independently from the main liquid body. Storm VFX describes improvements to whitewater behaviour and stability compared to the beta versions.

The solver is explicitly positioned as an offline simulation tool. There is no claim of real-time playback, interactive editing or on-the-fly meshing, and none should be inferred.

Pricing and licensing

Storm HydroFX is sold via Gumroad under annual subscription licences. The base (Indie) Storm HydroFX licence is priced at €145 per year. A Storm HydroFX Studio licence is priced at €249 per year, with multiple seat options selectable during purchase. Exact seat counts and per-seat pricing for the Studio tier are not listed as fixed values and must be configured on the Gumroad page.

Licences are activated online. The Gumroad listing specifies a seven-day money-back guarantee. HydroFX is distributed as a downloadable standalone application rather than an installer-based package.

Hardware and compatibility limits

HydroFX requires an NVIDIA GPU and uses CUDA. No support for non-NVIDIA GPUs is listed. The software currently runs only on Windows. These limitations are explicitly stated by the developer and should be considered non-negotiable at this stage. While HydroFX does not provide host-specific plugins, its reliance on standard interchange formats allows it to be integrated into pipelines built around tools such as Blender, Maya, 3ds Max, Houdini or Unreal Engine. Storm VFX does not provide official integration tools or presets for any of these hosts.

Production reality check

Storm HydroFX 1.0 is a narrowly scoped tool that does one job and avoids pretending otherwise. It does not replace broader simulation frameworks and it does not attempt to manage rendering, shading or scene assembly. For teams already comfortable moving caches between applications, this may be a feature rather than a limitation.

As with any newly released simulation software, artists and technical directors should test HydroFX thoroughly on representative shots and hardware before committing it to production use. New tools and innovations should always be validated in controlled conditions before being deployed on actual client work.

Link Citation Block

// Storm HydroFX product page
// https://stormvfx.gumroad.com/l/hydrofx

// Storm VFX official website
// https://storm-vfx.com

The post Storm HydroFX ships water without the node graph first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Theory Accelerated is the independent R&D studio of former ILM and Naughty Dog technical director Matt Puchala. Known for Axiom, a GPU-based volumetric solver for Houdini, the studio builds specialised simulation tools aimed at faster, artist-friendly workflows for VFX and cinematics. Paradigm extends this approach from smoke and fire into liquid dynamics.

Theory Accelerated has released Paradigm, a new GPU-accelerated sparse liquid solver for Houdini. The software, currently in open beta, aims to provide a faster alternative to Houdini’s native CPU-bound FLIP solver. According to Theory Accelerated, Paradigm can simulate millions of particles “in a fraction of the time a CPU would take”.

Like its sibling tool Axiom, Paradigm is designed to handle simulations across scales—from small splash tanks to large-scale water scenes. The solver runs entirely on the GPU through OpenCL, making it hardware-agnostic and compatible with GPUs from AMD, Intel, and NVIDIA, as well as Apple Silicon.

Built on the same tech as Axiom

Paradigm shares its underlying sparse-simulation architecture with Axiom, Theory Accelerated’s established GPU-based volumetric solver. Development of the two products is intertwined; improvements made during Paradigm’s creation reportedly led to better collision detection in Axiom 4.0. Despite the shared lineage, Paradigm and Axiom are separate tools, and there is currently no two-way coupling between liquid and volume simulations.

Simple setup, Houdini-native workflow

Paradigm integrates directly into Houdini and is structured around a compact node set—just four nodes are required to set up a basic splash tank. Its interface closely resembles Axiom’s, offering familiar workflows for existing users. Artists can use source shapes as emitters, colliders, or custom forces.

According to the developer, the goal is to make iteration as fast as possible. Paradigm’s GPU core enables quick previewing of surface tension, viscositiy, and adhesion effects, helping artists evaluate sims without long cache times.

Still missing whitewater, but it’s coming

As of the current beta, Paradigm supports small- and medium-scale liquid simulations but lacks several production-level features. Whitewater simulation and full support for Houdini’s ocean spectra are not yet implemented. Upcoming updates are expected to add colour sourcing, temperature-driven behaviour, viscosity attributes, and support for narrow-band simulation. Matt Puchala describes the current build as “highly unoptimised”, but plans to bring Paradigm to “the same level of polish that Axiom has”.

Free to test until February 2026

The open beta is free to download for all users until the end of February 2026c (See the FAQ for details). After that, Paradigm will move to a commercial model “similar to Axiom”, offering both perpetual node-locked and floating licences. The software runs on Houdini 20.0+ across Windows, Linux, and macOS, and requires an OpenCL 3.0-compatible GPU. The documentation includes setup examples and sample projects. Installation requires creating a free Theory Accelerated account.

Early verdict: promising, but still maturing

While Paradigm’s GPU acceleration promises a major speed boost for Houdini-based liquid simulations, it is still in beta. Key production features, such as whitewater and advanced ocean interaction, are not yet ready, and the solver is described as unoptimised. For now, Paradigm is best used for testing and experimentation rather than critical production work. As always, new solvers should be tested on controlled scenes before deplorment in a production. And we’ll check out the next builds to keep you in the loop when it is worth your precious GPU-cycles!

The post Liquid Thinking: Paradigm Brings GPU Speed to Houdini first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

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.

For those who don’t know the tool: Cinebench by Maxon has long been the go-to CPU and GPU benchmark for 3D professionals. It’s based on the Redshift rendering engine that powers Cinema 4D, and its scores have quietly dictated workstation builds across postproduction, VFX, and colour suites for years.

Updated guts for a new generation

Maxon’s official release confirms that Cinebench 2026 has been rebuilt around the latest Redshift core, mirroring the renderer inside Cinema 4D 2026. The test scenes and compiler base have been modernised to reflect current rendering workloads. As a result, scores from Cinebench 2026 are not comparable with those from Cinebench 2024 or earlier. Cinebench 2026 runs natively on Windows x86-64, Windows ARM64, and macOS. It remains free to download from Maxon’s website.

GPU support: Blackwell, Hopper, and Apple M5

The new benchmark now fully supports Nvidia’s Blackwell-series GPUs, including GeForce 5000 and Hopper cards, and AMD’s Radeon 9000 series. For Mac users, Cinebench 2026 is compatible with Apple M4 and M5 chips, using Apple’s unified memory architecture. Intel GPUs remain unsupported, according to Maxon’s documentation. GPU tests require at least 8 GB of VRAM (or 16 GB of unified memory on Apple Silicon), and the CPU tests scale with available system memory.

New SMT test: threading laid bare

A new SMT (Simultaneous Multithreading) test isolates logical-thread performance, showing how modern CPUs handle parallel workloads. This separates Cinebench 2026 from prior versions, which measured only total core performance. The result gives a clearer view of per-thread efficiency, especially relevant for render nodes and multi-core workstation CPUs.

Real-world alignment with Redshift

Maxon emphasises that Cinebench 2026 now uses the same Redshift code as Cinema 4D’s production renderer, making the benchmark a closer reflection of actual 3D rendering performance. This move should reduce the gap between synthetic test scores and real-world frame render times inside DCC applications.

That said, as always, benchmark results should be validated in actual production environments before being used for purchase or deployment decisions.

Availability and notes for cautious studios

Cinebench 2026 is available now, free of charge, from Maxon’s official site. The installer covers Windows 10/11 (x86-64 and ARM64) and macOS 14.7 or newer. While the tool’s interface remains largely unchanged, the new test scenes and threading evaluation mean you’ll need fresh baselines for every workstation in your pipeline. Studios that have not updated since Cinebench R23 or 2024 will find their old score sheets effectively obsolete.

Given the tight budgets and cautious upgrade cycles across post and VFX, this update serves both as a wake-up call and as free therapy for outdated benchmarking habits. Social media: Cinebench 2026 drops with GPU and SMT upgrades. Time to see if your workstation’s still earning its power bill.

Fact check reminder: Test new benchmarks on your own hardware before using results to guide workstation or render-node purchases.

The post Cinebench 2026: Benchmark therapy first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Chaos builds V-Ray, a production renderer used across architecture, VFX, and animation. It plugs into DCCs such as Blender, Maya, 3ds Max, and Houdini, offering physically-based rendering and global illumination with CPU and GPU engines. Chaos also runs the Chaos Cosmos asset library and Chaos Cloud, tying rendering and collaboration together inside a single ecosystem.

macOS joins the party

After years of waiting, V-Ray for Blender now runs natively on macOS 11.0 and newer with full speed and feature parity. The renderer matches its Windows 10/11 counterpart, finally letting Mac-based studios use the same shading, lighting, and AI toolchain without workarounds. Update 2 also supports Blender 5.0, maintaining full compatibility with current scene formats and node systems. Official release notes confirm the update as part of V-Ray 7, Update 2, dated 10 December 2025. (Chaos Docs)

AI tools: less grind, more render

Three new AI-assisted tools headline the release. The AI Enhancer adds small-scale realism to background elements, without re-rendering. It can target specific objects, such as fabric or foliage, and integrates directly into the V-Ray Frame Buffer with Chaos Cloud Collaboration support.

The AI Material Generator, linked with Chaos Cosmos, turns a single surface photo into a fully mapped PBR (physically-based rendering) material, complete with diffuse, normal, and roughness maps. Ideal for populating environments with believable secondary materials when deadlines bite.

The AI Upscaler handles resolution boosts from HD to 4K (or even 16K) without full re-rendering. Integrated through Chaos Cloud, it enhances textures and micro-details while preserving lighting accuracy. All three AI tools are confirmed by Chaos as part of the official release, but remain beta features; large sequence processing may require manual setup.

Distributed Rendering v2: the network works harder

Update 2 introduces Distributed Rendering v2 (DR2), replacing the previous network system with a new Dispatcher component. It coordinates tasks more efficiently across multiple nodes and can be configured directly inside Blender’s V-Ray render settings. Performance tests from Chaos show improved load distribution and better handling of dynamic geometry, particularly when mixing CPU and GPU render devices.

Returning heroes: V-Ray Fur, Cosmos, and UI clean-ups

Procedural hair, grass, and carpets return through V-Ray Fur, with improved instancing performance and cleaner parameter layouts. Combined with AI Enhancer and Upscaler, it can produce complex natural scenes faster than previous builds. The V-Ray Frame Buffer gains new Filter Presets, better Caustics control, and links from every property panel to online documentation. Chaos also refined the GPU Device Selection list and improved the layout of several texture nodes, fixing cluttered parameter groups that previously slowed down look-dev work. Interactive rendering performance has been significantly improved, and dynamic geometry, such as proxies or scattered meshes, now updates more reliably.

Modified and extended features

According to the official changelog, several internal systems were reworked. The User Color node now supports colour attributes; the Normal Map node introduces resolution-independent bump mapping; and a new Include/Exclude list allows finer control when the Render Mask Type is set to Objects. The renderer also supports USD scene loading and renders Cycles’ Translucent BSDF correctly after conversion. Users can drag-and-drop bitmaps directly into the node editor and parent the V-Ray Frame Buffer window to Blender’s main interface—small but welcome quality-of-life changes.

Quality-of-life fixes galore

The official documentation lists over forty bug fixes. Highlights include:

Viewport freezes when starting interactive rendering without a valid license are resolved.
Depth-of-field now updates correctly in both viewport and production renders.
Chaos Cloud exports .EXR sequences properly even when output paths are missing.
Cosmos asset import errors in non-English file paths are fixed.
Motion blur again works with multiple cameras and V-Ray Proxy objects.
Proxy scaling, negative transforms, and instancing via Collection Info nodes now behave as expected.
The Viewport Denoiser correctly applies to worlds with node trees.

In addition, interactive rendering no longer stops responding when node connections change mid-render—a long-standing production annoyance.

Update 1 recap

For those catching up, Update 1 (mid-2025) added V-Ray Scanned Materials for physically measured shaders, Cycles-to-V-Ray material conversion, and a redesigned Material UI. Those features remain available in Update 2, with improved node naming after Cosmos imports and smoother drag-and-drop creation of bitmaps.

Mac performance and GPU tweaks

The update includes GPU engine changes: removal of Subdivs parameters for certain settings, adjusted light-intensity limits based on units, and performance improvements for interactive GPU sessions. Dynamic geometry loading has been optimised, reducing stutter during viewport updates.

Ecosystem position

Inside Chaos’s wider portfolio, this release tightens integration between Blender and Chaos Cloud, bringing Blender artists closer to the workflows long available in V-Ray for Maya or 3ds Max. Combined with the Dispatcher system and AI tools, Chaos is clearly aligning all DCC integrations under a shared cloud and material ecosystem.

Pricing and availability

V-Ray for Blender Update 2 is available now for Windows 10/11 and macOS 11.0 or newer. Licences can be purchased as a Blender-only subscription or included in any V-Ray Collection. Educational licences remain discounted. Pricing details are listed on the Chaos V-Ray for Blender page.

Reality check

As always, test new builds before production deployment. AI features and distributed rendering changes should be validated in-house for consistency across render nodes, especially in animation pipelines or asset-heavy scenes.

The post Chaos Adds macOS & AI to V-Ray for Blender first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

A tasting of the dynamics and geometrys side (of) effects

This release is not about the number of features, but about finishing what was started, achieving true production readiness, robustness, performance, and ease of use. It’s a version focused on quality of life. Feature sets like MPM simulations and Karma have matured like a good wine. The machine learning tools respect the artist’s skill set and have left their state of play are actual usefull in production.

Even though SideFX remains modest in its official statements, Houdini 21 is a massive release. For the feature-hungry among us, the highlights include a fully matured APEX; a refined and clever animation and rigging framework; a simulating Copernicus (think Substance on Dope), and in the VFX realm, the production-ready MPM Solver. On top of that, we’re seeing machine learning tools popping up in all the right places (AI for people who don’t expect a Pixar film from a single click), faster and expanded rendering with Karma, and a healthy dose of quality-of-life improvements.

Since our editorial cat can only count to 300, we can’t tell you the exact number of new or improved features, but we’re impressed nonetheless. And soon, you will be too. To avoid overwhelming both writer and reader, we’re breaking this article into a mini-series. We’ll start with VFX & Geometry, followed by Solaris & Karma, Copernicus & Terrain, and the massive Animation & Rigging tools.

MPM

One of the most exciting additions in H20.5 was without question the MPM Solver. The MaterialPointMethod truly allows you to simulate a wide range of different materials. From water, snow, and sand to honey, metal, and concrete, all within a single Solver setup. The geometry is simply substituted by points or particles, which are then simulated. The different materials interact physically accurate and constraint-free, purely based on their assigned parameters.

The initial release was already impressive, but it left users standing somewhat in the simulated rain when asking: “How do I get a proper mesh with UVs?” That exact issue has now been beautifully solved in H21. Any MPM simulation, whether rigid body or fluid, can now be meshed (as polygons or SDF volumes), including UVs, color, and other attributes, using no more than two nodes.

A nice and usefull addition to this workflow is the MPM Debris node, which generates new points along fracture lines as sources for smoke, dirt, or secondary debris effects. So let’s take a look at meshing hard and fluid or granular surfaces across a few setups and scenarios and wrap things up with a creamed cookies drink while watching the official and very excellent MPM demo.

Surfacing MPM Simulations

Testing time! For this test setup, we’ll have a clay ball smash into a vase model, paying close attention to UV transfer and the generation of smaller fragments through the Debris Source. The easiest way to start an MPM simulation is by typing “MPM Configure” into the node search. This gives you a complete set of starter nodes right away. (Under MPM Configure, you’ll also find plenty of additional example setups for study or creative repurposing.) By the way, the MPM container on the far right controls the overall resolution of the entire simulation.

We replace the default sphere with our own model and can now assign materials directly inside the mpmSource node and tweak them to our liking. It’s genuinely fun. Feels a bit like a mini-game. Since a concrete material would be more realistic but also quite boring as a vase material, we went with Chunky Snow instead. The environment comes in via an Object Merge directly into the mpmCollider Sop, ready to go. Our clay ball, the antagonist of this little simulation, isn’t a collider per definition but another mpmSource ready to be smashed, merged with the vase and given its own material behavior, Chunk Soil.

To make sure the particles can actually see and “love” each other, we need to enable Particle-Level Collision in the solver. The new Auto Sleep feature helps keep the vase passive until the collision happens, preventing it from collapsing at frame one and saving quite a bit of compute time.

Since the clay ball will be meshed as a fluid and granular surface and the vase as a rigid object, we first separate the MPM particles using a Blast node, filtering them by their respective source names.

For surfacing the vase, we use the mpmPostFracture node, which takes the rest-geometry and the MPM particles as input. This node essentially breaks the geometry apart “end to start,” so it needs to be fed the final frame of the simulation. After that, we choose either Voronoi or Boolean Cut as the fracture method. The latter can generate interior details, subtle irregularities on the inner faces of the fracture, that weren’t visible before, and it’s also faster to compute. We can further control the number of pieces as well as define the minimum fragment size at which new pieces should be generated.

The final node in the chain is mpmDeformPieces, which transfers the newly generated fracture geometry onto the MPM particles and just like that, the vase shards, physically convinced they’re made of snow, go flying through the scene, complete with perfectly intact UVs. For more of a muddy mess, we could have generated a liquid or granular surface instead, but we’ll save that for the clay ball. The result from the Debris Source, which lets you precisely define when and where particles based on fracture are emitted, is then passed into a POP network, including collisions from the vase and background).

Time to get serious:

Continuos Emissions & Surface Tension

With this new option, you can quickly fill containers, simulate expanding materials, or layer different materials on top of each other. The option is located in the mpmource node and spreads new particles apart using positive pressure.

Let’s take our vase and let a thick, viscous something ooze out of it. A good chance to show how simple MPM can be: if we want things to float inside the fluid, they just need a lower density. A few cubes are generated and assigned a jelly material. Two geometries, two MPM Sources, merged and fed into the solver. That’s all it takes. Just as easily, you can mix different fluids within the same setup. And for a bit more drama, we can dive into the solver and add a POP Wind node with some turbulence.

Surface tension allows for realistic effects such as droplets, tendrils, and flowing water. H21 introduces two new ways to control surface tension for both liquid and viscous materials inside the MPM Solver. The Point Based method offers higher accuracy and stability, making it ideal for small and detailed simulations. The Grid Based method, on the other hand, is optimized for performance and handles millions of particles more efficiently, which makes it better suited for large-scale scenes. External forces and friction can be increased if objects keep moving when they shouldn’t. Otherwise, you might end up with a scene straight out of Terminator 2.

To achieve high levels of detail without an unnecessarily large number of simulation points, the new, more precise collision detection allows you to use the fracture edges of a simulation as the source for a targeted secondary simulation. The attribute Jp (Plastic Compression/Stretching) is key here. It can be used to isolate the fractured areas and feed them into a Surfacing node set to VDB mode. This resulting volume can then serve as the source for the second simulation. And don’t forget to use the main simulation result as a collider.

And finally to top it off, the official demo. A detailed breakdown of that beautiful cookie shot.

Machine Learning in Dynamics

You won’t find any generative AI native in Houdini, but rather a growing collection of smart, locally running models, often trained by yourself, designed to simplify or speed up time-consuming tasks.

Surfacing Flip, Vellum & Particle Simulations

Alongside Neural Point Surfacing for MPM, the new Neural Point Surface and proven Particle Fluid Surface nodes now bring neural meshing to FLIP, Vellum, and POP simulations as well. Until now a bunch of points are trying to reconstruct the surface of a material. With neural meshing, you can now achieve much sharper, more detailed surfaces across a both high and low frequencies. The result: surfaces that are no longer uniformly fuzzy, but crisp, structured, and temporally stable. As before, you can train your own models, but even the included presets already produce finer details. And thankfully, the whole thing is GPU-accelerated.

Volume Upres

The core problem behind volume up-resing: for efficiency, artists often create and approve low-resolution simulations. But once the voxeldensity is increased, the overall shape of the sim tends to change. With the new tools, a low-res simulation can now be upscaled while preserving its exact shape. This not only keeps previously approved versions intact, but also allows for far more iterations. A model that’s been trained on a specific motion or behavior can now upscale multiple variations of it.

The Billowy Smoke recipe (or shelf tool) comes with a pretrained up-res model already integrated. Let’s start by looking at a comparison between the low-res input simulation and the 3× up-res result.

Details are nicely added, while the overall shape is preserved impressively well. Caching took a bit of time, but it’s still far faster than running a full high-res simulation. The real idea, however, is that we can now reuse this up-res model for all our future Billowy Smoke setups and honestly, we probably should. So, let’s quickly modify the setup and see if we can break the upscaler.

This time, the solver runs at a voxel size of 0.05, using the 2× upscaler. The 3× model didn’t really add more detail, just extra waiting time. For a bit more fun, a Gas Wind with random direction and a collision shape were added. That collision shape, as it turns out, gives the upscaler a bit of trouble as seen below.

But when comparing the up-res result to a true high-res sim, it’s clear that the system is really good at preserving the base form. Doubling the voxel size in the high-res sim, on the other hand, changes the overall shape and eats up a ton of time but stays artifact-free. Or, if you really want perfection, you could just train a model specifically for this type of collision.

If you want to train your own model, this Equinox Hive talk walks you through every detail:

Zibra AI VDB compression

With this plugin you can save up to 99 percent of storage space when caching VDB simulations, which makes it perfectly suited for use in real-time engines such as Unreal Engine 5. The Zibra toolset, distributed via SideFX Labs, provides three dedicated nodes.

The first, zibravdb_compress, writes and exports .zibravdb files for use in Unreal and similar environments. The second, zibravdb_decompress, brings those files back into Houdini. And finally, zibravdb_filecache acts as a modified File Cache node that automatically handles compression, loading, and decompression for further use inside Houdini. Before diving in, you’ll need to download the model and obtain a license, potentially a free personal one if your revenue is below 100 K USD. The license management can be accessed directly from any of the three nodes.

For a quick benchmark, I used the Fireball Recipe and cached one regular VDB sequence alongside two Zibra versions with different quality settings. The original VDB sequence weighed 294 MB. The Zibra compression at a quality setting of 0.2 came in at only 5 MB, roughly 98 percent smaller. At a quality setting of 0.9, the result visually matched the original VDB almost perfectly while staying at just 36 MB, around 88 percent less.
That insane low file size at 0.2 naturally comes at the cost of lost detail, as visible in the comparison graph below. Still, the results are impressive and they open up the possibility for bringing volumetric simulations into real-time pipelines far more efficiently than before.

Pyro Shelve Tool Presets

Another way to get artists up to speed faster are production-ready presets, not just educational examples, but tools meant to be customized for your very real projects. Each of them comes with a ready-to-use Solaris network, fully set up for rendering straight out of the box. Even better, the Help section now includes a short guide and exploanation of important Nodes for every preset.

SideFX strikes a noticeably new tone here, aiming to flatten the learning curve rather than overwhelming newcomers with endless options (which, to be fair, they still do from time to time). These guides can be found under Documentation → What’s New → Pyro. In this section, we’ll take a closer look at three fundamentally different presets, each showcasing its own approach and creative use case.

Stylized Flame

With the refined Copernicus toolset, entirely new worlds open up: stylized fire based on a classic Pyro simulation, right inside Houdini. And if needed, even live-rendered in Solaris.

To put the claim of “easy adaptability” to the test, we took the Pyro Fireball preset and gave it a Toon-style makeover. Adding the VDB field “Flame” inside the solver’s output was all it took to make it work. The output from the Cop node, by the way, can be merged directly into the scene for further Houdini style editing.

Ground Explosion B

This shelf tool sets up a sparse pyro simulation featuring a large-scale explosion, smoke trails, and a shockwave. For more control and efficiency, it’s actually made up of two separate simulations, layered on top of each other and interacting through their velocity fields.

Candle Flame

A candle flame might not be the most exciting thing visually, but it’s one of those Pyro results you end up needing again and again. What makes this preset interesting, though, is the procedurally modeled candle that comes with it. Exploring that setup is almost more fun than the Pyro sim itself.

Thruster FX

In true H21 fashion and in the spirit of overall efficiency boosts, the new Thruster FX tool makes its debut: a setup designed to create engine and propulsion emissions with ease. It’s not just a new node, but rather a complete Recipe, a preconfigured network of nodes that some might, in hushed tones, simply call “presets.”

With a cheerful click on Thruster Exhaust in the Pyro Shelf Tools (or via Configure Thruster in the Tab menu), you’ll get a fully adaptable node tree, including a ready-to-render Solaris network. The effect itself isn’t a simulation but a cleverly layered, art-directable procedural system built around VOP Nodes. Multiple pyrothrusterexhaust nodes are stacked in layers, each responsible for different components like sparks, fire, and plasma. All working together to form a surprisingly easy to use thruster system.

So, what does it actually look like? And can it really be used straight out of the box, as promised? The short answer: pretty much, yes. The rendering comes surprisingly close to the viewport preview. To get it running, only a few connections inside the included Solaris network needed to be adjusted. For our small test scene, we did a bit of kitbashing inside Solaris, then added some glow and polish in Fusion.

Let’s take a closer look at the node, both from the outside and under the hood. The node expects a primitive as input, and a simple circle usually does the trick. It outputs both particles and a volume containing density and temperature fields. In the General tab, you can control speed, length, and the overall shape via a spline ramp. The Exhaust section handles the color ramp and lets you tweak the underlying noise pattern, which has a strong impact on the overall form. Under the hood, the node generates a VDB from Polygon, then modifies the result with a Volume VOP and a Volume Adjust Fog node.

As part of the ongoing effort to simplify things and lower the learning curve, SideFX has also released a good and detailed tutorial mini series: sidefx.com/tutorials/how-to-create-thruster-fx

Car Destruction FX

So that we can also crash the rigs built with the Car Rig SOP introduced in H20.5, Houdini 21 brings us the new Car Destruction Tools, led by the mighty RBD Car Fracture SOP, supported by the RBD Car Transform SOP. The first one takes care of fracturing and constraint creation, automatically handling the typical materials you’d expect in a vehicle: glass, metal, wood, and rubber. The RBD Car Transform SOP, similar to Transform Pieces, ensures that all pre-fractured parts are efficiently transformed based on the simulation points. You’re not limited to cars, by the way. Anything that follows the same basic logic can be blown apart. From motorcycles to helicopters, it all breaks just fine.

Destruction-hungry artists will find a detailed yet easy-to-follow example scene in the SideFX Content Library, the same visuals you might recognize from the keynote: sidefx.com/carbd-dual-car-collision/. A fitting go-through video can be found here:

Geometry, Viewport and other tasty QoL

Coming from its deep VFX roots, Houdini has taken quite a journey to establish its own distinct style of procedural modeling. With H21, that journey continues, extending existing nodes and adding a few genuinely useful new ones along the way. This time, even the viewport got some well-deserved love, now powered by Vulkan and capable of loading Gaussian Splats directly.

Sculpting in Time

The Sculpt SOP, introduced in H20.5 and (surprisingly) quite useful, now gets a genuinely groundbreaking new feature called Shot Sculpting allowing time-based, keyframe-free sculpting. Originally intended as a correction tool for character animation, the node turns out to be just as handy for VFX and motion design work.

Temporal control is handled through the Shot Sculpt panel, which at first glance looks a lot like an NLE timeline and, in principle, works much the same way. Sculpting can be organized into layers that can be offset in time, faded in and out (complete with easing), muted, or adjusted in opacity. Alternatively, you can use mask_track to paint time-based attributes, which can then be passed downstream and used in other nodes, for an obvious example, as masks.

Otherwise, the same rules apply as for the regular Sculpt SOP, whose updates we’ll take a look at next. In line with the new Shot Sculpting feature, the mask system has been reworked. Masks can still be painted manually, but can now also be loaded from an upstream float attribute, saved permanently, and blurred or sharpened as needed.

There are also new brushes. My personal highlight, the Elastic Grab brush:

Of course, the complexity and depth of ZBrush remain unmatched, but for many tasks, artists can now comfortably stay right inside Houdini.

Geometry Masks

There are also updates when it comes to masking. Several well-known nodes now include a Mask parameter, allowing the effect to be restricted to a painted or procedurally generated mask. Among them: Peak SOP, Soft Peak SOP, Inflate SOP, Flatten SOP, and Point Jitter SOP.

UV Flatten from Points

The latest addition to Houdini’s already powerful UV toolset could just as well be called “UV from Voronoi” since that’s exactly what it’s based on. The node distributes random or precisely placed points across the surface and uses them to calculate clean, non-overlapping UVs. It’s primarily designed for complex, high-resolution meshes, where traditional unwrapping tends to get messy fast.

Vulkan Viewport

Now enabled by default, the new Vulkan 3D viewport offers noticeably improved lighting, Ambient Occlusion, shading and ray tracing with built-in denoising, and a more accurate texture display though performance can take a hit if you push it too far. New worklights including a fully adjustable Dome Light, Physical Sky, and Three-Point Light setup now serve as the default viewport lighting.

Looking toward the future, the viewport can now display Gaussian Splats directly. Since splats are essentially just point clouds, and Houdini is fundamentally point-based, this opens up a rather promising combination. The .ply file can simply be loaded via a File SOP and passed into a Bake Splat SOP for further processing. From there, you can treat and manipulate the splats just like any other geometry using the usual SOP tools. More on rendering those Splats in the upcoming section on Solaris & Karma.

Curve Tools

The new Extract Contours SOP can generate object outlines from a camera’s perspective either directly as edges or as an edge group. Quite handy for toon-style effects.

The well-known Curve SOP now allows you to interactively split points into branches (with unique vertex numbers) or fuse them back together.

Unsubdivide

If things ever get a bit too much, this node can reconstruct a low-res input geometry based on Catmull-Clark.

Conclusion after some bottles of VFX

Even though the stated (and achieved) goal of H21 was mainly polishing existing systems and adding plenty of quality-of-life improvements, it still manages to sneak in a massive load of new features along the way. And we’ve only scratched the surface here. Deep dives on Copernicus, Solaris, Karma, Rigging, and Animation are already in the works.

What’s also refreshing is the ongoing effort to flatten the learning curve through better documentation, tons of in-house tutorials, and solid example files in the Content Library. Many things have become easier or let’s say, more accessible, without losing depth, at least for those who want to go there. As always, most nodes can still be cracked open and modified at their core. Nice one, SideFX.

The post Houdini 21: Like good wine (Part1, VFX & Geo) first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

Beeble AI has announced version 3.0 of its model SwitchLight, described as “the best Video-to-PBR model in the world”. The tool converts video footage into physically based rendering (PBR) passes suitable for VFX and relighting workflows.

Key improvements

According to Beeble’s official release, the model is now a true video model: it processes multiple frames simultaneously rather than treating each frame individually and applying a post-deflicker step. This approach is said to produce smoother, more stable temporal results in moving footage.

Beeble also claims that SwitchLight 3.0 has been trained on a dataset ten times larger than that of the previous version. The company states this broader dataset captures a wider range of lighting conditions, materials, and environments, yielding more realistic results.

The desktop application, Beeble Studio, now supports 4 K resolution input, 16-bit EXR output, and local GPU processing for video up to one hour in length. The cloud-based version has been upgraded to SwitchLight 3.0 as well, with no price increase for existing users.

The release further highlights improved preservation of fine surface detail, such as facial wrinkles, hair strands, and fabric texture. The update also claims to correct several artefacts present in earlier versions, including the green-tinted normals sometimes seen on top of subjects’ heads.

Workflow and platform details

Beeble confirms that all footage processed through its cloud application now uses the new model automatically, without additional user input. For the local version, Beeble Studio, the software downloads and activates the updated model upon launch. No changes to pricing or subscription structure are mentioned.

What is not yet clear or independently verified

Beeble’s claims of “the best Video-to-PBR model” and “unmatched quality” remain vendor statements; no third-party benchmarks or peer-reviewed tests have been published. Hardware specifications for the local GPU workflow, including minimum VRAM and platform compatibility beyond Windows, are not detailed in the announcement. However, as with any new AI-driven tool, studios should conduct thorough in-pipeline testing before adoption. Verification under real-world production conditions remains essential to ensure consistency and compatibility with existing workflows.

The post Beeble launches SwitchLight 3.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.