For those who don’t know the tool: Fusion Studio is a node-based compositor for VFX and motion graphics, living next to DaVinci Resolve and sharing its licensing universe, minus the timeline politics.

Motion graphics gets a bigger toolbox

Fusion Studio 21 adds support for Krokodove motion graphics effects, plus over 70 new motion graphics effects and tools. A new Macro Editor arrives with an inspector view and publishing to macros, aimed at making reusable tool setups less of a scavenger hunt.

Text tools also pick up practical upgrades. Text+ and MultiText add spell checking. Font handling expands with emoji and color fonts, plus a font browser for previewing and selecting fonts. MultiText adds improvements for position, pivot, alignment, and CSV import, and it gains double and triple click selection with drag selection, which should make dense text comps less like surgery with oven mitts.

Roughly a third into testing, expect your existing templates and macros to need a quick sanity pass, because new editors tend to surface old assumptions. That is normal. Test new tools before you trust them in production.

SPEEEEEEEEEED

Fusion 21 also leans harder into retiming with the SpeedWarp node SPDw. SpeedWarp is an AI powered retiming tool that analyzes motion between existing frames to construct new intermediate frames for smooth slow motion without stuttering. It uses DaVinci’s neural network and supposed to be good at reconstructing complex motion where traditional interpolation or frame blending would typically blur or distort.

HTML and JSON graphics walk right in

Fusion Studio 21 adds native support for OGraf HTML graphics and native support for Lottie animations. That combination targets a common pain point in broadcast and social deliverables: motion packages that need to travel cleanly between teams and machines without turning into a pile of fragile renders. And since there is always one more Typo, you want it to work quickly.

We need to talk about OGraf

The OGraf Standard is a web based broadcast graphics specification from the European Broadcasting Union. It targets graphics like lower thirds and over the shoulder elements, and it aims to make them deliverable and renderable across diverse platforms instead of being trapped inside closed vendor systems. The idea is modular graphics workflows where components can be mixed and matched, so teams can create a graphic once and render it on traditional broadcast outputs, digital platforms, web streams, and even inside video editing tools.

At the spec level, OGraf defines what a compliant graphic looks like and how a renderer should interpret it, so a graphic can be created once and used in multiple compatible renderers. A graphic must include a JSON manifest ending in dot ograf dot json plus a JavaScript file that exports the graphic as a Web Component, along with any resources like images, videos, and fonts. The spec also describes a typical workflow split into editor, controller, server, and renderer, and it explicitly allows those parts to come from different vendors rather than a single all in one stack.

That is excellent news for Fusion Studio users because it adds native support for OGraf HTML graphics, which turns this from a broadcast only niche into something you can pull directly into comp land without reinventing the pipeline.

If your shop already gets OGraf packages from a broadcast graphics team, or you need to hand off the same graphic logic across multiple renderers, native OGraf support means fewer bespoke conversion steps and less glue code that breaks at the worst possible time. It also gives Fusion users a more standardized on ramp for HTML graphics workflows, which is the kind of boring interoperability that saves hours.

USD and the 3D side of comps

Fusion Studio 21 updates its USD stack with support for USD SDK 25.11, including the Hydra 2.0 API for the Storm renderer. USD support expands to 3D matte objects and textures, plus a USD Texture Projector and Catcher. The USD Loader also gains global in and out controls. On the compositing side of 3D, the 3D Renderer adds support for Cryptomatte. Fusion Studio 21 also adds native support for creating Relief Maps.

There are also workflow improvements that focus on day-to-day graph hygiene. Fusion Studio 21 lets you change common inspector properties for multi-tool selections, and it can change common inspector values across all selected multi-tool layers. That should reduce the classic Fsuion ritual of clicking twelve nodes to change the same one value.

Deep, stereo, vectors, metadata, and lens work

Fusion Studio 21 adds multilayer support for stereoscopic 3D clips and deep images. Deep images gain color correction. Vector channel support is added for multilayer workflows.

Metadata handling gets more flexible: user defined metadata variables can be used in paths, expressions and scripts. Lens Distort adds checkerboard calibration and GPU acceleration.

Fusion Studio 21 also allows keyframes and spline views to open as a floating window, which is a small quality-of-life feature that tends to matter a lot once you animate all day.

Installer scope and the extra apps

Fusion Studio 21’s installer puts the core application on your system and also adds utilities for setting up hardware control panels. It also installs Blackmagic RAW Player and Blackmagic Proxy Generator into the applications folder. On macOS, installation runs via the Fusion Studio Installer icon, and removal uses the Uninstall Resolve icon. On Windows, uninstall goes through Programs and Features, selecting Fusion Studio and running Uninstall. On Linux, uninstall comes from choosing the uninstall option after running the installer.

Minimum system requirements to actually run it

The macOS minimum requires macOS 15 Sequoia or later, an Apple Silicon based computer, and 16 GB of system memory or 32 GB for improved performance. For monitoring, it lists Desktop Video 12.9 or later.

The Windows minimum requires Windows 10 Creators Update, 16 GB of system memory or 32 GB for improved performance, and a GPU with at least 4 GB of VRAM. It lists a GPU that supports OpenCL 1.2 or CUDA 12.8, AMD and Intel official drivers from the GPU manufacturer, and an NVIDIA Studio Driver 570.65 or newer. For monitoring, it lists Desktop Video 12.9 or later.

For Windows on Arm, the minimum calls for Windows 11 for ARM on a Qualcomm Snapdragon X Elite series processor, with 16 GB of system memory or 32 GB for 4K.

On Linux, the minimum calls for Rocky Linux 8.6 and 32 GB of system memory, plus a discrete GPU with at least 4 GB of VRAM. It lists OpenCL 1.2 or CUDA 12.8 support, AMD official drivers from the GPU manufacturer, and an NVIDIA Studio driver 570.26 or newer. For monitoring, it lists Desktop Video 12.9 or later.

Pricing and licensing reality check

Fusion Studio is listed at $295. As always, new tools and innovations should be tested before use in production, preferably on a clone of the job, not the only copy of the job.

Link Citation Block

// Quoted info
https://www.blackmagicdesign.com/products/fusion
https://www.blackmagicdesign.com/products/fusion/compare
https://www.blackmagicdesign.com/support
https://www.komkomdoorn.com/krokodove/
https://ograf.ebu.io/
https://lottie.github.io/
https://openusd.org/
https://github.com/Psyop/Cryptomatte
https://www.blackmagicdesign.com/products/blackmagicraw
https://www.blackmagicdesign.com/products/blackmagicproxygenerator
https://www.apple.com/macos/
https://www.microsoft.com/windows
https://www.kernel.org/
https://www.khronos.org/opencl/
https://developer.nvidia.com/cuda-zone
https://www.nvidia.com/download/index.aspx
https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-x-elite
https://rockylinux.org/
https://www.blackmagicdesign.com/products/davinciresolve

The post Fusion Studio 21 beta is here first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: OctaneRender is a GPU renderer that sits after lookdev and before finals, and it talks fluently with DCC plugins plus OpenUSD and MaterialX, when it is in a good mood.

The alpha, the scope, the fine print

OctaneRender 2027.1 Alpha 1 is out as a public development build intended for testing by experienced users, and it is explicitly not positioned as production ready. Scenes saved in this alpha are not guaranteed to stay compatible with future builds. The build is Windows only right now, the minimum required NVIDIA driver version is 572. The downloads listed for this alpha are the standalone Windows installer and a ZIP archive. Other build types are planned for subsequent releases.

Real time neural viewport, now with thunderbolt energy

The headline feature is a new real-time neural viewport mode that replaces the previous real-time mode. It is built on the neural radiance cache framework introduced in OctaneRender 2026. The alpha describes the new mode as enabling near noise-free interactive rendering at very low sample counts compared to traditional path tracing. The mode is designed to preserve the spectral path-tracing behaviour while improving interactive feedback, even under complex lighting conditions. It combines internal research with NVIDIA DLSS Ray Reconstruction.

In the UI, the alpha notes a dedicated toggle. The real-time neural viewport can be enabled or disabled using a Thunderbolt button in the viewport components bar. Quality settings for the real-time denoiser live under the imager node, with the goal of balancing performance and quality depending on the hardware. If you have ever watched a veiwport go from soup to something readable right as a director walks over, you already know why this matters. The promise here is faster clarity, not just faster pixels.

Upscaling joins the party: DLSS and FSR modes

This alpha adds support for new up-sampling modes based on NVIDIA DLSS and AMD FSR. The build also references AMD FSR 3. The implementation sits in the Upsampler section of the imager node, alongside other up-sampling methods. On the DLSS side, the referenced technology page describes DLSS Ray Reconstruction as an AI method that replaces hand-tuned denoisers with an AI network that generates higher quality pixels between sampled rays in intensive ray-traced scenes. Those statements describe DLSS generally, not a specific Octane integration result. This renderer is CUDA based, and the Windows alpha focuses on NVIDIA GPUs (Big surprise!).

AI Light 2.0: sampling that tries harder

AI Light 2.0 lands as a new light sampling method intended to resolve noise faster. AI Light is described as a hierarchical algorithm for sampling scenes with many light sources, and the update is positioned as a major revision compared to the original introduction back in OctaneRender 4.0.

For lighting heavy setups, this is the kind of change that can alter how fast you converge on creative decisions. If your daily routine includes juggling dozens of practicals, emissive set dressing, and a few too many hero gobos, any sampling improvement tends to show up right where it hurts, in the first minutes of iteration.

USD export and a more hands on USD workflow

OpenUSD workflows get a concrete upgrade. Geometry export to USD is included, and the build adds the ability to export a scene in USD format. The cgchannel overview also notes that geometry export in USD can include limited support for USD Preview Surface materials.

On the editing side, the standalone edition includes a USD Stage editor that allows selecting variants and layers without saving and reopening the USD file. The alpha also adds built in support for authoring variants and muting USD layers directly within the USD geometry archive.

If your pipeline already treats USD as a transport layer between layout, lookdev, lighting, and downstream tools, these changes aim straight at friction. More export options reduce the number of awkward handoffs that turn into late night chat messages that start with “hey quick question….”

UVs and geometry: more room for messy reality

The UV ceiling changes, because production UVs are never as polite as tool demos. The maximum number of UV maps allowed per primitive increases to 10, up from 3, and UV sets can be assigned arbitrary names in DCC apps that support it.

Other geometry and attribute changes include support for named UV vertex attributes, support for using vertex attributes in bump maps, support for colour vertex attributes in vertex displacement, and a Vectron tube primitive addition.

If you have ever inherited an asset with five UV sets and a note that says do not touch UV4, you now have more breathing room. The named UV support also helps keep humans oriented when the same mesh carries multiple UV purposes across shading, decals, and baking.

Changelog nuggets for TDs who read release notes for fun

Beyond new features, the alpha lists a spread of resolved issues and smaller changes. A few examples include fixes around DDS preference crashes, Alembic instancing, several MaterialX node behaviors, and multiple OpenUSD import issues such as points not loading correctly and animated point instances importing incorrectly.

The Lua API gets deprecations in geometry exporter properties, including moving from renderSizeX and renderSizeY to textureRenderWidth and textureRenderHeight, and replacing writeOcsData with embedNativeData. A small UI level tweak removes Clock Rate and Cores fields from the GPU information panel. This is where you start thinking about tool glue. If you have scripts that poke exporter properties or automate export settings, the deprecations are your early warning sign to check for breakage.

Availability, licensing, and pricing

This alpha is available alongside the stable OctaneRender 2026 releases. The software is offered as rental only via Studio+ subscriptions. The pricing listed is €23.95 per month or €239.88 per year, and the Studio+ subscription page also lists an annual price presented as 19.99 € per month billed yearly.

Free Prime editions are also available for OctaneRender and Octane X, with the Prime editions limited to rendering on a single GPU and offering a smaller set of DCC integration plugins. The alpha download links themselves require a licensed customer login for access. That is where OTOY enters the picture in the most practical way possible.

Production reality check

This build is explicitly framed as experimental, and it is not recommended for production use. That guidance aligns with the normal alpha reality: features change, files drift, and stability work continues in later builds.

New tools and innovations should always be tested before use in production, ideally on representative scenes with your actual assets, shading conventions, and deadline pressure.

What to watch while you test

The big workflow test is whether the neural viewport mode makes iteration measurably smoother on your scenes, and whether AI Light 2.0 shifts your sampling strategy. The second test is whether USD export plus USD Stage editing reduces round-trip times in YOUR pipeline. The third is whether the DLSS and FSR upsampler options behave predictably inside your lookdev and review loop, especially when you rely on consistent framing and visual stability.

https://render.otoy.com/forum/viewtopic.php?t=85551

The post OctaneRender 2027.1 alpha goes neural first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

For those who don’t know the tool: OpenPBR sits in the material and shading layer, feeding lookdev and final-frame rendering. It can travel between CPU and shader code thanks to a shared macro layer, and it plugs neatly into a broader Substance 3D style workflow.

A reference library you can actually drop in

A public reference implementation of the full OpenPBR 1.0 BSDF is now available, released as a small, self-contained library built to mirror a production implementation used in an internal engine. The package is designed to be simple to integrate. It is delivered as a single header include named openpbr.h, aimed at teams who want to evaluate, sample, and ship consistent shading behaviour without hauling in a larger framework. The licensing choice matters for production teams and tool builders. The library is licensed under the Apache License 2.0, which is commonly used for permissive reuse and redistribution.

The API is small and very on purpose

The exposed interface is intentionally compact. The API surface is described as prepare, sample, eval, and pdf. That kind of shape is familiar to anyone who has wired a material model into a renderer, a path tracer, or a real-time shading stack. You prepare state, you sample directions, you evaluate response, and you compute the probability density for whatever sampling strategy you picked.

The key point here is not that these names exist, but that the implementation is a complete production implementation of the full OpenPBR 1.0 BSDF, then refactored into a tighter library form. That implies the library is meant to be used as a working baseline rather than a toy example.

One source, many targets

A core design goal is portability across multiple compilation targets. The library includes a GLSL style macro layer so the same source can compile as C++, GLSL, CUDA, Metal Shading Language, or Slang. For pipeline folks, that is the headline hiding behind the headline. A single code path that can be shared between CPU side reference evaluation and GPU side shading variants can reduce mismatches between offline and realtime looks, reduce duplicated bug fixing, and cut down on the inevitable drift that happens when implementations fork.

This release is presented as a reference implementation, but it is also explicitly described as the physically based production implementation that ships in an internal engine. That is a different promise than a pure spec document. It is code that has been used in anger, then packaged to travel.

What this changes for lookdev and realtime teams

The practical value for working artists and tech artists is consistency. A reference implementation offers a common baseline for how OpenPBR 1.0 behaves across tools and targets, especially when the same source is intended to compile into CPU and GPU contexts.

For realtime teams, the goal of compiling into shader languages and shader adjacent toolchains is the kind of detail that can save weeks. If your renderer uses GLSL and your tools team validates materials in a C++ baker or previewer, sharing one library can reduce the odds that two implementations disagree in subtle ways.

For offline teams, a compact library with a clean API can be easier to wrap into a renderer plugin, a USD shading adapter, or a testing harness that validates renders across builds. Nothing in the provided facts claims any of those integrations exist out of the box, but the library shape is clearly aligned with that kind of usage.

Some of the most valuable wins in shading are painfully unglamorous. Deterministic results across targets, fewer implementation forks, and clearer testability can be the difference between a stable material library and a never ending parade of look diffs.

One reminder that applies to every new shading drop, no matter how solid it sounds: new tools and innovations should be tested before use in production.

The vendor angle

Adobe is positioning this as a public release of a production OpenPBR 1.0 BSDF implementation, repackaged into a minimal single header library with a cross target macro layer.

https://github.com/adobe/openpbr-bsdf

The post OpenPBR BSDF reference code from Adobe first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

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