For those who don’t know the tool: Mush3D is a GPU-accelerated finishing tool for animated caches. It imports Alembic data from other DCC applications, then adds sculpting, corrective deformation, transfer and simulation before downstream use.

Surgery after animation

Mush3D 3.0 runs the awkward stretch between approved animation and a finished deformation result. Artists can load an animated geometry cache, sculpt directly on the moving surface and add simulation or transfer operations without returning to the original character rig.

The application works with animated meshes rather than limiting its sculpting tools to static geometry. Its workflow covers final polish, facial corrections, deformation cleanup, secondary motion and other shot-level adjustments on cached animation.

A recurring shoulder collapse, an elbow that loses volume or a facial transfer that pinches at particular expressions can be addressed on the cache itself. The artist works on the delivered motion rather than rebuilding the setup that generated it. The software uses GPU acceleration for interactive deformation. It runs as an online application and as a standalone desktop application for Windows, Linux and macOS. Both access routes use the same account and licence system.

Sculpt the moving target

The sculpting system works directly on animated caches and supports multi-resolution editing. It can reconstruct subdivision levels from cached animation, allowing an artist to work at different mesh resolutions while keeping modifications on a shared layer across the mesh stack.

That gives the tool a job closer to shot finishing than conventional asset sculpting. The input already moves. The task is to repair, reshape or enrich that movement without treating every frame as an unrelated static model. Sculpting brushes can change the animated surface, while cloning tools transfer surface detail from other meshes. Earlier versions already allowed corrective shapes to be sculpted on individual frames and their intensity to be animated across the timeline. The cache workflow also avoids tying the finishing pass to a particular source DCC. Geometry usually enters through Alembic, while the free tier limits exchange to OBJ. Paid tiers add Alembic import and export. Core sculpting remains present in the free edition. More specialised deformers, desktop access, project history and Alembic exchange sit in the paid plans.

Pose Trainer learns the fixes

The new Pose Trainer deformer applies example-based correction to animation caches. Artists prepare a set of reference poses, either by sculpting them manually or by using captured 3D data, then train the deformer on those examples. The resulting corrections can run across the animation cache. This targets deformation errors that recur whenever a character reaches similar poses, without requiring the original rig to be rebuilt.

A pre-sculpted pose can define how the surface should look when the underlying motion reaches that condition. The trained system then applies the learned correction to matching portions of the animated cache.

Pose Trainer also works with facial animation. The tool can improve facial 4D transfer between different characters by learning target-specific corrections intended to retain expression volume, silhouette and sculpted form.

The same mechanism can clean up transferred expression libraries. Artists can use cloning tools on FACS and blend shape sets when the transferred shapes need manual correction. This places Pose Trainer between raw transfer and the final animated cache. It does not replace the source animation, but modifies the resulting deformation through trained corrective examples.

Tetrahedra enter the tissue

Version 3.0 adds a tetrahedron-based deformation system for secondary motion in muscles, fat and other soft tissue. Artists paint a mask over the surface region that should receive the effect. The solver creates a tetrahedral volume beneath that selected area and uses it to deform the animated surface.

The mask keeps the operation local. A character does not need a tetrahedral volume across its entire body when only a neck, abdomen or other soft region requires additional motion. That makes the new solver part of the tool’s established simulation workflow. Existing deformers include Jiggle, Wrinkle and Transfer Shapes, alongside the Sculpt Deformer and the new Pose Trainer.

The tetrahedral solver does not appear in the free plan. It is included in Indie, Pro and Enterprise subscriptions, together with skin wrinkle simulaiton and the other paid deformers.

Wrinkles without a dermatology degree

The skin-motion system lets artists mask areas of a character and generate dynamic wrinkles and surface movement from the animated performance. This follows the same regional approach as the tetrahedral solver. The artist chooses where the deformation should occur rather than applying a global simulation to the entire cache.

Jiggle deformation remains available for secondary motion, while Transfer Shapes moves deformation information between meshes. These tools share the central cache-based workflow: import animation, isolate the area that needs attention, apply a deformation layer and export the adjusted result.

Facial transfers get a repair pass

Facial transfer can expose differences between source and target characters. Proportions, expression shapes and surface volume may not survive a direct transfer unchanged. The facial workflow in version 3.0 uses Pose Trainer to learn corrections for the target character. Artists can prepare corrected examples and apply the trained result across the transferred animation cache.

No supported external training frameworks, runtime engines or model formats are named, and no API details appear on the page. Software API access is listed as an Enterprise feature. The supported API functions, programming language and integration targets are not specified.

Web app or desktop seat

The software can run through a browser-based web application or as a standalone desktop program. The web application uses account-based access. Paid plans include a web workspace and project history, while the free plan includes signed-in application access and an account dashboard. Paid subscriptions also include a desktop licence. The standalone build supports Windows, Linux and macOS.

Licences, billing and machine activations are managed through the account dashboard. Existing users of version 2.0 retain separate access to legacy accounts and downloads through the older service.

Four plans and one revenue line

The Free plan costs $0 per month (That’s why it is called free)). It includes account access, OBJ import and export and the core sculpting tools. It does not include Alembic exchange or the paid deformers.

https://mush3d.com/pricing

The Indie subscription targets artists and companies with annual revenue below $100,000. It costs $29 per month or $290 per year. Indie includes the web workspace, desktop licence, project history, Alembic import and export, Sculpt Deformer, Wrinkle Deformer, Jiggle Deformer, Transfer Shapes Deformer, Pose Trainer, tetrahedral simulation and skin wrinkle simulation.

The Pro subscription targets companies with annual revenue above $100,000 that use the software in production. It costs $98 per month or $980 per year. Pro contains the same listed creative tools as Indie and permits commercial use above the $100,000 annual revenue threshold.

The Enterprise plan costs $149 per month or $1,490 per year. It adds floating seats, team licence management, an offline activation manager, a licence-manager server and software API access. All three paid plans are subscriptions. No perpetual licence.

Alembic does the handoff

Paid editions use Alembic for animated geometry import and export. That keeps the application outside the source DCC while preserving access to moving mesh data. The free edition exchanges OBJ files instead. OBJ carries geometry but does not provide the full paid Alembic animation-cache workflow described for production use.

One layer, several resolutions

Multi-resolution cache sculpting addresses a specific problem. Animation caches may arrive at one resolution, while an artist needs access to broader forms and fine surface detail during correction. The software reconstructs subdivision levels from the animated cache. Artists can move between resolutions while keeping changes on a shared layer across the mesh stack. That shared layer lets broad edits and detailed surface work belong to the same modification structure.

Cloning tools can transfer surface detail from other meshes. The same cloning approach supports correction of FACS and blend shape transfers between different faces. These controls place manual sculpting beside the automated deformers. Pose Trainer handles repeated pose-based corrections, tetrahedral deformation adds larger soft-tissue motion and sculpting remains available for shot-specific work that needs direct artist input.

New tools and workflow changes should always be tested on representative assets before entering production. A troublesome shoulder from an actual show will reveal more than a beautifully behaved demo creature.

• Mush3D 3.0 release article
• Mush3D product page
• Mush3D pricing

The post Mush3D 3.0 Adds Soft Tissue Tools first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Massive is a standalone crowd simulation app for building agent scenes, with Arnold rendering, and ties into wider Maya and USD pipelines via the commercial line.

Free, but not aimless

A free edition of Massive Crowd Sim is available for non-commercial use. The core promise is simple: crowd simulation with no limits on agent capabilities, and no limits on the number or complexity of agents in a scene. That makes it a legit learning build, not a teaser that stops when you finally get a crowd moving without looking like a synchronized swimming team. The catch sits where you would expect it: renders are watermarked, and the supported renderers list stays short at the moment, with Arnold plus the built-in Velocity renderer listed as supported.

What you actually get day one

The free edition ships with a complete set of video tutorials and a stack of demo scenes. The demos cover a wide range of setups, including quadrupeds, insects, rigid body dynamics, flying, and shooting. That mix matters, because crowd work rarely stays politely bipedal for long, except Military Propaganda Goosestepping, but the studios doing that don’t need free software and have ALL the budget.

Installation is refreshingly old-school

Setup reads like a throwback in a good way. Download the installer, unzip or untar, and run it. On Windows, you run the installer. On Linux, you drop the bin directory into /usr/local/massive/. The manual can be unzipped wherever you want.

After that, the only required step is to activate the license. Optional environment variables exist, with details documented in the manual. If your pipeline team loves containers, reproducible installs, and predictable paths, this is the rare vendor workflow that does not try to reinvent software deployment. The free edition still expects you to behave like a grown-up about where binaries live, especially on Linux.

Licensing: one machine, one account, bring patience

The first launch triggers a license activation window. You enter the same username and password you use for the Massive 101 forum login. If activation succeeds, the license file lands in the .massive directory in your home directory, then the app starts. After that first activation, the app starts immediately as long as the license remains valid.

There is also a hard limit: only one active license is allowed per account, and a six month delay applies before a new license can be issued. That detail matters for lab setups, shared training workstations, and anyone who reformats their OS the way some people change socks. Not judging, just sayin’.

This is also where a free edition stops being magic and becomes process. If you plan to teach a class or run a studio workshop, design around the one active license rule early, not five minutes before teh first session.

Support: community-first, by design

Because the edition is free and limited to non-commercial use, there is no formal support provided. Instead, the Massive 101 forum exists as the help channel, where users can share tips, ideas, and problem solving.

The forum post also says the team will keep an eye on it, and there might be some input from them. If you are used to commercial support tickets with response time targets, this is not that. If you are used to production artists helping other production artists with practical workarounds, this looks familiar, for better or worse.

Export and pipeline limits you should treat carefully

Massive 101 is almost completely fully functional, with the full simulation toolset and no limits on the number or complexity of agents. It also has specific pipeline restrictions, including that motion, cloth, and hair simulation files save in a Massive 101 file format that cannot be used in Massive Prime, plus that USD and geometry export are disabled.

That incompatibility for Massive 101 and the big one is that there isn’t a row of “Assistant stations” for setup, and only one license for the big Massive to bring it all together.

Those details are important if your goal is anything beyond learning and internal tests. Watermarked renders are an obvious non-starter for client finals, but disabled export can be a more subtle trap if you assume you can “just move it into the rest of the pipeline later”. If your studio pipeline leans on USD interchange, treat this as a training build unless you can independently confirm the exact export behavior in your own testing.

Compatibility and pricing, as stated

Compatibility is Windows 10 and Linux, and free for non-commercial use. For commercial pricing, a perpetual floating license of Massive Prime is at $3500, with rental at $2500 per year, and says Massive Prime includes Massive for Maya.

Where this fits with your current crowd toolbox

If you already live inside the Crowdsim-world, this release sits in a useful niche: training, R and D, seeing if Massive fits your needs, personal skill building, and previs-scale experiments where you want to learn behavior authoring without immediately paying for seats.

For teams already hooked on Maya, the commercial ecosystem includes a Maya-integrated edition, and the broader stack talks about rendering integration and pipeline hooks across supported renderers. That larger ecosystem matters, but the free edition itself focuses on learning and local runs, not studio deployment. Also, Maya, by now, has Golaem built in.

https://www.massivesoftware.com/massive101.html

https://www.massivesoftware.com/massive101/forum/viewtopic.php?t=2

The post Massive Crowd Sim gets a free 101-edition first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Maya is a core DCC from Autodesk for modeling, rigging, animation, and FX, with lookdev via LookdevX and node FX via Bifrost, plus pipeline handoff through USD.

The headline feature is editorial glue

Maya 2027.1 adds support for OpenTimelineIO in the Sequencer, enabling interchange of editorial cut data between DCC and timeline tools.

Sequencer gets editorial glue, not just buttons

Maya 2027.1 adds import and export support for OpenTimelineIO, with OTIO data being a standardised equivalent to XML for supported sequence, track, shot, audio, and file reference information. OTIO import preserves camera assignments and camera attributes, and reconstructs tracks from stored track information. The same workflow includes additional shot-level data such as labels, colors, thumbnails, and frame range information.

Sequencer also gets a round of editorial workflow updates beyond OTIO. Autodesk claims improvements to timeline exchange, shot editing, audio handling, playblast output controls, and scripting access. Shot creation now works directly on a selected track, or from a selected Time Slider range. Shot editing includes an updated hold workflow where hold frames come from a dedicated Hold mode while you drag shot edges. That sounds small until you try it on a cut with a dozen micro-trims and discover you do not need to invent a new swearing dialect.

Audio behavior becomes stricter. Sequencer uses only audio associated with the sequence. Audio not linked to Sequencer gets ignored, and Sequencer audio does not mix with Trax audio. A new Time Slider audio menu option called Use Sequencer Sounds controls that behavior. Playblast Shot Options adds Display Size controls for output resolution, with options listed as From Window, From Render Settings, Custom, and From Image Attributes. Output resolution depends on the chosen Display Size and Scale settings. Zooming in Sequencer now centers on the cursor when you use the mouse wheel, which helps the tiemline stop teleporting away from the thing you actually meant to inspect.

As always, new interchange formats look great in demos and get weird at 2 a.m. Test OTIO import and export on your real sequences before you bet a delivery on it.

MotionMaker focuses on editing clarity

Autodesk positions 2027.1 as a release with AI-powered tools and everyday workflow updates, and MotionMaker gets the everyday part this time. MotionMaker now shows frame ranges directly on clips and active windows. The stated goal is clearer timing feedback and behavior aligned with Sequencer.

Character naming gets a cleanup. Autodesk standard characters display simplified names in the UI, dropping the adsk_ prefix while keeping internal identifiers for compatibility. Character definitions also support a display name attribute used in the Create menu and character creation options.

New keyboard shortcuts navigate to the adjacent start frame before or after the current action clip in the timeline, aimed at faster clip-to-clip movement while editing. Updates to character registry handling also reduce redundant processing when creating MotionMaker registries.

Smart Bevel keeps hunting the ugly edge cases

Smart Bevel receives quality updates described as handling more complex geometry with fewer errors, with the practical promise of less manual cleanup on geometry with many intersecting edges.

Cutback relaxation improves to help prevent straight-edge segments from shifting, aimed at hard-surface models that mix linear and smooth forms. Smart Bevel also reduces spikes and jagged sawtooth corners in certain edge cases. Limiting works better across intersection types, with improvements intended to stop bevel results from crossing. Intersections previously missed are now detected.

Arc welding of new junctions becomes more thorough, and isolated arc removal becomes more reliable. Smart Bevel also improves handling of edge sequences that previously failed to bevel, with the result described as proper beveling and prevention of holes or missing faces at junctions along the sequence. Preset support expands so Smart Bevel presets can now save the Remove Isolated Arcs state.

Bifrost adds a search box and more sim and rig polish

Bifrost 3.1.0.8 adds a way to find where specific nodes are used in the graph, plus other new features and improvements. The same version lists updates for rigid body simulation, including per-instance colors, plus performance improvements for rigging and viewport drawing. New high-level compounds include deform_onto_mesh_UVs, wrap_deform_by_mesh, and wrap_deform_by_points. Rigs built with Bifrost now support Maya Cached Playback for improved performance, with a stated limitation that Cached Playback only works if the rig uses no feedback ports.

USD for Maya targets variants, and pins the manager

The USD plugin update listed as USD for Maya 0.36 adds support for targeting specific variants to receive edits, including changes to geometry and materials. The USD Variant Manager can now be pinned to its current display to prevent it from updating when you change selection. That is the kind of feature you only notice after it saves you from editing the wrong thing during a review.

LookdevX projects textures, searches graphs, and stays Arnold-friendly

LookdevX 2.1.0 adds texture projection nodes for mapping textures without UV coordinates. The workflow described uses the Node Library under Autodesk to add a projection node into the graph, connect a texture input, then connect the output to a material. Eight projection types are available: Planar, Spherical, Cylindrical, Ball, Cubic, Tri-Planar, Concentric, and Perspective. A Projection node combines all types into one node, with switching done inside the node so the texture updates on the object.

LookdevX also adds Graph Editor search to find nodes by name, aiming to reduce scrolling in larger graphs. Universal SRT manipulator support lands for the first matrix44 input port on LookdevX nodes, letting you edit that transform directly in the viewport via the usual manipulator workflow.

Arnold and Substance updates ride along

Autodesk lists Arnold for Maya 5.6.1.1 as part of the update, with changes since 2027 including a tech preview of Flow Render, custom AOVs for volume shaders, MIKKTSpace normal mapping support, and additional updates. Maya 2027.1 also includes Substance 3D 3.0.6.

Treat both as pipeline changes, even if you never touch a shader graph. Renderer and material tooling changes can break assumptions in templated scenes, and reliabel output beats exciting output when a client stares at a schedule.

Platforms and pricing

Maya 2027.1 is available for Windows 11, RHEL, and Rocky Linux 8.10 and 9.7, plus macOS 14.0 and later. The software is rental-only, with subscriptions listed as US$255 per month or US$2,010 per year. In many countries, artists earning under US$100,000 per year and working on projects valued under US$100,000 per year qualify for Maya Indie subscriptions, listed as US$330 per year. Maya Creative 2027.1 is also available, listed as pay-as-you-go with prices starting at US$3 per day and a minimum spend of US$300 per year. It has the same new features as Maya 2027.1, except for Bifrost.

New tools and innovations should always be tested before use in production, ideally on real shots and real assets, not a perfect demo cube that never gets a change request.

https://help.autodesk.com/view/MAYAUL/2027/ENU/?guid=GUID-F923AA68-6CE5-4292-88EA-292F5A786BA2

The post Maya 2027.1 adds OTIO to Sequencer first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Dash runs inside Unreal Engine as an asset browser plus world-building toolkit. The Fab build ships the Content Browser only, while the website installer can also unlock the wider toolset with a paid license.

Two installs, one idea

Polygonflow now offers Dash in two distinct ways: as a free plugin on Fab and as the full Dash installer from the Polygonflow website.

The Fab listing calls the package “Dash – Advanced Asset Manager” and in this version, it is “just” a content browser that lets you search and drag and drop local assets into any UE5 project. It includes tagging for your own assets with a stated limit of up to 1,000 assets tagged per month, plus a Smart Collection System for organizing assets.

The website installer route matters more, because the Dash Content Browser itself has been available for free since Dash version 1.9.0, but the free license is limited to the Content Browser side of the toolset. The free license includes the supported libraries, the tagging system, and the centralized browsing experience across UE5 projects, but not other Dash tools such as Easy Scattering, Procedural Meshes, Physics Tools, or Material and Atmospheric Tools.

What is actually different between Fab and the website build

The Fab version includes the Content Browser only, and explicitly points to the website download if you want the full plugin toolset. The website build splits into two experiences. The free license stays content-only, meaning you use the Content Browser, library integrations, tagging, and centralized asset browsing. A paid license can unlock the other Dash tools, Easy Scattering, Procedural Meshes, Physics Tools, and Material / Atmospheric Tools. So the practical difference is not the content browser UI, it is how far you want to go beyond asset browsing once you are inside the same plugin shell.

Included libraries, and why that matters more than the tagline

Both the Fab listing and the Dash docs have the same core set of integrated libraries: Quixel Megascans via Fab or Quixel Bridge downloads, Amazon Berkeley Objects with 6,900 models, ambientCG with 2,300 textures plus HDRIs and decals, Poly Haven with 1,900 assets plus textures and HDRIs, The Base Mesh with 1,400 models, and the IES Library with 1,300 lighting presets.

On the website side, the Dash Asset Marketplace lives inside the Content Browser, with the Dekogon library and a Sierra library entry that includes one free pack.

Polygonflow also supports browsing and importing content across multiple UE projects from inside the project you are currently working in. The docs add a warning on version compatibility for external browsing: UE5 projects are forward compatible but not backward, so you can browse content from the same or older UE5 versions, not newer.

Custom assets, right now

In the Project Library tab, you can currently add your own static meshes, textures, and blueprints. The tagging flow focuses on making assets searchable beyond filenames and folder names, and the content browser adds collections for grouping assets into reusable sets.

Pricing and the usual production warning

On Fab, Dash – Advanced Asset Manager is free. Commercial pricing for paid Dash licenses is 8€ for students, 20€ per Month for professionals below the 250.000$ barrier, and 95€ per month for bigger studios. Test any new browser, tagging, or library workflow on a non-critical project before it touches production depots and shared team setups.

https://www.fab.com/listings/865301e9-2d26-425d-8f3c-e0aadf35da61
https://docs.polygonflow.io/advanced/free-content-browser

The post PolygoFlow Dash asset manager goes free on Fab first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Feature animation gets performance-obsessed

A new set of feature animation sessions puts character performance front and centre. Supervising Animator Adam Sarophim will present how performance-driven animation gets built at Sony Pictures Imageworks using work from KPop Demon Hunters and GOAT. The session description focuses on crafting emotion, personality, and audience connection through movement, timing, and subtle detail.

Animator Jacob Frey will present The Animation of Zoomania 2 and describe collaboration between art and technology as part of the filmmaking process at Walt Disney Animation Studios. The session description frames the work as an example of how tools and artistic intent meet inside a feature pipeline. Details about specific story beats, pipeline tooling, or shot counts are not specified in the Sources.

Two European-leaning projects also land on the slate: The Last Whale Singer (a teenage humpback whale named Vincent), and a procedural real-time pipeline segment called Trash Island. The speakers listed for that session are Jan Hofmann, a CG Supervisor and Unreal Engine expert at Telescope Animation, and Amir Ashkezari, an FX Supervisor and Technical Director at PFX. The pipeline description centers on Houdini generated assets moving via OpenUSD into both real-time Unreal Engine and a traditional Autodesk 3ds Max and V-Ray workflow, connected by custom tools intended to support daily collaboration between studios in different locations.

Zako is a feature project based on a true story about an Armenian painter during World War II and the Soviet Union. Director Tigran Arakelyan of OnOff Studio will present how VR animation can serve as a core creative tool for sketching, staging, and animating directly in 3D space, as well as practical methods for integrating VR animation into a feature film production pipeline.

AI talks that aim past hype

The Artificial Intelligence track is around practical production use and the question of what AI should do in modern pipelines, with an emphasis on keeping a human artist in the loop.

Ben Grossman of Magnopus is listed for an individual session, followed by a panel appearance. Mohsen Mousavi, Senior Director of Visual Pioneering at Eyeline Studios, is also in an individual session and on the same panel. Hao Li, founder of Pinscreen, is about to present on work spanning computer vision and facial performance technology, having completed AI work on Fallout Season 2. The track is curated by Mike Seymour, co-founder of fxguide.

Cinematography goes deep into the lens mess

The Cinematography track highlights craft from stop-frame production through to photoreal VFX . Cinematographer Dave Alex Riddett will present Work Aard Play Aard, a behind-the-scenes look at decades of cinematography at Aardman and the practical skills involved in stop-frame storytelling.

VFX Supervisor Victor Perez will present GLASS: Capturing the Lens Look for Photorealistic VFX. The session description focuses on lenses having distinct optical characteristics including distortion, chromatic aberration, field curvature, vignetting, iris behavior, and micro-contrast, and on methods to analyze, measure, and reconstruct those characteristics inside VFX pipelines so CGI inherits the visual identity of the camera that shot the plate. The track is curated by Sara Coppola-Nicholson, Director of Research and Education at Cooke Optics.

Partners bring cloud and tools to the conversation

Two newly announced partners add their own angle on production infrastructure and creative tooling. AWS Visual Computing is about cloud-based solutions for visual effects, animation, and 3D content production, including scalable rendering, virtual workstations, and high-performance storage optimised for media workflows. It also highlights AWS Deadline Cloud as a fully managed render management service.

Foundry is … well, if you don’t know the company making Nuke, you should reconsider and read the rest of this website. The partner programming showcases compositing, lighting, look development and texturing, with participating studios named as Industrial Light and Magic, RISE FX, Outpost VFX, and Mikros Animation.

The partner section also includes an in-person day at Raum Mannheim featuring project insights on Fallout Season 2, Netflix’s The Dinosaurs, and Teenage Mutant Ninja Turtles: Chrome Alone 2 – Lost in New Jersey, plus a talk by Director and VFX Supervisor Hugo Guerra.

Dates and tickets, plus the reality check

Tickets are on sale, and the “On Site” runs at Haus der Wirtschaft in Stuttgart from May 5 to 7, Online and On Campus run on May 8, and On Demand runs from May 9 to June 9. See all of you there!

https://fmx.de/en

The post FMX 2026 adds animation, lens talks and of course AI first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

dy Install Libs is built to make installing libraries smooth and simple, with the stated goal of avoiding manual edits and broken installs. It ships as a shelf toolset for Houdini, aimed at the everyday stuff artists actually do: bring in a library, make sure it loads, and move on with their lives. The headline feature in v1.3 is Library Manager, a custom UI tool to download, install, enable, and disable local libraries. Version v1.3 is dated March 24, 2026, with a follow up v1.3.1 dated March 26, 2026.

The part you came for: Library Manager

Library Manager adds a single interface for discovering, installing, and managing open-source and commercial Houdini libraries. That matters because library installs rarely fail in exciting ways. They fail in slow, petty ways, like a missing file, a wrong path, or a package file that loads everywhere except the one machine that counts.

This release frames Library Manager as an evolution and combination of the earlier toolkit tools. The idea is simple: fewer trips into the filesystem, fewer chances to fat finger a package entry, and more time spent actually using the tools you installed.

There is also an explicit caveat: it may not work for installing render engines, since they typically require a custom JSON package file to set up environment variables and paths. In other words, the tool targets the library side of life, while heavyweight integrations can still demand a hand-tuned setup.

What dy Install Libs does around the manager

The toolkit includes several functions that cover the library lifecycle, from bringing in data to keeping package files aligned with where the library lives. Library from JSON imports a downloaded library using its JSON file and automatically copies and updates the package file in your library folder. This is the one for when a library arrives with its own packaging info and you want it to just land cleanly.

Install Library generates a new JSON package from scratch tied to your library folder. That means you can start from nothing and still end up with a package file that points where it should. Library from GitHub clones and installs libraries straight from a GitHub URL, which is handy when the library lives as a repo instead of a zip. It also supports downloading repository releases. That support is listed in v1.1 dated August 5, 2025.

Create Library builds a library scaffold with templates and auto-generates the package file, which aims at standardizing how a library starts its life on disk. Restart Houdini to reload everything with one click, when you want the tool to do the classic on-and-off ritual for you.

GitHub reality: releases, missing packages, and relative paths

Git based libraries come with their own quirks. The release notes for v1.1 include a fix for cases where a repo does not have a package file, replacing an older path JSON variable with hpath. It also adds support for relative paths using the $HOUDINI_PACKAGE_PATH variable in installed package files.

That combo matters because repos vary wildly in structure. Some ship a tidy package file. Some ship nothing but hope. Tooling that acknowledges those differences tends to be more usable in real production setups, where you do not control every library you need to install.

Small fix, big impact

v1.3.1 lists support for the enable key from package files when it appears as a string, while it should be a boolean. It also lists a URL key fix for when a library from a database is installed manually as a standalone library, along with small fixes and improvements.

Pricing and the practical bit

The tool is free to download, with a Gumroad listing shown as $0+. Pricing beyond that is pay what you tink it is worth.

Pipeline advice that still counts

Even if Library Manager makes installs feel effortless, new tools and innovations should be tested before use in porudction. Try it in a clean preferences setup first, confirm your package behavior matches expectations, and then let it anywhere near a show.

https://cdordelly.gumroad.com/l/dy_install_libs

The post dy Install Libs adds Library Manager to Houdini first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Atlux λ plugs into Unreal Engine and ships a virtual studio, lights, presets, and automation for fast renders. It is sold on Fab and can also be installed with the Epic Games Launcher.

Fab listing, now with Mac support

Atlux λ is now available on Fab as a visualisation plugin for Unreal Engine. The newest version adds macOS support. The plugin is solo-developed by Jorge Valle Hurtado. The plugin requires account registration. The listing also shows no rating yet, Allows usage with AI set to Yes, and Generated with AI set to No.

The pitch, minus the pitchforks

The core idea: a complete in-editor photo studio-style workflow aimed at speeding up lighting, rendering, and cinematic work inside Unreal Engine. In practice, that means a Virtual Photo Studio, realistic light assets, studio and light presets, camera motion presets, an automated turntable, batch rendering, post-process materials and LUTs, procedural gobos, VFX reference assets, and a simplified render interface.

A key workflow point is automation around sequences and rendering. Rendering takes one click, with everything handled automatically, and no manual Level Sequences or Movie Render Queue setup required. That is a big promise, so treat it as a workflow claim until you validate it in your own scenes and build environment.

One click rendering as a pipeline building block

If you have ever tried to standardise look dev outputs across a team, you know the dull truth: the hardest part is rarely the final pixels. It is the repeatability. Atlux λ leans into repeatability by bundling its own studio environments, lighting assets, presets, and a streamlined render interface, then pushing users toward a single-button render flow. The idea is to keep the shot setup and output consistent, especially when multiple artists work on the same asset library.

That is also where the curated content matters. When a tool ships with production-ready assets and presets, it reduces the number of decisions per shot and lowers the odds that one artist accidentally reinvents the sun at 3 a.m. It also gives supervisors a clearer target for what “correct” looks like in a shared lighting and camera language.

Gaussian Splatting prep, with COLMAP export

The feature list includes COLMAP export for Gaussian Splatting workflows. For teams experimenting with Splatting , the practical value depends on how smoothly the exported data lines up with your existing reconstruction steps and tooling, including COLMAP. The sources do not provide detailed specifications for what is exported or how it maps to downstream tools, so you will need to validate that part yourself.

Atlux λ Live and packaging as a desktop app

The feature list also includes Atlux λ Live, described as a “runtime version” that allows users to package a scene as a fully interactive desktop application, for purposes such as interactive client presentations, sharing scenes without requiring the Unreal Editor, and delivering a controlled runtime experience using the toolset.

If you have ever handed off an interactive review build to a client, you already know why this matters. Packaging is rarely hard in theory. It is hard because it is always the week you cannot afford surprises. Treat the packaging automation as a convenience feature that still deserves a dry run on your target machines and OS versions.

Pricing and licensing, in plain numbers

Pricing is now official: A Personal perpetual license is listed at US$249.99 excluding tax. A Professional perpetual license is listed at US$349.99 excluding tax. Both are perpetual licenses with one active user on any computer, offline access, and full support, updates, and maintenance.

The buy page has a standalone installer for Windows only for the Personal and Professional options, and it also describes purchasing via Fab with the same Personal and Professional pricing, plus availability on Mac and inclusion in the Epic Games Launcher.

Educational pricing is also specified on the same page. An Educational Rental is listed at US$4.95 per month excluding tax, described as cancel any time, one active user on any computer, and support, updates, and maintenance while active, with Windows only and a requirement for school or academy validation.

Support is for Unreal Engine versions 5.4, 5.5, 5.6 and 5.7.

// Fab listing page for Atlux λ
https://www.fab.com/listings/3c321e8e-f0b0-4235-ba38-02d59299869b
// Official product homepage and feature overview
https://atlux.one/

Atlux λ 2 brings 3D scanning inside Unreal

The post VINZI Atlux λ arrives on Fab first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Forest Pack scatters huge scenes inside Autodesk 3ds Max, living between layout and lookdev where forests, rocks, and crowds multiply faster than notes.

The headline change: collisions stop playing favorites

Forest Pack 9.3.5 expands collision checking to every distribution mode, including Path, Reference, and Particle Flow.

That sounds simple, but it lands right in the messy middle of environment work, where you swap distribution approaches as the shot evolves. One day you block a treeline with a path, the next day you need to reference hero trees, and then someone asks for “just a bit more variation” and you end up driving density through a different method. In 9.3.5, collision checking no longer depends on which distribution mode you picked.

The practical result is consistency. Your layout rules do not have to change just because your distribution method changes. If your day-to-day involves dense assets where intersections become a constant cleanup tax, collision checking across modes targets that pain directly.

This release also frames collision parity as a feature-parity and consistency push across distribution methods, with the stated goal of removing limitations that force workarounds. That positioning is a marketing claim, but the core functional change is specific and concrete: collision checking now covers all distribution modes in the tool, including Path, Reference, and Particle Flow.

Materials that travel: .pmat lands in the Library Browser

9.3.5 adds support for portable material libraries in the Library Browser using the .pmat format. The .pmat format is a custom material library format used internally for the developer’s own libraries. The key design point is independence from specific 3ds Max versions, which supports a wider range of releases without maintaining separate libraries per version.

That same mechanism now applies to user asset libraries through the Library Browser for Forest objects. In practical pipeline terms, the feature targets studios that keep multiple 3ds Max versions in flight, plus anyone babysitting long-lived projects with legacy requirements.

Effects gets two new levers, one of them watches the camera

The Effects system in Forest Pack picks up new attributes aimed at more precise control of items and camera-based logic.

First up is fpItem.geomSubID. It returns an item’s sub-index in the Geometry List. The use cases include defining indices within groups, ForestLOD, and ForestSet, and targeting individual elements inside grouped geometry, ForestLOD setups, or Forest Sets.

That matters because many environment assets arrive as grouped geometry, or they become grouped once the shot starts demanding variants and LOD juggling. With a sub-index available, Effects can target specific components inside an asset. The examples given for what that enables include enabling or disabling a component, plus adjusting scale, rotation, or position independently from the rest of the asset.

Second is Max.cameraPos. It returns the camera position in Forest local coordinates. The functional promise here is camera-aware behavior in Effects, including custom look-at logic or changes based on distance from the camera.

Together, these two attributes push Effects toward finer-grained procedural control without changing existing setups. The release messaging says the additions aim to expand what Effects can do without adding more UI complexity or affecting existing scenes. That intent statement is not a measurable guarantee, but the attributes themselves are explicit and new.

One caveat for production sanity: camera-driven logic often looks great until you cache, render, and discover that one overlooked camera switch turns your forest into a mutating alien organism. Test new setups before you bet a delivery on them.

Pricing and licensing: what is stated and what is not

Forest Pack 9.3.5 is available to users with an active Maintenance Plan.

A store page lists Forest Pack with a total price excluding VAT of 250,00 €.

A Maintenance Plans page lists a total price excluding VAT of 80,00 € for Forest Pack maintenance.

A free edition, Forest Pack Lite, is also availabe here Forest Pack. It includes many of the core features of the Pro version and can be used in commercial projects.

https://docs.itoosoft.com/changelog/2026/03/15/forestpack-9_3_5

https://www.itoosoft.com/blog/forestpack-935-released

The post Forest Pack 9.3.5 broadens collisions 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 event: FMX is where post, VFX, and realtime folks compare notes, spot new workflows, and meet toolmakers from Foundry to AYON .

The 30th edition runs on site May 5 to May 7, with Online and On Campus on May 8, and On Demand from May 9 to June 9. Early Bird ticket options run until March 20. Tickets are sold through the ticket shop, and the full schedule is published as an online program schedule.

This year’s reveal is a broad spread across VFX, animation, and digital media creation, with more updates promised as additional speakers and topics get added. The headline message is simple: the program is live now, and it is designed to be browsed like a buffet. Get your preferred morsels here :)

RENO turns a studio inward

A newly confirmed session in the Shorts track focuses on RENO, an original sci fi short used as a live testbed for virtual production and machine learning workflows. The session names Tav Flett, Rob Hifle, James Pollock, and Paul Silcox, and describes how a traditionally post-driven VFX studio re-engineered its pipeline for a newly opened virtual production stage. It also calls out Gaussian splat scanning, automated rotoscoping, and marker removal as tools for streamlining production.

Generative video, now with shot notes

The hype cycle is almost over. The bubble tends to pop the moment somebody asks where this stuff fits into an actual production pipeline. That is the useful angle of Moonvalleys‘ session in the “The Road ahead” track. . Instead of treating generative video as a party trick, Ben Lock looks at what happens when studios try to use it for real: control, continuity, versioning, integration, governance, and all the other small details that usually kill shiny ideas on contact.

For VFX and animation teams, that is the point. Not more halfbaked sizzle reels, but a sober look at where generative video already helps, where it still breaks, which parts of the panic were never grounded in production reality, and when studios may begin hiring artists again once practical applications, and their many many limits, are easier to assess.

Predator: Badlands, built as a handoff

A joint presentation in the VFX for Features track names Laurens Ehrmann from The Yard VFX and Dominik Zimmerle from TRIXTER discussing work on Predator: Badlands. Shared assets, shared look development, and constant creative exchange across studios to ensure continuity while elevating environments, characters, creatures, and effects, plus a deep dive into selected sequences and the creative and technical challenges behind them.

And there is more to come! Much more!

https://fmx.de/en/program/program-2026/overview

The post FMX 2026 program goes live first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

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.

In this interview, Pixar shading and grooming artist Markus Kranzler discusses work on Hoppers after Elemental, including time in Pixar’s Tools Department, a layered approach for wet fur, and how design readability can trump anatomical accuracy when deadlines exist and the cameras cut fast.

Markus Kranzler is a Technical Director at Pixar Animation Studios, with credits as a character shading and groom artist on Inside Out 2, Elemental, Turning Red, Luca, and Soul, plus earlier Pixar work including volumetric clouds on The Good Dinosaur and set dressing on Finding Dory.

Before joining Pixar in 2015, Kranzler worked in lighting, lookdev and rendering roles at MPC and Trixter, with film credits including Skyfall, Iron Man 3 and Man of Steel.

DP: Hi Markus, it’s been a while since Elemental. What did you do on Hoppers, and why the role change?

Markus Kranzler: One of the main differences was that I was working on solid characters that weren’t dynamic fluids. :D  One of the first projects I worked on this show was actually not in my department, but in the “Tools Department”. That is where all the geniuses sit that create our software, plugins and shaders.

Since a big part of the movie shows animals in and out of water, I was helping them figure out a simpler way to make fur look wet without having to adjust each character’s shader to make it look wet. We ended up achieving that by layering a wet shader on top, which then affects certain lighting lobes on the fur shader. 

Also on this show, besides shading, I was grooming some of the animals. That’s what we call creating and styling the hair or fur on a character. I had done some grooming in the past, on my graduation short “The Present”, but this was the first time I actually got to groom at Pixar. 

Another difference was that I wrapped and rejoined the show about six times. Most people come on for a single stint and move on, but they kept bringing me back for a couple of weeks at a time. This was mostly after the majority of the shading and grooming artists had wrapped, so I would help crank through new assets or tackle larger waves of fixes as they came in.

DP: With Hoppers being set in a natural environment, how did that change your approach to grooming? 

Markus Kranzler: Even though the looks are different, the characters in Hoppers are strongly stylised in their own way. For us, it’s always about looks that are believable, not necessarily physically correct. Similar to most of our movies we take nature as inspiration, but we put our own spin on it. This can affect certain departments differently from others. In this film because the story heavily depends on comedic timing, I would say that the environment had controlled detail to guide the viewer’s eyes and the characters were built out of simple, readable shapes with a tactile feel similar to felted toys. 

DP: In a stylised film like Hoppers, you’re always balancing plausible physics with deliberate exaggeration. How do you decide how “real” hair and fur should behave versus how “cartoon” it should read?

Markus Kranzler: It’s all about the story! The first question we ask is: Does it serve the story better if things behave and look more realistic, or more stylised? Then we go from there. On Hoppers, the main criteria were to make the characters look endearing, comedic, but also instantly recognisable for the fast cuts. 

DP: How much of that balance is determined by art direction, and how much do you discover later through animation and shot work?

Markus Kranzler: It is usually a very collaborative and fluid process. In most cases, we have a pretty solid foundation coming from art direction, but as we move from 2D into 3D we adjust as we explore and learn things.

DP: How early were you involved in character preparation and design decisions for the protagonists and key characters?

Markus Kranzler: On this film, I joined fairly late. So most of the key characters were already being worked on. Most workflows and the design language had been figured out at that point. 

DP: On the design side, did grooming constraints ever influence decisions like hair length, density, silhouette, or “how much the hair is allowed to move”?

Markus Kranzler: Actually, yes. I worked on the skunks, and they are a great example of such a decision. One of the main features of a skunk (besides it’s smell) is its big bushy tail. In nature, the anatomical part of the tail is very skinny and the whole volume comes from it’s fluffy fur. But simulating that would not only be more expensive, but maintaining a fluffy, instantly recognisable shape would also be trickier. So we “cheated” and increased the tail’s volume to grow the hair by quite a bit. Thereby reducing the length of the individual hair curves. 

DP: Hoppers has characters that can read as more animal-like in one context and more human-like in another, depending on the scene and how we’re meant to interpret them. Did you get explicit direction to shift the exterior presentation of characters for that? 

Markus Kranzler: The main change when we see the animals from a human’s perspective is their eyes. We called them “Dot Eyes”. Since we as humans read a lot of expressions from the eyes, that shift alone made a big enough difference. We only had to make minor tweaks to the model and grooming to account for the slight difference in that region. 

DP: Tooling question: was this largely one grooming system end-to-end, or did you use multiple systems for different needs?
Markus Kranzler: We have our own proprietary grooming tool within our in-house animation software, “Presto,” called “Pele”. We use that for both animal fur and human hair, and from there it feeds into our standard shading pipeline. 

DP: For artists trying to achieve a similar look, what are the first conceptual steps you take when approaching a new groom, for example, a beaver?

Markus Kranzler: First I need to understand the art direction. For us, the guideline comes mostly from 2D drawings. Before we start, we have a kick off meeting with the production designer, art director, and/or character designer. In that kick-off, we go over the general aesthetic of the film, who the character is and what they do in the movie, and then break apart each component.

Often we will also get some photographs of real-world examples that serve as inspiration, but we clarify what we want to preserve and how we want to diverge from reality. Once I have that understanding and reference material, it’s very similar to how one would approach a photo-realistic asset. E.g. drawing textures, placing and grooming the hair curves, adjusting the specularity, tweaking displacement etc. And you do a lot of iterations.

DP: Reference for SOME of these animals is abundant. How do you sort, filter, and prioritize reference when translating real-world anatomy into a stylised film language?

Markus Kranzler: That is a pretty common and important discussion that comes up in meetings and reviews. As I mentioned, our guideline is usually a 2D drawing, which inherently is a simplification of something by an artist. And then a shading artist like me interprets it to create a different version of it. It’s a bit like a game of telephone. Sometimes the message gets jumbled up. It does get easier with time, as all parties gain more experience in communicating and interpreting the intentions. But sometimes that can also lead to new discoveries that improve results. So it’s always a learning curve, but that makes it exciting and refreshing every time. 

DP: Looking back, do you have a favourite character to work on, and why?

Markus Kranzler: My answer probably won’t be very exciting since I didn’t work on any of the main characters, but I would say my favourites are the classroom turtle we see at the beginning of the movie. Not a lot of grooming there, but I find it adorable. And then I made a character we called “Janky Beaver”. It’s one of the prototypes of the observation robots we see in a short time-lapse. You barely notice it in the movie, but I like it because it’s a great example of the wacky humour of the film.

Elementary!

The post How Pixar Cheats a Skunk Tail first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the school: The VFX School was an online training platform focused primarily on Houdini-based FX simulation workflows. Its courses centred on effects such as destruction, fluids and pyro simulations, sometimes rendered with engines such as Redshift and prepared for compositing. The platform targeted artists learning production-style simulation pipelines.

Closing the classroom

The online training platform The VFX School has announced it is shutting down. Rather than removing its material or quietly archiving it, the platform has released its entire course library for free public access. All courses are currently available to stream without registration or payment. The site also provides downloadable project files and associated assets for the training material.

It is a rare exit strategy in the education business. Instead of locking the archive behind expired subscriptions or abandoned logins, the creators chose to hand the library to the community that supported it. The platform itself states that the release is intended as a thank you to artists who followed and supported the school. In practical terms, this means the full catalogue of courses can now be watched and downloaded without cost.

Videos are currently hosted through Vimeo and embedded on the course pages. Project files and scene assets are distributed as downloadable ZIP archives. According to the website, video access is expected to remain online until March 1, 2027. After that date the Vimeo hosting may be removed. For anyone interested in the material, the polite interpretation is simple. Download first, organise later.

Seven courses, mostly explosions

The publicly available course library comprises seven training courses, centred primarily on Houdini-based FX simulation workflows. The topics follow the usual suspects of production FX work. Destruction simulations, fire and pyro effects, fluids and cinematic-scale simulation setups appear throughout the material.

One of the larger training programmes is titled the Houdini Renascence Program. The course is described as a broad introduction to modern Houdini simulation workflows and FX techniques. Other courses focus on more specific simulation scenarios such as rigid body destruction, bridge collapse simulations and fluid-based commercial effects. Each course combines instructional videos with downloadable Houdini scene files. These files allow users to inspect how the simulations were built and configured. File packages are not small. Some course downloads reach approximately 28 GB, reflecting the inclusion of project assets and rendered simulation data.

Render passes included

One detail that may interest compositors more than simulation artists is the inclusion of rendered FX sequences. The downloadable course packages include multi-layer EXR sequences produced from the Houdini simulations. These sequences contain multiple render passes generated during the rendering process.

For compositing artists working in applications such as Nuke, this type of material is often more valuable than a finished render. Multi-layer EXR files can contain lighting passes, depth passes and simulation layers that allow the shot to be reconstructed during compositing.

Training assets with full render passes are relatively uncommon in publicly distributed course material. Many educational resources provide only flattened footage. Here the render layers allow users to rebuild the shot structure themselves. Lighting contributions can be adjusted, depth information can be used for atmospheric effects and elements can be recombined in different ways. In other words, the files behave more like a miniature production shot than a simple demonstration render.

Simulation topics

The simulation subjects covered in the courses reflect typical Houdini FX work used in film and commercial pipelines. Examples include collapsing bridge simulations, fire and explosion setups, liquid simulations and procedural destruction sequences.

These examples are built using Houdini’s node-based procedural system. Instead of keyframing every action manually, artists assemble networks of operators that control the simulation behaviour.

By including the full scene files, the courses allow users to inspect how these networks were constructed. Solver settings, constraint networks and simulation nodes remain visible inside the scenes. For technical artists or FX TDs this can often be the most instructive part of training material. Watching a tutorial is useful. Opening the scene file is usually more revealing.

A rare kind of shutdown

When subscription education platforms close, the usual result is a disappearing library. Content often vanishes along with the service that hosted it. Access expires, servers are switched off and the training material effectively evaporates.

The VFX School’s decision to release its full archive is therefore notable. It preserves the material and places it in the hands of the community rather than removing it from circulation. It is a quiet gesture, but a generous one. In an industry where learning resources can disappear overnight, leaving the lights on for everyone is a respectable way to exit.

Practical value for artists

From a production perspective the most useful part of the release may be the downloadable assets rather than the videos themselves. Large EXR simulation sequences and structured Houdini project files provide practical training material for both FX and compositing artists.

These assets allow experimentation with lighting passes, volumetric renders and compositing workflows using production-style data. Public FX footage often consists of pre-rendered stock clips with little structural information. The course assets, by contrast, contain layered render data and simulation outputs that can be studied and modified.

For artists learning how simulation renders translate into final composite shots, this kind of material can be extremely instructive. The release therefore functions both as a training library and as a small archive of practice assets.

https://thevfxschool.com/

The post VFX School Closes and Leaves the Lights On first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

LOOKSfilm brought Overmind Studios in as the sole VFX vendor for all six episodes of A World Divided, a historical drama following six real figures from World War II through the 1960s. The series blended archival material with recreated drama and moved across locations from New Mexico and China to Russia, Israel and French Algeria.

Shot in Germany, Belgium, Luxembourg, and Poland, the project demanded constant geographic reshaping and period-authentic cleanup to sell multiple continents and decades, all while working to rolling episodic deadlines.

Tobias Kummer was VFX lead on A World Divided at Overmind Studios. He supervised on set on key shoot days, built the project pipeline and delivered the work alongside André Gerhardt as a two-person VFX team. (Site | IMDB | Linkedin | Xing)

DP: How did you come onto A World Divided, and what was the overall scope?

Tobias Kummer: LOOKSfilm brought us in as the sole VFX vendor for all six episodes. We’ve worked with them before, so there was already trust there. The series was a historical drama following six real figures from World War II through the 1960s. It wove archival material together with recreated drama and jumped across locations from New Mexico and China to Russia, Israel and French Algeria.

André Gerhardt and I handled the VFX work as a two-person team, with me also covering on-set supervision on key days. Across the season, we delivered around 125 shots in total.

DP: What were the main categories of VFX work across the season?

Tobias Kummer: Most of the work fell into a handful of categories. The biggest chunk was geographic transformations and set extension work. The show was shot in Germany, Belgium, Luxembourg, and Poland, but it needed to represent locations across multiple continents, so we were constantly reshaping the world. We made the Pustynia Błędowska desert in Poland read as New Mexico in some scenes and as Israel in others. We replaced window views with believable locations and extended sets to fit both the period and the geography.

Period cleanup was the other constant. Removing anachronisms took up a steady portion of the workload, such as power lines, phone masts, wind turbines, modern signage, contemporary vehicles, basically anything that didn’t exist between the 1940s and 1960s. Some removals were straightforward paint-outs, while others required proper tracking and reconstruction for moving shots, especially given the anamorphic lens characteristics to account for.

Beyond that, there was a lot of environmental and atmospheric work. We added snow to summer shoots where winter was required, enhanced practical smoke and explosions with additional elements, and built the nuclear explosion sequence. There were also the smaller, problem-solving shots that always appeared on a show like this, including window inserts, moon replacements, damage work, retouching visible wig seams and removing on-set facilities from reflections. Many shots weren’t just one technique. A single exterior might have needed cleanup, set extension and atmos all layered in one comp.

DP: What constraints shaped the work most?

Tobias Kummer: What shaped the work was the schedule and the fact that we were a two-person team delivering an episodic shot count with rolling deadlines. Episodes moved into colour on a rolling basis, which meant we had to work sequentially and finish each episode properly before moving on to the next. We couldn’t cherry-pick shots across the whole season when we needed breathing room. There was a clear rhythm to the work. However, we had to maintain strict discipline.

“What shaped the work was the schedule, and the reality of being a two-person team delivering an episodic shot count with rolling deadlines.”

DP: How did the anamorphic photography affect VFX, especially cleanup?

Tobias Kummer: The anamorphic photography added complexity in places you might not expect. Distortion and breathing made tracking more challenging than it would have been with spherical lenses, particularly on handheld or more dynamic shots. We had everything from locked-off tripod plates to dolly moves, cranes, and handheld coverage, so even simple cleanup could have become complicated if you wanted it to sit cleanly while preserving the anamorphic feel.

DP: What did on-set supervision change for you in practical terms?

Tobias Kummer: On-set supervision helped in practical ways. Sometimes it was about making sure we had clean plates and tracking markers. At other times, it was flagging modern details before they became post problems. Or it was a small camera placement decision that saved hours of rotoscoping later. We had an initial planning phase with the DOP and directors in May 2023, and on-set supervision ran through the shoot from May to July.

Then there was a long gap. We didn’t receive VFX plates until May 2024, nearly a year after wrapping, because production was working through the edit in the meantime. That delay reinforced something I always try to stress. Write everything down during on-set supervision. No matter how certain you are that you’ll remember something, you won’t a year later. Good notes made it possible to pick the work up again without having to guess.

DP: How did the schedule work once plates started arriving?

Tobias Kummer: Once plates started arriving, we had roughly two weeks per episode, regardless of complexity. VFX production ran for over 12 weeks across the six episodes. Shot complexity varied widely. Some cleanups were quick, while sequences with multiple iterations took longer, but the template system helped. The first shot of a new type might have taken time to establish the approach, but similar shots afterwards moved much faster.

Approvals were efficient. Most shots were approved in versions 1 or 2, and only a handful needed additional revisions. When revisions did happen, they were usually about creative direction rather than technical fixes, which came back to communication and understanding intent early.

DP: How did you split responsibilities as a two-person team?

Tobias Kummer: André and I divided the work in a clear way, but we kept shot ownership flexible. I handled on-set supervision, project planning, client communication and pipeline setup, and I also did shot work as well. André focused on shot execution and handled the motion graphics. We didn’t rigidly assign shot types. It was more fluid. Whoever was free took the next thing that needed doing. Because we were working remotely, communication was essential. We stayed connected throughout the day, and if one of us got stuck, a quick call and a screen share often solved what might have taken hours otherwise in minutes.

DP: What did you use for project management?

Tobias Kummer: For project management, we used Ramses by RxLaboratory. That was our central truth for what was in progress, what was out for review, and what was approved.

I wanted to avoid the usual folder wrangling that came with episodic work, so I built a small Fusion plugin that connected directly to the Ramses API. In practice, it meant that when you opened a shot, the setup was already done. Correct plates, correct naming, correct version number, correct saver paths, and comp settings that matched the show spec. It wasn’t glamorous work, but it prevented mistakes and kept us moving. Templates were the other foundation. I kept them rigid where mistakes were expensive and flexible where a shot needed freedom.

DP: Can you break down the plate specs and colour pipeline?

Tobias Kummer: Plates came from Avid as 4K MXF containers in DNxHR HQX 12-bit with a 1.8 anamorphic squeeze, in ARRI Wide Gamut 4 and LogC4.
We composited in scene-referred linear, so the input linearisation was standardised. Output was standardised too. For review, we rendered previews in Rec.709 using the client reference LUT, so the work looked close to the intended look. Finals went out in ARRI Wide Gamut 4 and LogC4 so the grade could treat VFX shots like any other plate. The LUTs were helpful for context, but we couldn’t bake them into the finals without limiting the colourist’s downstream options.

DP: Why Fusion Studio, and what tools mattered most?

Tobias Kummer: All compositing happened in Fusion Studio, because it was what we knew and because the node-based approach was genuinely flexible under episodic revision pressure. When notes came back, you could restructure a comp non-destructively. Insert processing, reroute parts of the tree, try alternatives, without rebuilding from scratch.

Fusion’s tracker and planar tracker held up well on the anamorphic plates, which mattered for both cleanup and set extension work on moving shots. Magic Mask helped as well. It wasn’t perfect in every case, but it saved us more than once from manual roto. We supplemented with a handful of Reactor tools and some custom tools we’d built, but the aim was to rely on Fusion’s core toolset and maintain a consistent pipeline for broadcast delivery.

We also used Blender for 3D elements and set extension geometry, EmberGen for pyro and atmospheric simulations, SynthEyes for more complex camera solves and Affinity Photo for detailed paint work. All rendering was done locally rather than on a farm, which gave us more control and faster iteration.

DP: Pick one shot that best represented the season. What was it, and how did you approach it?

Tobias Kummer: If I had to pick one shot that summed up the work, it was a vast desert establishing shot where we turned the Polish Pustynia Błędowska into an Israeli desert landscape. The plate was shot on a crane mount, so there was a slight shake, and the camera racked focus between foreground and background. In the original plate, you could see the forest at the edges of the location, which didn’t sell the intended geography at all.

This was a case where on-set supervision paid off. Had we gone with the initial framing, we would have had the actors’ heads and the car crossing the horizon line, which would have meant rotoscoping them out to replace the background. I asked for a slight adjustment to the camera placement so everything stayed below the horizon. That saved hours of roto later and made the background replacement much cleaner.

In Fusion Studio, we used a few point tracks to stabilise and reapply the move, and we paid close attention to the rack focus because anamorphic lenses can shift and breathe, causing the background to drift if you ignore it. We built a matte painting from Israeli desert reference photos for the mountainous backdrop. We added blowing sand using an EmberGen simulation we had created and reused across multiple desert shots, and we added heat haze with a simple Fast Noise feeding a Displace node. The focus rack was matched by hand with keyframes. The shot was approved in version two.

DP: What were the key lessons you took from delivering this as a small team?

Tobias Kummer: If I had to distil it down to what kept us on time while maintaining quality, it came down to a few habits. First, learn some scripting, Python or whatever your tools support, and automate the repetitive, error-prone parts of the job. The time savings compounded quickly, especially for a small team, and you don’t need to build for massive scale to benefit.

Second, organise everything and document it. When you’re juggling episodes, you can’t waste time on version mix-ups or folder hunting, and the year gap between shoot and plate delivery made that even more important. Lastly, don’t waste time being stuck. Fresh eyes solved problems faster and a quick screen share could save hours. And honestly, sometimes the best decision was to stop and sleep. If you weren’t making progress, you’d often solve it faster in the morning.

The post A World Divided: Shaping a Global WWII Epic at Overmind Studios first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

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

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

USD and Hydra workflow updates

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

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

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

XPU feature coverage expands

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

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

Shading system refinements

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

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

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

Geometry and motion updates

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

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

Volume rendering and lights

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

Incremental

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

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

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

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

For those who don’t know the event: FMX is an annual conference in Stuttgart focused on animation, VFX and digital media production. It connects studios, software vendors and production teams across features, commercials and games. Details and tickets are available via FMX.

FMX 2026 has confirmed new sessions covering large-scale feature VFX, stylised feature animation and high-end commercial character work. The programme additions include speakers from Wētā FX, Pixar and Illogic Studios, alongside new Premium Partners AMCRS, Accenture Song VFX and AYON. The event will take place on site from May 5 to 7, followed by online and on-campus sessions on May 8, with on-demand access running from May 9 to June 9. Early Bird ticket options are available until March 20 via the FMX ticket shop.

Pandora, fire and 3,100 shots

Senior VFX Supervisor Eric Saindon and VFX Supervisor Sam Cole from Wētā FX will present work from Avatar: Fire and Ash. According to FMX, the studio delivered more than 3,100 shots for the film.

The presentation will cover the integration of extensive native stereo photography with CG environments, fully digital performance captured characters and physics based coupled effects simulations. Native stereo photography refers to imagery captured simultaneously for left and right eye views, rather than converted in post. Coupled effects simulations describe interdependent simulations, for example fire interacting with wind and character motion, solved together to maintain physical consistency.

Saindon and Cole will also discuss a new tool called Kora, developed to provide more art directable fire. FMX states that Kora was created to allow greater control over flame behaviour while retaining physically based characteristics. No further technical specifications have been released at press time.

Stylisation as pipeline logic

In the Feature Animation track, Visual Effects Supervisor Beth Albright from Pixar will present Hoppers. The session is titled Stylization as a System.

The session will address how the team preserved physical realism to maintain emotional stakes while shaping surfaces for clarity and appeal. This includes coordination across modelling, animation, simulation and lighting.

A wolf, a supermarket and feature grade craft

The Shorts track will include a presentation by animation director Benoit Bargeton from Illogic Studios on the Intermarché commercial Le mal aimé. The campaign features a wolf attempting to gain the trust of other animals in the forrest by becoming vegetarian. The film went viral globally, and you propaly have already seen it.

Bargeton’s talk will focus on how feature film animation was achieved in a commercial context. This includes artistic and acting choices, as well as technical decisions supporting those directions. Cross department collaboration between modelling, rigging and animation will be addressed.

Commercial schedules typically impose tighter timelines and smaller teams than feature productions. FMX states that Illogic Studios adapted its workflow and resources to deliver a project of this scale. Specific software, renderers or proprietary systems used have not been disclosed in the announcement.

Premium Partners on the floor

FMX has also announced three Premium Partners.

AMCRS, the Animation Media Creators Region Stuttgart network, represents more than 30 VFX providers, animation studios, game developers and interactive media companies, along with six colleges. The network was initiated by MFG, the regional media and film society.

Accenture Song VFX is an award winning team guiding projects from script and concept art to final delivery. FMX states that the team has earned nine Emmy nominations over the past six years and secured an Emmy Award last year for work on HBO’s The Penguin. No additional production credits are listed in the announcement.

AYON is presented as a production backbone for animation and VFX, combining pipeline and production tracking with review, planning, scheduling and resource management. Producers, supervisors, pipeline TDs and developers use AYON to unify creative data and automate handoffs. At FMX, AYON will host talks, demos, panels and Q&As in its dedicated room. The focus will include review, scheduling and resource planning updates, roadmap insights and practical studio case studies.

Many additional sessions are still to be announced!

The post FMX 2026 spotlights fire, fur and pipelines first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: The Pixel Farm develops PFTrack, a node-based 3D camera tracking and photogrammetry system used in VFX, virtual production, and survey-driven pipelines. It exports to DCC tools including Autodesk Maya and integrates LiDAR and image based reconstruction.

The Pixel Farm has released PFTrack 26.02, a point update to its camera tracking and photogrammetry software. The release focuses on export reliability, Survey Solver behaviour and data validation rather than new solver technology. According to the published change list, the update introduces improvements to Maya export scripts, OBJ texture handling, LiDAR import logging and node connectivity within the Survey Solver. It also resolves a keyboard shortcut conflict in the Orient Camera node.

Maya export scripts corrected

The updated Maya export scripts now automatically parent background image planes to cameras on export. This addresses a long standing friction point in matchmove handoff. Previously, depending on scene configuration and export path, artists could end up manually re-parenting image planes inside Maya to maintain alignment between the solved camera and its background plate. The revised script automates this relationship at export time.

For tracking teams delivering camera solves into Maya-centric pipelines, this reduces post-export clean-up and the risk of misalignment during layout or scene assembly. The vendor statement does not detail changes to other DCC export scripts.

Survey Solver and OBJ texture loading

PFTrack 26.02 updates the way OBJ mesh textures with numbered filenames are loaded into the Survey Solver node. OBJ sequences or assets that rely on incrementally numbered texture files will now load correctly when imported into Survey Solver. The official notes do not specify naming conventions, but refer to numbered filenames in general terms.

For facilities using photogrammetry meshes or survey derived assets with multiple texture tiles, correct automatic loading reduces manual reassignment inside the node graph. It also limits the possibility of mismatched textures during camera solve refinement. The change appears limited to texture loading behaviour inside Survey Solver and does not reference modifications to the OBJ importer elsewhere in the application.

LiDAR import logging added

The update adds explicit error logging when importing corrupted or incomplete LiDAR survey data files. PFTrack supports LiDAR survey data within its camera-solving and scene-reconstruction workflows. In previous versions, incomplete or damaged files could fail during import without detailed diagnostic output.

With 26.02, the system now logs errors when such data is detected. The vendor documentation does not describe the logging format, verbosity level or where logs are written. It does state that error logging is triggered when corrupted or incomplete LiDAR files are imported.

Photogrammetry node connectivity fixed

A further fix addresses connector logic in Studio and Enterprise editions. Photogrammetry nodes can now be connected to secondary inputs of the Survey Solver where appropriate. The official wording specifies that this applies to Studio and Enterprise only.

This suggests that earlier builds restricted valid node graph connections in certain configurations, potentially limiting more complex photogrammetry driven solves. The updated connector logic restores the ability to route photogrammetry outputs into secondary Survey Solver inputs when supported by the node’s design.

The vendor has not published technical detail about which specific input sockets were affected or how the internal validation rules have changed. Not independently verified at press time.

Facilities using advanced node graphs that combine survey data, image based reconstruction and manual constraints should review existing templates to confirm expected behaviour after updating.

Scope and positioning

This release does not introduce new solver models, GPU-acceleration changes, or major UI revisions. It is positioned as a maintenance and workflow refinement update. The focus remains on export reliability, data validation and node graph correctness. For studios that rely on PFTrack for camera tracking, survey alignment and photogrammetry reconstruction, these adjustments address specific operational irritations rather than expanding feature breadth.

PFTrack is available in three editions. PFTrack Solo is priced at £699 for a permanent licence. PFTrack Studio is offered on a rental basis, with pricing listed at £59 for a five day rental period. PFTrack Enterprise pricing is available on request from The Pixel Farm. As always, facilities should confirm current licensing terms and support options directly with their vendor before procurement.

As always, new tools and updates should be tested in controlled conditions before being introduced into active production pipelines.

The post PFTrack update tidies Maya and LiDAR workflows first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Katana from Foundry is a look development and lighting application used in feature animation and VFX. It sits downstream of asset creation DCCs and upstream of final rendering, managing complex scene assembly and renderer integration.

Foundry has released Katana 9.0, introducing a new USD centric framework called UsdSuperLayer alongside new USD lighting and material nodes and early support for Hydra 2 in the Viewer. The company positions UsdSuperLayer as a foundational architectural change for USD workflows inside Katana. According to Foundry’s official release, UsdSuperLayer is designed to allow artists and TDs to create and edit any USD prim directly within Katana, with USD treated as the authoritative scene description.

UsdSuperLayer at Node Graph level

The UsdSuperLayer node is designed to expose the incoming USD stage and allow users to create or edit prims directly on its authoring layer. According to Foundry’s documentation, this layer then feeds back into existing USD native Katana workflows.

The purpose is to form a basis for future specialised and custom tools built around a USD native context, with scalability and flexibility as design goals. UsdGaffer is described as a derived example of such a tool. UsdSuperLayer and its derivatives can be edited directly through Katana’s Python API. Foundry states that USD is treated as the “source of truth” for all properties serving as UI elements.

A key parameter is primPath. This indicates the path on which the node will create or edit prims. If primPath is changed, any created prims or edits are transferred to the new path. Foundry also states that primPath assists performance by masking stage composition to that path. Users are therefore advised to scope the scene to as minimal a section as possible to attain best performance.

By default, primSpecifier is set to Define, allowing prim creation on new paths. Override and Class specifiers are also available via a dropdown. This menu is customisable using Python Context Menu Plug ins. Documentation is provided under USD Processing Engine and UsdSuperLayer in the developer guide.

In the initial release, the context menu supports adding lights by category, adding light filters, adding Rig Xform, Scope and Material prims, renaming locally created prims, and deleting prims or overrides. Downstream UsdSuperLayer nodes cannot fully remove upstream created prims, only their own authored opinions.

Light creation is driven by discovery through the SdrRegistry for entries with light as context. Associated API schemas, such as MeshLightAPI and VolumeLightAPI, are auto applied using apiSchemaAutoApplyTo metadata. Foundry states this allows Katana to remain up to date with renderer specific choices while treating USD as the universal source of truth for registered prim data.

If a light shader defines a Category, a custom menu is generated grouping registered lights by category. By default, the light creation menu appears only on UsdSuperLayer and UsdGaffer nodes.

Light filters are created as child prims of selected light prims, with relationships set automatically when possible. If the parent is unsuitable, the filter is created at the same hierarchy level without automatic relationship creation. Deleting a filter removes references from immediate ancestors only. Relationships outside the filter hierarchy remain.

The parameter panel is populated based on the currently selected prim in the tree view. At present, it supports single selection and displays the first selected item if multiple prims are selected.

Parameter display is handled by Parameter Handler Plug ins. In Katana 9.0, three are shipped: Properties, Metadata and Shader handlers. The Properties handler displays API and Typed schemas on the prim, including locally and upstream authored values via the Stage Parameter Policy. Locally authored attributes not part of current schemas are also shown. The Metadata handler exposes prim level metadata editing. The Shader handler appears if a shader id property is detected and queries the SdrRegistry for matching shader definitions.

A showIncomingScene toggle exposes upstream created prims for downstream editing. Visual indicators in the tree view include grey U for unchanged prims, yellow E for edited prims, and green N for locally created prims. This provides a high level overview of authored changes at node level.

Filtering is supported through setFilteredConcreteSchemas and setFilteredApiSchemas methods, which restrict the tree view to prims matching defined schema filters. If filters are empty, all prims are shown.

A SyncSelection toggle mirrors behaviour found in GafferThree, with off, out and in or in out modes. By default, it is set to in out and can be changed in preferences.

Transformations can be applied to Xformable prims via Viewer manipulators. Transformations use a new SubEngine feature for the LayerEngine. This relies on attributes stored on the prim using the FnSubEngineAPI multi apply schema, included with FnUsdShim. C plus plus utilities and Python bindings via usg.FnSubEngineAPI are provided.

SubEngines allow procedural on demand interpretation of the incoming stage on each traversal. The Engine system is extensible, comparable to the Geolib Op system, and documented in the developer guide under Usd Processing Engine and Engines.

To transform incoming prims, MakeInteractive must be set to Yes. A right click option allows batch modification of this value. Locally created light prims default to MakeInteractive set to Yes.

Visibility can be toggled in the tree view, setting USD visibility on the prim. Four states are defined: incoming, local visible, local invisible and inherited invisible. The tree view toggle cycles between incoming, local invisible and local visible for efficiency.

UsdSuperLayer and its derivatives support copy and paste of prims within and across nodes. Name clashes are resolved through enumeration. When copying edited prims, only authored edits are copied.

A tab system has been added to the parameters of UsdSuperLayer and derived nodes, with each tab representing a ParameterHandlerPlugin whose label and ranking priority can be adjusted.

UsdGaffer specialises for lighting

UsdGaffer is described as the first specialised node derived from UsdSuperLayer, focused on lighting workflows. Its primPath defaults to /lights, causing new light prims to be created under a /lights Scope prim, for example /lights/distantlight1.

The tree view applies filters to show only prims using specific Typed and API schemas relevant to lighting. Typed schemas include UsdLuxBoundableLightBase, UsdLuxLightFilter, UsdGeomXform, UsdLuxNonboundableLightBase, UsdLuxPluginLight and Scope. API schemas include UsdLuxLightAPI, UsdLuxVolumeLightAPI and UsdMeshLightAPI. Context menu options are inherited from UsdSuperLayer but filtered for lighting tasks. In addition to light and filter creation, Add Rig Xform and Add Scope options are provided. Pressing R in the tree view creates a Rig.

UsdGaffer introduces a linking tab for creation and editing of light and shadow linking relationships. Incoming upstream linking properties are also displayed. Foundry notes that in USD defaults, includeRoot in light and shadow linking collections is active. Linking collections can be edited via relationship or membership expressions. If includeRoot is enabled or includes or excludes paths are specified, membershipExpression mode is ignored. Collections can be inspected in the Scene Explorer by activating the Collections view tab and selecting the light’s Collections working set.

UsdMaterial as lightweight tool

Katana 9.0 adds a UsdMaterial node with three modes: create, edit shader and edit interface. Create mode generates a single shader material under the prim path defined by materialPrimPath. Edit shader mode targets an existing Shader prim defined in shaderPrimPath, populating incomingShaderNode and shader properties from the SdrRegistry. Edit interface mode targets an existing Material prim whose contained shader properties have been promoted to its public interface.

Foundry explicitly states that UsdMaterial is not a substitute for a future look development toolset in the USD native space. It is described as a lightweight tool to create single shader materials and edit existing Material setups on an individual prim basis.

Hydra 2 rendering behind an env var

Katana 9.0 includes an initial implementation of Hydra 2.0 rendering. This workflow is gated behind an environment variable. Setting KATANA_ENABLE_HYDRA2 to 1 enables two new features: the Hydra 2.0 Viewer tab and the Hydra Scene Browser tab.

Foundry describes this as a first glimpse of what an end to end Hydra rendering solution could look like in Katana, from viewport to final frame image. The Hydra 2.0 Viewer tab renders only Hydra 2.0 data. It differs from the existing Viewer tab and can be used as a quality check to compare rendered images to the Hydra 1 viewport.

In this iteration, USD stages render in the Hydra 2.0 viewport but not through expansion based loading. Some Geolib attributes also render, but Foundry states that parity with Hydra 1.0 has not yet been achieved.

The implementation for rendering Geolib data derives from an internal library, FnHdBridge2.0, which will not be publicly available. Default lighting is not included in the Hydra 2.0 Viewer, although default materials are present and can be overridden by assigned materials.

To compare images between viewerports when rendering Geolib attributes, default lighting and basic material toggles must be disabled in the Hydra 1 Viewer. For USD data, a GafferThree must be placed in the scene to render basic materials.

A shim layer has been implemented to allow studios to write their own SceneIndexFilters. This requires building Katana’s FnUsdShim against a studio’s own USD version. Instructions are located under the FnUsdShim directory in the Katana installation. Foundry recommends that users with custom render delegates begin this process.

Hydra Scene Browser for debugging

An experimental Hydra Scene Browser tab accompanies the Hydra 2.0 Viewer. It displays the unflattened Hydra scene, similar in concept to scene graph navigation in usdview, but with the added ability to show Geolib data being fed into Hydra. Its stated intention is to help debug scenes prior to final frame rendering.

In this iteration, the Hydra Scene Browser does not show USD data being fed into Hydra. Foundry indicates that this will be updated in later iterations.

The tab contains three panes. The left pane lists Hydra prims within the selected terminal scene index in a tree view. The middle pane shows Hydra prim data sources associated with the selected prim, expandable to leaf level. The right pane displays source values for the selected data source.

Additional controls include Choose Scene Index, Inputs for selecting upstream scene indices, Show Notice Logger for recording dirtied, added, removed or renamed events, and Write to file, which exports the scene to a text file and reports its location in the Katana terminal.

VFX Reference Platform CY2025 and USD update

Katana 9.0 updates to VFX Reference Platform 2025. Listed versions include GCC 11.2.1, glibc 2.28, Visual Studio 2022 toolset, Windows SDK 10.0.22621, Python 3.11.11, Qt 6.5.3 modified, PySide 6.5.3, OpenEXR 3.3.2, OpenSubdiv 3.6.0, Alembic 1.8.8, OpenColorIO 2.4.2, Boost 1.85.0, Intel TBB 2021.13.0, OpenVDB 12.0.0 and NumPy 1.26.4. Outside the VFX Reference Platform, Katana 9.0 updates to USD 25.08.

Studios upgrading from earlier Katana versions will need to validate plug-ins, render delgeates and pipeline integrations against these updated dependencies. As always, new tools and innovations should be tested in your own pipeline before use in production.

// https://campaigns.foundry.com/products/katana/whats-new

The post Katana 9 deepens USD and previews Hydra 2 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Export Helper Pro is a Blender add-on sitting at the very end of asset creation, handling outbound exports to game engines like Unity, Unreal and Godot, with presets that reduce clicks and regret. It lives alongside Blender’s native exporters and does not replace them.

A familiar itch

A newly released free Blender add-on called Export Helper Pro aims to remove friction from one of the least glamorous but most repeated tasks in realtime asset production: exporting meshes out of Blender and into a game engine. The tool is authored by Michael Bridges and distributed via Gumroad as a free download. According to the author, the current version is rebuilt for Blender 5 and is open for public testing.

The add-on has attracted attention partly because of its origin story. Bridges references an abandoned internal Blender plug-in originally developed by Embark Studios, the studio behind Arc Raiders. That internal tool has not been updated for over six years. After examining its code, Bridges revisited their own earlier export tool and rebuilt it with a broader scope.

This context matters mainly as motivation. Export Helper Pro is not a continuation of Embark’s tool, nor is it affiliated with the studio. It is a separate project, written independently, and positioned as a general-purpose utility rather than a studio-specific pipeline component.

What the add-on actually does

Export Helper Pro adds a dedicated Export tab to Blender’s right-hand N-panel in the 3D Viewport. From there, users can export assets using a small set of clearly scoped options without navigating Blender’s standard export dialogs each time.

The core function is batch-style exporting based on context. Users can export all objects in a scene, only selected objects, or one or more named collections. This is intended for modular asset workflows where collections represent discrete export units.

Supported export formats include FBX, glTF and OBJ. FBX is positioned for Unity and Unreal workflows, while glTF is intended for Godot. OBJ is included as a fallback for maximum compatibility, though the author notes it exposes fewer options than the other formats.

Export Helper Pro does not introduce a new file format or a custom exporter. It wraps Blender’s existing exporters and exposes commonly used settings in a single panel. As such, the quality and limitations of the output are those of Blender’s native export code.

Selection, collections and intent

One of the add-on’s central features is collection-based export. Instead of exporting an entire scene or manually selecting objects each time, users can designate a collection and export it directly. This allows assets to be structured semantically in Blender and exported accordingly.

In a demonstrated example, a helicopter asset consisting of 52 objects is exported as a single FBX file by selecting its parent collection. The resulting file contains all objects merged into a single export operation. This behaviour is consistent with Blender’s standard FBX exporter and does not automatically instance repeated meshes.

The author explicitly notes that this is not a substitute for proper instancing or asset optimisation. Export Helper Pro does not analyse meshes for duplication or attempt to restructure assets. It simply automates the act of exporting what the user has already organised.

Origin handling and viewport colour conversion

Among the exposed options is the ability to centre object origins before export. This can be useful when assets need consistent pivots for placement in an engine. The centring operation is applied at export time and does not permanently modify the Blender scene, based on the information provided.

Another option is conevrsion of viewport colours to exportable colour data. This is intended for workflows where meshes are coloured directly in the viewport rather than via materials. When enabled, these colours are baked into the export so they remain visible in the target engine.

Armatures, textures and embedded data

Export Helper Pro includes toggles to include armatures when exporting animated rigs. This aligns with standard FBX and glTF export options in Blender and does not introduce custom rig handling. The add-on also exposes options to embed textures directly into FBX or glTF files. Embedded textures can simplify handoff at the cost of larger file sizes and reduced flexibility. As with other options, this relies on Blender’s built-in exporters and inherits their constraints.

Installation and availability

The add-on is distributed via Gumroad here. It is currently free to download. Installation follows standard Blender practice. Users download the add-on archive, open Blender Preferences, choose to install from disk, and enable the add-on. Once installed, the Export tab appears in the 3D Viewport sidebar.

The author states that the tool has not been tested in every scenario and invites users to report bugs or suggest improvements. This positions the release clearly as an open testing phase rather than a finished commercial product.

Engines and expectations

The add-on explicitly targets Unity, Unreal and Godot. These targets are defined by export format rather than deep engine integration. There is no engine-side plugin, no automated import configuration, and no engine metadata generation. For Unreal and Unity, FBX is the intended format. For Godot, glTF is recommended. This reflects common practice rather than bespoke support.

What it is not

Export Helper Pro does not claim to be a pipeline manager, asset tracker, or versioning system. It does not replace Blender’s exporters, and it does not attempt to standardise asset naming or directory structures. It also does not attempt to solve instancing, LOD generation, collision mesh creation, or any of the other problems often bundled into export tools by marketing departments.

Its stated goal is narrower: reduce repetitive UI actions and make exports faster and more predictable.

Sensible expectations

For asset artists working solo or in small teams, Export Helper Pro offers a way to shave time off repetitive exports without introducing heavy infrastructure. For larger studios with established pipelines, it is unlikely to replace custom tooling. Its value lies in being small, direct and honest about its scope. It does one thing, and it does it in front of you, in a panel you can see.

As always, new tools and workflow changes should be tested carefully before being introduced into production environments.

// Export Helper Pro Gumroad page
// https://michaelbridges.gumroad.com/l/ExportHelperPro

The post One click exports and zero patience for menus from Blender to Unreal, Unity and more. first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Adobe Animate is Adobe’s 2D animation and interactive authoring tool, used for vector animation, rigged characters, and legacy Flash-style pipelines inside the wider Adobe Creative Cloud ecosystem.

What actually happened

Following several days of confusion, contradictory reporting, and one notably premature obituary, Adobe has formally clarified the status of Adobe Animate. The application is not being discontinued. It is not being removed. It is not being sunset on a fixed date. Instead, Animate has been placed into what Adobe calls maintenance mode, indefinitely.

Adobe updated its official Animate knowledge base article on February 4, 2026. The wording is explicit and repetitive, likely by design. Adobe states that Animate will continue to be available to both existing and new customers, with no deadline for removal. The company also states it has no plans to discontinue or remove access to the application. This represents a change from an earlier customer email that suggested a clearer end-of-life trajectory. Adobe now says that information is no longer valid and that the position has changed.

The distinction matters, particularly for studios and freelancers still shipping broadcast graphics, educational content, and lightweight 2D animation using Animate-based pipelines.

Maintenance mode, defined precisely

Adobe’s definition of maintenance mode is narrow and unambiguous. Animate will continue to receive security updates and bug fixes. It will continue to be supported. It will remain downloadable for new users. It will continue to open existing projects.

It will not receive new features.

Adobe repeats this point multiple times in its documentation. There is no language about feature backlogs, paused development, or future reassessment. Maintenance mode is described as indefinite. This is not an uncommon status for mature tools with stable user bases, but Adobe rarely uses such blunt phrasing for Creative Cloud applications.

Access to existing content

One of the central concerns raised by users was long-term access to authored content. Adobe explicitly addresses this. The company states it is committed to ensuring Animate users retain access to their content regardless of future changes in development status.

This applies to individual subscribers, small businesses, and enterprise customers. Adobe does not describe any technical mechanisms beyond continued availability of the application itself. No migration tools or export guarantees are mentioned. There is also no mention of file format deprecation or conversion paths. Animate documents remain Animate documents.

The backlash and the cleanup

The clarification follows widespread reporting that Animate was being discontinued outright. Digital Production published an article stating that Adobe had pulled the plug on Animate. That headline was based on earlier information provided by Adobe and has since been overtaken by events. The company’s own documentation now contradicts that earlier messaging.

Adobe pulls the plug on Animate at last

Adobe acknowledges this directly, stating that what it initially shared has changed. This is a rare case where the vendor explicitly reverses a communicated product trajectory, rather than quietly rephrasing it.

Implications for production users

For production artists, the practical outcome is stability without evolution. Existing pipelines can continue to function. Security vulnerabilities should be addressed. Bugs may still be fixed, though Adobe does not define the scope or frequency. There will be no new animation tools, no workflow improvements, and no modernisation beyond what is required to keep the application operational.

For some teams, this is acceptable. For others, it confirms the need to plan exits, even if no forced deadline exists. Animate becomes a frozen dependency, not an actively developed one. The key point is that this decision is now explicit, not implied.

// Adobe Animate maintenance mode documentation
// https://helpx.adobe.com/animate/kb/maintenance-mode.html

The post Animate re-animated first appeared on DIGITAL PRODUCTION and was written by Bela Beier.