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.

For those who don’t know the tool: UVPackmaster by Łukasz Czyż (glukoz) is a GPU-accelerated UV packing plugin for Blender. It automates the tedious job of fitting UV islands efficiently, using CUDA or Vulkan acceleration, and is widely used in texturing workflows for VFX, games, and real-time assets.

Dynamic tiles, dynamic thinking

The newly released UVPackmaster 4 marks a structural overhaul of the popular UV packing add-on. Developer Łukasz Czyż rebuilt the engine to allow features that the 3.x architecture could not support. The first visible result is Dynamic Tiles, a system that automatically calculates the number of UV tiles (UDIMs) needed during packing, rather than forcing users to assign them manually.

Texel density tiers for texture discipline

Another key addition is improved texel-density management. Users can now define per-island density before packing, and introduce texel-density tiers (groups of islands linked by shared scale rules). This enables consistent texture resolution across materials without iterative rescaling.

Group layout for atlas workflows

A new Group Layout Mode enhances control over texture atlas creation. It lets users manage UV groups directly during packing, particularly useful for environment assets or game-ready atlases. Interface refinements also include the option to reposition UVPackmaster panels freely within Blender’s UI.

A re-engineered core

The 4.0 release refactors the underlying codebase for long-term extensibility. According to official statements, UVPackmaster 3 will continue to receive maintenance updates until at least 2027, but will not receive any new features. The redesigned engine introduces better multi-platform stability across Windows, Linux and macOS, including Apple Silicon.

Still a GPU workhorse

As before, UVPackmaster can use either CUDA or Vulkan for acceleration, allowing both NVIDIA and AMD GPUs (and Macs) to benefit. The packer continues to support multi-threaded CPU fallback, UDIM workflows, per-group packing and heuristic search algorithms to improve UV fill efficiency.

Licensing and support

UVPackmaster 4 is priced at US $53 for a single-user licence, with higher-tier studio options available. It supports Blender 2.83 and later on 64-bit systems. As always, we recommend testing new software releases in controlled conditions before full adoption of the pipeline.

The post UVPackmaster 4 unwraps a smarter way to pack first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Jan also coordinates customer projects, takes care of meeting deadlines for deliveries. Before founding Cinegy, Jan‘s career included business unit manager at the former software developer Integraph Computer Systems (ICS), business development manager at Access Graphics, a subsidiary of the conglomerate General Electric, and sales and marketing manager at the IT company Cinegy. marketing manager at the IT company Aist Medialab AG. Jan is an alumnus of the University of Hamburg, where he studied history.

DP: What are the advantages of Daniel2?

DP: You say Daniel2 offers three key advantages: lower usage of of the system bus bandwidth, lower storage space/bandwidth consumption on the hard on the hard disk or in the network, freeing the CPU for other tasks. How did you and your team achieve this?

Jan Weigner: Unfortunately, this statement is only true to a limited extent and in ideal cases. If applications are adapted to the advantages of Daniel2, then one can achieve significant performance leaps that otherwise cannot be achieved even with the most expensive hardware. But if you look at Daniel2 like an easily exchangeable codec à la AVI or Quicktime, you will still achieve performance advantages, but not nearly as much. but nowhere near as much. To take advantage of a GPU-centric codec, the application must have a GPU pipeline into which the Daniel2 codec is integrated.

„Don‘t open your life jacket until you‘re off the plane!“ is another way to sum up Daniel2. If I use the CPU to decompress my video data, which then has to be shovelled by the CPU from system memory into the GPU, then we have a similar scenario. Ideally, the CPU is degraded to a data shovel, shovelling the compressed Daniel2 data back and forth – and leaving the rest of the work to the GPU, which can do it much faster. However, we have to admit, with the latest CPUs, which also have more and more CPU cores and faster RAM, we are now also getting very far. With just one 16-core AMD Epyc processor, you can achieve an encoding speed of over 800 fps 8K Daniel2, which is more than you can deliver in image data with eight BMD Decklink 8K Pro SDI cards, more than 32x UHD60 channels.

DP: What sparked the idea for Daniel2?

Jan Weigner: Daniel2 is a further development of our Daniel (V1) codec, which is already almost twenty years old. „Video for Windows (VfW)“ AVI codec with the main focus on preserving the alpha channel, i.e. the ability to preserve transparency in the output. The many problems with the AVI format were the initial spark, along with the official end of Windows support for VfW. We switched to MXF as the format and wrote Daniel2, the first native Nvidia GPU codec that can completely unload the CPU. This development process took several years until we had the first pure Nvidia Cuda video codec.

DP: Who else was involved in the development of Daniel2?

Jan Weigner: As a company we have been developing video codecs for over twenty years. Our team is partly recruited from AIST times. Maybe someone still remembers MoviePack? The software was sold almost a million times. Even then we developed our own DV codecs, MPEG1 and then MPEG2 codecs. Then came XDCAM and with our own H.264 codec also XAVC and AVC-Intra and -Ultra. We refrained from developing our own HEVC codec because we consider the pure CPU implementation of an HEVC encoder to be a waste of energy.

HEVC cries out for hardware acceleration, which is included in all common GPUs and also some APUs (CPUs with integrated graphics unit). During the development of our H.264 codec, we had already tried to accelerate it with Nvidia GPUs using Cuda but this quickly turned out to be impossible. The design of the H.264 encoder does not allow the sensible use of a massively parallel (GPU) architecture. architecture. The experience gained with Nvidia GPUs, especially Cuda, then flowed into the design of the Daniel2 codec.

DP: Why was Daniel2 developed with PC hardware in mind?

Jan Weigner: My six-year-old Dell XPS15 notebook with Nvidia GTX 1050 graphics is fast enough to cut 8K:60 using Daniel2 in Adobe Premiere – or play 8K:60 smoothly using our free player.

DP: Which projects would Daniel2 be disadvantageous for?

Jan Weigner: In reality, many editing projects remain in the codec format in which the recording took place natively, which also makes sense in many cases, as transcoding can cost time. If a camera records directly in ProRes, for example, then it is usually also edited in ProRes. So the productivity gain has to be big enough to justify a move to Daniel2, which is not always the case for small projects. When shooting directly in Daniel2 or rendering directly in Daniel2, this problem does not exist.

DP: What technical hurdles were cleared during development?

Jan Weigner: On the fastest GPUs, such as the Nvidia RTX 4090, we achieve around 4000 fps decoding and over 1500 fps encoding in 8K. The problems remain the same: The RAM is too slow and the system bus too small. The fastest PCIe-based graphics cards are are still based on PCIe 4.0 and are thus far too narrowly connected to feed the monster – consisting of thousands of GPU cores. More than 300 fps of 8K data will not pass over the PCIe bus, at least until PCIe 5.0 arrives, which will then allow for doubling, which is still far too little to fully utilise an RTX4090.

Conversely, of course, you can say that a much smaller GPU will do. We can save the planet at the same time because we burn much less energy. Or the unused 80 per cent GPU performance of the RTX4090, which I could at most utilise with image material generated directly on the card, remains for other tasks. 8K60 Daniel2 real-time encoding on an RTX4090 card uses about 4 per cent and 8K60 playback about 1.5 per cent. These values are so small, one can almost speak of background noise. A GPU fan does not start for Daniel2 8K60 encoding or decoding. With 32K or 64K, of course, it‘s different.

To achieve this speed, we have reworked every aspect of the codec over many years. RAM is slow, even on the latest and fastest graphics cards. Any RAM access, any avoidable operation that would require RAM access, has been avoided. The codec arithmetic has been tailored precisely to the optimal processing capability of GPUs. All together, it took almost five years of development work.

DP: The Cinegys website says: „Daniel2 aims for the same place in the production workflow as Avidss DNxHR, Apple‘s ProRes, JPEG2000 or Sony‘s XAVC.“ What similarities does Daniel2 share with these codecs?

Jan Weigner: Daniel2 is a DCT codec like MPEG2 or H.264; but it is an I-frame codec, so each frame is compressed individually, just like DNxHR, ProRes and JPEG2000. With XAVC, there is also a long GOP variant that also includes the adjacent frames. DNxHR, ProRes and JPEG2000 are wavelet codecs, just like RED RAW. XAVC is a DCT codec. We are talking about a nano-DCT codec in Daniel2, which shares some features with wavelet codecs like JPEG2000, such as progressive decoding and the option to compress lossless.

Progressive decoding means that if, for example, I have compressed an 8K video in Daniel2, but only select HD as preview in the editing programme, then I only have to read a fraction of the data from disk or over the network – and only need 5 per cent of the performance compared to 8K. In production, this means that proxy workflows become superfluous. Daniel2 can scale and convert colour spaces at the same time as decoding – and is faster than copying the same amount of uncompressed data from A to B in memory. Of course, Daniel2 still supports transparency using the alpha channel, and does so so efficiently that the alpha channel can always be left on. When it is empty, it does not cost any extra bandwidth or memory.

DP: The Cinegy website says: “All old dependencies and old codec architectures have been left behind.” Are there any disadvantages to this?

Jan Weigner: Catch 22 is what you would say in English. In other words: the world has not waited for another codec. To get more support for Daniel2, Daniel2 would have to be better supported. No camera manufacturer will include Daniel2 as a format unless most editing software supports it. No editing software manufacturer will support Daniel2 unless most camera manufacturers support it.

For Adobe CC (Premiere and AFX) we have had free Windows and Mac plugins for years, now also for MacOS ARM. But the Adobe customer has to find and install the plugin themselves. On top of that, the Adobe codec plugin architecture is not designed for GPUs, everything has to be copied again from the GPU to the CPU’s memory and then back again, which is idiotic.

Daniel2 is by far the fastest codec for Adobe Premiere, but with direct Premiere integration a further performance increase by a factor of three to six would be realistic.
We have been talking to manufacturers like BMD about Resolve for over four years. You only have CUDA and only Windows, they said at the beginning. In the meantime, Daniel2 also runs on Linux, MacOS, iOS, Android, OpenCL, Metal, and so on – but Daniel2 on Raspberry Pi4? Check! Jetson Nano/Nintendo Switch? Check! Intel ARC GPU? Check! Maybe one day we’ll get to BMD and Daniel2 will become an integrated part of Resolve. We can already export today, but that’s less interesting.

Cineform was one of the best codecs of its time and has dissolved into irrelevance at the latest since the GoPro takeover. As with Betamax, Video 2000 and VHS, the best technology usually never wins, but market power. We could shoot 8K 60 4:2:2 10bit on the latest iPhone with Daniel2 if the camera could. But at least 4K60 4:2:2 10bit would already be possible. Our Daniel2 codec has been ported to iOS for years. It’s just that Apple won’t let us (or anyone else) get that close to the iPhone’s camera hardware to make it a reality.

DP: For which type of media output is Daniel 2 most suitable?

Jan Weigner: Daniel2 is not suitable for Internet streaming in the conventional sense, and thus not for the usual live-streaming-YouTuber. There are a number of application scenarios in the broadcast sector, but these are now eclipsed by other industries and application areas. Daniel2 now scales up to a resolution of 4 billion x 4 billion pixels = 16 trillion pixels (18 zeros); this is well beyond what Premiere and After Effects support.
The most interesting areas at the moment are: desktop virtualisation, video surveillance, monitoring, AR/VR/XR, gaming and hyper-video walls.

DP: In which areas would you like to improve Daniel2?

Jan Weigner: We use Daniel2 in our own cloud products, sometimes for cloud-based playout within the AWS cloud. Daniel2 is hardly suitable as a delivery format, the data rates are too high for that, but within the AWS cloud I hardly have any bandwidth problems. Thanks to Daniel2, we can increase efficiency to such an extent that we can deliver the same playout features as the competition – in comparison to the competition, respectively on many times smaller AWS Cloud instances.

We do need a GPU as part of the instance, but it can be very small. Furthermore, using Daniel2 as the playout format leaves the Nvidia H.264/HEVC hardware unused and can be used for delivery encoding or decoding SRT Live input. For a FullHD playout channel, we only need a single CPU core, also thanks to Daniel2. This is just one application scenario. With Daniel2, we can offer an alternative to SMPTE 2110 broadcast workflows that can easily scale up by a factor of ten using the same hardware.

DP: Looking back, what would you do differently in the development of Daniel2?

Jan Weigner: We wasted a lot of time trying to get people who were never interested in working with us. The innovations have not been happening in broadcast for a long time. UHD still hasn’t caught on in linear television. In Germany, real HD on ARD and ZDF would already be an enormous step forward. We’ve been doing 8K for five years and now much, much higher resolutions. I don’t have to look for customers for this in the TV or film sector. Gaming and AI are fields that we concentrated on too late.

DP: In the near future, what developments await us in the in the world of codecs?

Jan Weigner: The next version of the Daniel2 codec is on the way – and it will be even faster, require significantly less bandwidth and offer better quality. That covers the horizon for the next two years. What will be in five or ten years, I can only guess. Resolutions will increase in any case, but I dare to doubt that this will happen through the TV sector. Gaming and AR are more likely. Daniel2/3 is the ideal codec for AI training. Faster than any hardware-accelerated JPEG or H.264/HEVC/HEVC decoder, with no resolution restrictions but progressive decoding. AI training image databases encoded with Daniel2 can be pushed through the AI cluster much faster.

DP: How do you view the fact that RED, or rather James Jannard and team, are taking legal action against competitors?

Jan Weigner: We’ve been following the action from the beginning. That RED ever received this trivial patent is a disgrace to the US Patent Office. There is clearly prior art (also called “prior art”. In patent law terms, refers to the technical and other knowledge at the time of the patent application. – Editor’s note). The RED RAW format is JPEG 2000. The fact that RED got a patent on a certain form of debayering is astonishing, as there is no technical innovation behind it. Others have brought better solutions to the market before.

DP: Was there a point in the history of Daniel2’s history that makes you particularly proud?

Jan Weigner: Various national American TV stations would not be on-air without Daniel2. Virigin Media’s first UK UHD channel (hosted in the AWS Cloud) could only be launched thanks to Daniel2, as the performance of the AWS instance was not sufficient at the time.

The post Daniel2 Dynamo? Next-gen Codecs! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.