For those who don’t know the tool: SplatTransform is a CLI and library that converts and edits Gaussian splats for pipelines that end up in SuperSplat or real-time runtimes. It ships as a package for Node.js and also runs in browser contexts.

What 2.0 actually changes

SplatTransform 2.0.0 adds a sparse voxel grid plus exterior fill for nav simplification. That pushes the tool beyond file shuffling and into spatial reasoning you can use for scene cleanup and interaction prep, especially in Gaussian Splatting workflows. Or, you know, previews.

Two new GPU-based processing actions land alongside the voxel pipeline: filterFloaters and filterCluster. They target unwanted bits that do not belong to coherent spatial clusters, and they run on the GPU path.

Floors, clusters, and tighter crops

2.0.0 adds floor fill, voxel-level cluster flood, and tighter voxel crops. The net effect is more structured scene operations, built on the voexl representation rather than only per-splat attributes. The release also refactors logging and progress reporting, and the CLI now reports peak memory usage in its final summary line. That is small, but it is the kind of small that saves time when you run batches overnight, or the whole studio is computing in timewarp.

Less native baggage, more inputs

The tool replaces meshoptimizer with a lossless coplanar-merge pass. That removes a native dependency from the meshing side of the pipeline and keeps the operation lossless by design. SplatTransform also accepts http and https URL inputs in the CLI, so you can feed remote assets directly without a manual download step. PlayCanvas also updates the dependency on supersplat-viewer as part of the 2.0.0 release work.

Formats, install, and the boring but important bits

The repo documents claim support for PLY, Compressed PLY, SOG, SPZ, SPLAT, KSPLAT and LCC, plus write support for PLY, Compressed PLY, SOG, SPZ, GLB, CSV, HTML Viewer, LOD and Voxel formats. So, everything we ever heard of as formats for splats. Install uses npm with a global command, and there is also a Docker backend guide for server-side use. Which we will be testing soon, and if you don’t hear from us again, something exploded.

The code is MIT-licensed and published as an open-source package, which usually means it’s free to use, but any production adoption still deserves a legal and pipeline check. New tools and innovations should always be tested before use in production, preferably on the worst shots and the messiest captures first.

https://github.com/playcanvas/splat-transform/releases/tag/v2.0.0

The post PlayCanvas updates SplatTransform to 2.0 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Fallout Season 2 asked for more scale and less forgiveness. Rise delivered 244 shots across seven episodes, with the heaviest work landing early, and kept two sites moving as one crew. The playbook stayed familiar, but the demands went feral: closer cameras, heavier mechanical interaction, city-wide procedural destruction, and sand-driven reveals that punished every shortcut.

Fallout!

Andreas Giesen is a Rise VFX Supervisor with a Houdini-heavy background and a track record on FX-intensive shows. He is credited by the Television Academy for a 2024 Primetime Emmy nomination for Fallout in “Outstanding Special Visual Effects in a Season or a Movie”. His Rise FX credits include serving as the studio VFX Supervisor on The Matrix Resurrections, as well as work on has worked on X-Men, The Matrix, The Last of Us and the various entries in the Marvel universe, among others.

DP: When we last spoke about Fallout Season 1, you worked on a show that combined large-scale environments, destruction, Vertibirds, Power Armour, and complex integration work. On Season 2, where did the challenge shift?

Andreas Giesen: The challenge shifted purely to massive scale and extreme scrutiny. In Season 1, we were establishing the rules. In Season 2, we took those rules and stress-tested the pipeline. We had a huge jump in scale, like procedurally destroying the entirety of Los Angeles or dealing with the multi-layered sand reveals of Area 51, but we were operating with roughly the same core team size. Brute forcing was not an option. We had to lean heavily on our procedural setups and the USD foundation we built in Season 1 just to survive the shot count.

DP: Did Season 2 feel like a continuation of an established visual language, or more like a technical reset because the demands had changed so much?

Andreas Giesen: Artistically, it was a continuation. We already had that shorthand with Jay Worth and Jonathan Nolan, so we knew what that tactile, grounded Fallout look felt like.

Technically, though, it was a massive upgrade. We did not throw everything away, but we had to rebuild or upgrade many assets because the camera was suddenly much closer or the interactions were much more complex. The Vertibird docking with the Caswennan, for instance, required a whole new level of mechanical detailing that just was not necessary in Season 1.

DP: RISE delivered work across several episodes, with particularly dense work in some of the early ones. How did that affect the structure of the production on your side?

Andreas Giesen: We delivered 244 shots spread across seven episodes, but the bulk of the heavy lifting hit right in episodes 2 and 3. To keep the chaos in check across our Berlin and Stuttgart offices, we operated as one unified team. We ran single VFX dailies so it never felt like two separate facilities. We relied heavily on our in-house production management tool, risebase 3, to keep the sites synced.

Honestly, a massive shoutout to our VFX Producer Annelie Dangel , Production Manager Scott Kunysz, and the coordination team. They were the real firewall keeping the production structured while the artists dealt with the pixel pushing.

DP: You mentioned that the work was divided into more specialised teams. How exactly did that division work in practice?

Andreas Giesen: Instead of splitting the work purely by department, where an asset just gets tossed over the wall, we built small, cross-functional strike teams dedicated to specific sequences. For example, we had a dedicated Area 51 team and a completely separate Caswennan team.

Each of these pods basically consisted of one layout artist, one lighting artist, and an FX artist if the sequence required it. This meant the artists became absolute experts on the continuity, lighting setups, and specific technical hurdles of their assigned sequence, rather than constantly context switching between different environments.

DP: The Caswennan ship has become even more important in Season 2. At what point does a hero asset like that stop being “just a vehicle”?

Andreas Giesen: When you get that close, it absolutely stops being just a vehicle and becomes a massive flying set. The layout has to treat it like a static environment just to block the shots, especially when we are tracking complex character animation and heavy mechanical interactions, like the Vertibird docking, directly onto the hull.

DP: What were the rebuild decisions under the hood?

Andreas Giesen: It was actually a really interesting round-trip process. Since the flight deck scenes were shot on a virtual stage, we received the Unreal Engine asset from production as our starting point. Funny enough, that Unreal asset was originally based on our own Season 1 dirigible model!

So, our CG team, led by Jenny Leupold , took the updated proportions from the virtual stage, brought the asset back into our pipeline, and completely re-engineered all the high-res cinematic details and shading quality.

DP: How did you approach balancing a highly detailed close-up asset with practicality for layout, lighting, and shot iteration?

Andreas Giesen: We relied heavily on our USD workflows and instancing. We had to design functional heavy hydraulics and complex mechanical joints so the lifting arm physically made sense up close, but we could strip that back or use lighter variants for wider layout tasks so the scene would not grind to a halt in the viewport.

DP: In Season 2, there seems to have been a stronger overlap between physical production, virtual production, scans, and final CG. How did that affect the pipeline in concrete terms?

Andreas Giesen: It meant we lived and breathed LIDAR. For the Area 51 reveal and the hangar sequences, production gave us incredible plates and highly accurate scan data. Having that precise spatial data was the only way to guarantee a seamless transition from the practical sets into our massive digital extensions. Once that data enters production, it locks in your scale, distance, and speed, which were crucial for making the flight dynamics feel grounded in reality.

DP: There was also mention of Unreal-based virtual production material related to the airship. How did you manage the relationship between real-time assets, scanned set data, and final cinematic assets?

Andreas Giesen: Again, USD was the bridge. We took the Unreal assets, which gave us the exact scale and spatial relationships from the LED volume, and used them as the spatial framework to build our final pixel cinematic assets over the top. It ensured that when we integrated the final CG back into the live action plates, all the contact points and lighting references matched the physical set pieces perfectly.

DP: Was the biggest benefit from USD technical elegance, or simply that it stopped artists from stepping on each other’s work?

Andreas Giesen: Ha, a little bit of both, but honestly, stopping the file overwrites is worth its weight in gold. On a more technical level, the real elegance was how flawlessly it let us bridge the gap between Maya and Houdini.

For the Shady Sands environment, our Layout Lead Karin Wolf and her team built the pristine, non-destroyed city parts in Maya. We then brought that via USD straight into Houdini to scatter all the granular details and endless cornfields. Being able to mix and match layouts without friction meant artists could just stay in the tool they were fastest in.

DP: The Vertibird work in Fallout has always been interesting because it needs to feel stylised and believable at the same time. What were the challenges for it in Season 2?

Andreas Giesen: The challenge is that it is a massive, lumbering vehicle, but it still needs personality. For Xander Harkness arriving at Area 51, he is a fantastic, slightly cocky pilot, so we had to inject this aggressive precision and specific swagger into the flight path and mechanical braking.

The integration challenge, especially during the Caswennan docking, was finding that fine balance of heavy momentum. We had to ease the mass and simulate procedural micro vibrations to show it buffeting in the air currents. The hardest part was nailing the exact frame where the mechanical arm takes over the full weight and the rotors power down.

DP: How much of selling a vehicle like that comes from animation, and how much from camera language, editorial rhythm, and integration into atmosphere and environment?

Andreas Giesen: Animation gets you the weight and the performance, but the environment integration is what sells the lie. In the hangar landing, the plate was dramatically backlit. Our lighters had to introduce specific light sources to shape the geometry nicely and match the foreground. Then the FX rotor wash tied everything together. We simulated heavy CG dust and debris blowing right past the lens, matching the practical wind from the live-action plate to physically anchor the digital ship into the real set.

DP: For sequences involving scanned practical sets, such as hangar or landing environments, what are the biggest pitfalls once the scan data actually enters production?

Andreas Giesen: The biggest pitfall is that the scan data and the live action plate lock you into absolute physical reality. If the plate has a specific wind direction or interactive lighting, absolutely every piece of CG vegetation, dust, or vehicle integration has to physically react to that exact same environmental energy, or the illusion breaks immediately.

DP: Fallout still has this very specific balance: it is heightened and absurd in places, but the world still needs physical credibility. How does that affect VFX decisions in review?

Andreas Giesen: You have to ground the absurdity in absolute, boring physical reality. For the dramatic dirigible crash, which is inherently a heightened, spectacular moment, we went straight to historical footage of the Hindenburg. We ran intense, clustered simulations starting with plastic deformation for the metal bending, triggering RBD sims for the hull ripping apart, and feeding that into multiple layers of pyro for flames, smoke, and contact sand. If the physics are incredibly strict, the audience will buy into the universe’s stylised madness.

DP: On a show like this, where does proceduralism genuinely save time, and where does it still need a heavy layer of manual art direction to become production-ready?

Andreas Giesen: Proceduralism saves you on the sheer volume, but art direction saves the shot. For the destroyed Los Angeles, we started with basic map data, literally just cubes and planes. Our brilliant TD, Kilian Baur , built a Houdini tool that procedurally converted those cubes into heavily detailed, destroyed buildings. It generated massive amounts of geometry. But you cannot just hit simulate and walk away. We had to manually paint the degree of destruction across different zones for compositional reasons. The tool does the heavy lifting, but the artist still has to compose the frame.

DP: Was there a particular sequence in Season 2 where the real constraint was neither the creative idea nor the client feedback, but simply scene complexity, cache weight, or iteration cost?

Andreas Giesen: The dirigible crash and the Area 51 reveal were absolute beasts for cache weight. For Area 51, we were blending volumetric dust, suspended sand particles, and contact sand actively swirling off the geometry. The dirigible had even more interactive layers, expertly managed by FX TD Arnaud Malherbe under Jens Martensson .

We survived by heavily clustering the sims for faster turnarounds and by relying on deep compositing workflows in Nuke. Our Compositing Supervisor Michael Lankes , Comp Lead Kader Bagli , and Comp Lead Jannik Walzer did incredible work taking those massive datasets and balancing them without bringing the farm to its knees.

DP: What became easier on Season 2?

Andreas Giesen: Things like lookdev for the energy signatures became easier. We reused the core effect for the cold fusion and diode glows from Season 1. But because we had to scale it up to so many more shots, we had to build highly efficient setups in Nuke involving heavy rotomation and complex relighting, since that blue glow affects every shiny metal surface around it. The look was established, but the volume and the necessary integration were significantly harder.

DP: Was there a shot or sequence this season that looks deceptively simple in the final cut, but was technically far more difficult than most viewers would ever suspect?

Andreas Giesen: It has to be the Power Armor enhancements. Production has this absolutely incredible practical suit that a stunt performer wears on set. However, because it is a physical, wearable suit, sometimes individual parts will naturally jiggle or bounce a bit too much during heavy action, which breaks the illusion of solid, heavy metal armor.

In the shot where the massive dirigible is coming down and exploding in the background, we actually had to completely replace the shoulders of the Power Armor while the character is running away. Everyone in the audience is obviously staring at the massive fiery airship crash taking up the sky, but there we are, meticulously tracking and doing invisible CG replacement on shoulder pads just to make sure the suit feels appropriately heavy.

DP: And conversely, was there a shot that looked terrifying at first but became manageable once the right structure or workflow was in place?

Andreas Giesen: Definitely the procedural destruction of Los Angeles. The idea of destroying a city of that scale is terrifying. But once Kilian’s tool was in place, and we utilised our USD pipeline to block the shots with simple geometry while the high-res destruction updated seamlessly in the background, it actually became a highly manageable, iterative process. We could instance the endless piles of rubble and rusted cars, which kept the massive scale from becoming unrenderable.

DP: What is a technical lesson from Fallout Season 2 that would transfer well to other large episodic shows?

Andreas Giesen: The absolute golden rule is to keep everything as procedural as humanly possible so you can actually survive rapid client changes. That, combined with establishing those small expert strike teams we talked about, is how you manage the chaos. But the real lifesaver that transfers to any heavy show is aggressive pipeline automation. For sequences with massive shot counts, we utilised our proprietary riseflow tools to completely automate the heavy lifting.

We could submit CG renders from one principal master scene across 50 different shots before leaving the studio. By the next morning, the pipeline had automatically generated 50 temporary composites, already perfectly combining the new CG with the live-action plates using deep learning. Waking up to 50 ready to review temp comps instead of a massive rendering bottleneck is the only way to deliver a show of this scale.

DP: What is the next project you are working on, insofar as you can already talk about it, and is there anything from Fallout Season 2 that you are taking with you into that next production?

Andreas Giesen: I am currently working on something very exciting, but unfortunately, it is strictly under wraps right now, so I cannot speak about it just yet. But I am absolutely taking the USD workflows and the procedural pipeline strategies we refined on Fallout straight into this next challenge!

The post RISE: Fallout Destroys LA, Politely first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

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

What 1.0 actually changes

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

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

Sourcing gets less crunchy

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

Read more: Theory Accelerated shifts Paradigm 1.0 for Houdini

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

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

The performance pass: SDF, advection, sorting

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

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

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

PCG everywhere: viscosity and pressure style steps

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

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

Tank workflows and open water domains

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

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

Outputs, fields, and other useful knobs

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

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

What it does and does not include

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

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

Compatibility and system requirements

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

Pricing, licensing, and the parts people actually ask about

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

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

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

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

Where this sits in a broader Houdini sim stack

Liquid Thinking: Paradigm Brings GPU Speed to Houdini

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

Axiom 4 for Houdini: Faster GPU Pyro With Better Collisions

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

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

https://www.theoryaccelerated.com/paradigm

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

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

https://www.theoryaccelerated.com/axiom

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

What Project Violet is

Project Violet is a tutorial series made in Houdini 21, of the “Intermediate” Level, by Sam Taylor. The series shows new character features and workflows in Houdini 21 while combining the production readiness of Epic’s MetaHuman system with Houdini rigging and simulation workflows to build an approachable full human workflow.

That matters because it narrows the promise. This is not a inspiration reel, but a character pipeline exercise, with the character coming from MetaHuman and the heavy lifting happening in Houdini. If your day job sits anywhere near character setup, deformation, or character-adjacent sims, Project Violet wants to show you how to reuse, get a decent iteration speed, and getting a believable human through a procedural toolset without constantly falling back to manual rig babysitting.

The pipeline pitch: MetaHuman base, Houdini control

The main idea: take MetaHuman as the starting point and use Houdini for rigging and simulation versatility. It calls MetaHuman “production-ready” (we could discuss that, yet, the character is still in intensive care), and it presents that as the baseline you inherit rather than something you rebuild. Everything after that becomes a question of how far you can push Houdini’s character toolset once you stop spending weeks on initial asset authoring.

Houdini 21: Like good wine (Part1, VFX & Geo)

A separate SideFX-side (hehehe) for Project Violet describes it as an evolution of an earlier character-centric project, and it wants to focus on greater realism and expanded capability of the character, to showcase Houdini rigging and animation capabilities updated for new features and efficiencies in Houdini 21, and demonstrate a character pipeline that emphasises proceduralism while using MetaHumans as a base for the workflow.

That language is still a pitch, but it dosn’t widen the scope. The project is about a workflow, not a single solver trick. It aims to demonstrate procedural character work in Houdini 21 with a MetaHuman starting point.

One practical caveat: none of these claims your exact studio constraints, problems and idiosyncrasies of the colleagues get solved. Your skeleton naming rules, mesh structure, and export requirements still exist. Project Violet shows a route, not a universal treaty.

Houdini character tooling under the hood: APEX Autorig Builder

If Project Violet is the show, the APEX Autorig Builder is one of the stagehands. The APEX Autorig Builder SOP is a tool to interactively apply and configure pre-built and custom rig components through the viewport, which aims to make character setup more intuitive and lets you quickly build a complete rig.

SideFX draws a line between the APEX Autorig Builder SOP and the APEX Autorig Component SOP. The Builder can add multiple rig components, supports interactive viewport rigging, and allows modifying a limited set of component parameters in the viewport. The Component SOP adds one rig component at a time, can be used to create custom components, and exposes the full set of parameters in the parameter editor.

Back to Project Violet, because it glues the workflow in Houdini’s modular rig component approach rather than a one-off rig graph built for a single hero asset. Even if you do not adopt the exact tutorial approach, those constraints and mechanics tell you what Houdini 21 expects when you try to scale character setup.

Unreal and MetaHuman side of the bridge

Project Violet ties into Unreal. Epic’s MetaHuman are tools to assemble a MetaHuman character or create MetaHuman-compatible grooms in SideFX Houdini.

That tells you two things. First, the pipeline is not only about ex/im-porting Alembic and hoping for the best. It involves a toolset that lives in the Unreal ecosystem but targets Houdini as the working environment for certain tasks. Second, the workflow depends on version compatibility and installation details that can change across engine builds, pipeline images, and studio IT lockdowns.

This is where the series may appeal to teams that want to get to motion and deformation problems quickly, or to studios that already standardised on MetaHuman for certain classes of characters and now want deeper procedural control on top.

Either way, run a controlled wokrflow test before you bet a show schedule on it.

https://www.sidefx.com/tutorials/project-violet/

https://www.sidefx.com/docs/houdini/character/kinefx/autorigbuilder.html

https://dev.epicgames.com/documentation/metahuman/metahuman-for-houdini

The post Project Violet links Houdini and MetaHuman first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: KeenTools makes tracking plugins for Nuke, Blender, and Adobe After Effects. The new GeoTracker for SideFX Houdini sits between matchmove and FX layout, and it runs as a SOP node in OBJ and Solaris.

Houdini gets geometry first tracking

GeoTracker for Houdini runs as a native SOP node inside Houdini and works in both OBJ and Solaris contexts. The tool targets geometry based object tracking and camera tracking from 2D footage, with the goal of keeping the full workflow in the Houdini scene rather than bouncing to a separate tracking app.

The core interaction stays intentionally direct. You align an imported or scene built 3D model to the filmed object, then use viewport pinning to keep that object stuck to the plate while the tool reconstructs motion across the shot. That tracked geometry can then feed downstream Houdini work where it actually matters, like driving FX timing, layout, and interactions.

If you already treat layout as the first FX department, this kind of geometry tracked handoff can save a lot of back and forth. It also means you can keep shot scale, scene units, and the rest of your Houdini context consistent, instead of trying to trcak down why a solve looks fine in one app and wrong in another.

Camera solves, lens guesses, and the boring parts

Alongside object motion, the Houdini beta supports camera tracking by aligning static objects or environment models, including LiDAR style environment meshes. It also includes focal length estimation for cases where camera parameters are unknown, plus zoom tracking to follow focal length changes over time.

The Houdini integration also calls out camera import and export in both OBJ and Solaris contexts. That matters because camera plumbing can become the silent time sink, especially when a show uses Solaris for USD centric lighting and layout but still relies on OBJ context for parts of the FX build.

GeoTracker remains geometry based, so you need a 3D model to start tracking. That model can be anything you import or create in the Houdini scene. More detail can help, but extremely dense meshes can get heavy. The beta also includes Surface Masks to exclude parts of the model from tracking when occlusions or reflections would otherwise pollute the solve.

Beta reality check, installs, and pricing

The plugin ships as an open beta and it is free during that beta period. Each beta version stays valid for 30 days, with regular updates planned until a stable release is ready.

Installation stays old school by design. You drop the extracted package into your Houdini packages directory on Windows, macOS, or Linux, and Houdini picks it up. Updates and removal work the same way: delete the old files, replace with new ones, or remove them entirely. There is no auto updater for the beta yet, so you own the housekeeping.

System requirements keep the target clear: Houdini 20.5 or newer on 64 bit Windows, macOS on Intel or Apple Silicon, or Linux. The guidance for graphics hardware stays refreshingly unromantic: a decent GPU that can handle Houdini.

As always, treat new tools like you treat new render builds: test in a controlled setup before you bet a delivery on it, even if the demo looks clean.

https://keentools.io

https://keentools.io/products/geotracker-for-houdini

The post KeenTools GeoTracker enters Houdini open beta first appeared on DIGITAL PRODUCTION and was written by Bela Beier.