For those who don’t know the tool: Natsura, the Houdini foliage toolkit lives inside Houdini, can push assets to Unreal Engine workflows, and now leans harder into assemblies, mapping, and export glue.

What shipped in 0.6

Version 0.6.0.0 landed on March 25, 2026, with support for Houdini 20.5 and Houdini 21.0. The release calls out modular effectors, Nanite assemblies, an assembly decorator, a revamped UI, analytics, scan extension, and Houdini 21 support. The update introduces an Assembly workflow aimed at quickly rigging twig and branch libraries and assembling canopies. There is also a set of tools for Unreal Nanite skeletal assembly support, paired with wind authoring tools. Assembly-related nodes are flagged as experimental in the release notes, though. Be careful.

On the shaping side, the release adds a modular effector system like a bolt on simulation modifiers with no VEX required. Effectors are an extendable stack, and the base effector node supports writing VEX to extend the simulation and respond to geometry and inputs.

Assemblies, decorators, and Unreal export

The release adds new nodes for an assembly pipeline, including an assembly resource node for mesh library import and auto rigging, an assembly decoration node for canopy decoration that can pick modules based on traits and transform instance hierarchies with rigid rotations, and a classify node for trait-based module classification.

Export to Unreal related workflows gets multiple mentions. The export node for Unreal Nanite assembly lists updates including material support, skeletal and static assembly, fixed instance naming, and removal of a transform on points that broke instancing. There is also a LOP node for USD workflows that creates a Nanite assembly for SOP based creation.

Wind support is expanded through new nodes for wind initialisation and validation, wind class assignment for Unreal, a wind preview visualisation tool that is functional but not accurate or meant to look good, and a node that exports UE5 DynamicWindSkeletalData as JSON. If your environment team already has a wind data convention, this is the part to validate early, especially around naming, material binding, and what your in-engine tooling expects.

Effectors, guides, and growth controls

Several new effectors are listed: deflection, magnet attraction, gravitropism, gravity, and noise based growth perturbation. The grow node line gets a long set of updates in this release, including a new spiral parameter with absolute and relative modes, integration with the effector stack, and an updated decorator stack format to match the effector stack.

One practical change is the way mapping and prim construction are described. Map prim construction is deferred to grow, which is described as reducing node count and compile time. There is also an instant colour preview mentioned, plus options for skeleton swapping and custom draw modules. Growth workflows appear to be treated as a family of versions, with backwards compatibility restored across multiple grow versions and various mapping and parameter warning cleanups.

Rig simplification and reskinning

Rig simplification tooling shows up both as a new simplify rig node and as updates to a simplify rig reskin path, as well as multi stem tree support, chaining of simplify nodes, and added carve method and max joints count. If your pipeline needs a predictable joint budget for game ready trees, this is where you will want to spend time.

Analytics and privacy details

Analytics is “opt-in” and disabled by default, with no data collected without explicit user consent. If you work in an environment with strict compliance rules, the opt in default and EU cloud note are helpful details, but you still need to run your own review. Make sure your team knows what is allowed, and that tool telemetry decisions match your facility policy.

The notes also state that 0.7 will be a breaking release, and this 0.6 release includes precursor work such as a standardised mapping architecture, groundwork for decorator cook trigger decoupling, and a foundation for mappable decorator parameters. Read that as a warning to keep a rollback plan, and to budget time for update testing before you touch active porudction setups.

Compatibility notes for Houdini artists

Houdini 21 support is obvious, including mention of an APEX graph schema enforcement fix. The release also claims continued full Houdini 20.5 support, plus compatibility work around Qt bindings.

In practice, this release spans a lot of surface area: SOP level nodes, UI panels, export to Unreal, USD workflow hooks, analytics, and a mapping engine refactor. That is a lot of moving parts for a minor release number, even if the changelog is transparent about what is experimental. Treat the upgrade like you would any node library update: keep a copy of old scenes, validate the graphs, and test exports end to end before shipping anything client facing.

https://www.natsura.com/

The post Natsura 0.6 adds effectors and Nanite export for Houdini Foliage 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.

Blender To Unreal Live Link is built around a simple promise: push models, materials, and textures from Blender into Unreal Engine without bouncing through a traditional export and reimport loop. The workflow centers on a Blender add-on and Unreal-side Python scripts that sit inside your project so the handoff happens from inside your normal working tools. The add-on supports one-click sending, and it also offers an auto-sync mode for iterative work.

Milad Kambari (Artstation) sells the add-on for $18 on Superhive.

Getting connected without guessing

After installing the Unreal plugin and the Blender add-on, the two applications connect through a Start Live Link action on each side. In Blender, the workflow uses a Start Live Link button. In Unreal, the workflow uses a Blender Live Link menu with its own Start Live Link action.

The first connection can take longer than later runs because the network communication between the applications establishes itself for the first time. A connected status indicates the link is established. If you want to confirm the setup path executes correctly, the workflow suggests checking the log and watching for errors shown in red. If you do not see red errors, that indicates the path was set up correctly, and the instruction is to keep the plugin and scripts in the right place and stay patient while the connection finishes.

Send selected, send full scene, and why one is a trap

Once connected, the basic transfer flow centres on selecting assets in Blender and sending them across. The add-on offers two transfer options: Send Full Scene and Send Selected. Send Full Scene is positioned for smaller to medium scenes, and Send Selected is positioned for larger scenes where you only push what you need.

The usage guidance recommends not leaning too heavily on Send Full Scene because real scenes can be heavy, with a large number of objects. The suggested working method is to proceed with Send Selected so you keep control of what moves over, and to transfer heavier scenes piece by piece. The stated goal is better scene management while avoiding the need for extensive hardware resources.

The workflow description also demonstrates sending multiple objects at once using Send Selected, where selecting multiple objects and running the send results in both arriving in Unreal.

Materials, textures, and the two-lane road

Material transfer is included alongside geometry transfer. The tool is described as able to send materials along with textures, including transferring a model together with its texture. The product listing also states that simple physically based materials transfer automatically with textures for base color, normal, roughness, and metallic.

When materials get more complex, the workflow shifts to a different option. The add-on includes a Bake and Send Selected mode intended for complex materials that need baking before they can be sent. The listing describes complex shader setups using nodes such as the Mix node as examples that can require this path. In this mode, materials are baked into clean textures for transfer, and the workflow is described as non-destructive, restoring original materials after the send. The tool detects whether a model has UV maps. If UV maps exist, it does not alter them and uses them for baking. If a model does not have UV maps, it can generate UV maps as needed for baking.

Live sync, but with a leash

Live sync mode sends changes automatically, but the workflow has a specific rhythm. For edit mode changes, the flow relies on exiting edit mode. After you make an edit, you exit edit mode and return to object mode so the edit becomes visible in Unreal.

Live sync is also framed as “something to use carefully”. The developer does not recommend using it extensively because it can require hardware resoruces due to the different graphical structures of the two applications.

Hierarchies, pivots, and scale sanity

On the scene-structure side, the listing describes parent and child support. Selecting a parent object can include its mesh children automatically, which matters when you are working with grouped meshes or hierarchical scene organisation.

It also preserves pivots. Object origins from Blender are preserved in Unreal, so the pivot behaviour you author in Blender carries through after transfer. Scale handling is called out too. The listing describes a 1 to 1 scale relationship between Blender and Unreal, aimed at avoiding the classic scale mismatch workflow pain. Transforms are part of the transfer. Location, rotation, and scale are sent and applied in Unreal.

What is included and what it needs

The package includes a Blender add-on file and Unreal Python scripts named blender_livelink_addon.py, livelink_unreal.py, and init_unreal.py.

System requirements list Blender 5.0 or higher and Unreal Engine 5.5 or higher, plus Windows 10 or 11, with the condition that both applications must run on the same machine.

Pricing is listed as $18.

Practical takeaways for production artists

If your daily loop includes moving assets from Blender into Unreal for lookdev, lighting, layout, or realtime checks, this tool focuses on reducing the friction in that handoff. It provides Send Selected for controlled transfers, Send Full Scene for smaller setups, and Bake and Send Selected for complex material cases that need baking. It also includes live sync for iterative updates, with workflow notes about exiting edit mode so edits propagate.

As with any new pipeline tool, test it in your own environment before you rely on it for production.

https://superhivemarket.com/products/blender-to-unreal-live-link

The post Real-time Blender to Unreal Live Link first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

If your modeling flow depends on lining up a mesh to photos, you already know the usual pain points inside Autodesk Maya. You set up a camera, attach a reference image, tweak focal length and framing, then bounce across panels and settings while your brain tries not to forget what the likeness looked like two clicks ago. Handy RefTool aims straight at that friction by collecting the controls for reference matching into a single interface. The practical target is portrait modelling, but the same camera to image alignment problem shows up everywhere you match a 3D model to reference images. That includes creature design and hard surface work when you want the model to sit cleanly against a specific plate or photo set.

Classic mode, fewer context switches

RefTool includes a Classic mode that sets up reference cameras by automatically creating a camera in a scene and assigning a reference image to it. From there, the workflow focuses on fast iteration. You can adjust camera settings via slider controls, rotate around the model, zoom in for alignment checks, and scrub the opacity of the reference image to see how closely the sculpt lines up.

That opacity scrubbing matters more than it sounds. It turns the usual on-off flipping of an image plane into a continuous check, so you can keep your eye on silhouette, landmarks, and proportions without turning the viewport into a strobe light.

Once you have a camera setup you like, RefTool can export it as a JSON file, allowing you to reuse it in future projects. That reuse angle fits neatly with production reality, where you do not want to rebuild the same camera matching scaffolding every time a new head variant or costume pass drops into the scene.

RefBoard mode turns cameras into a wall of thumbnails

When you have multiple reference views, the real time sink is not creating them. It is switching between them in a way that keeps you oriented. RefTool includes a RefBoard mode that lets you arrange camera views like an image board and switch between them by clicking on thumbnails. That thumbnail switching also plays nicely with the way artists actually work on likeness. You rarely stay married to one image. You bounce between angles, you cross-check, you sanity test, and you keep moving. A board of camera views makes that bounce less disruptive than hunting through the outliner or viewport menus for the right camrea at the wrong moment.

Install notes, plus a very specific graphics requirement

There are two tracks here, and the install experience differs. For the free RefTool v2.1, installation runs through the Script Editor inside Autodesk Maya. You open the Script Editor, load the RefTool_v2.0.py script, then either execute it immediately or save it to a shelf for a one-click launch later. The same listing also includes free scripts labeled RefTool v2.1.1, including RefTool v2.1.1.py and RefTool_V2.1.py.

For the full RefTool v3.0, the install path starts with unpacking an archive. You then open Autodesk Maya, switch the Script Editor to the Python tab, drag and drop a maya_installer.py file into the editor, and click Save. A file dialog prompts you to select the RefToolV_X.X folder that contains the source files. After that, the tool icon appears on the currently active shelf.

One operational detail comes with a big warning label. Each time the tool launches, it runs directly from the folder selected during installation. If you move, rename, or delete that RefToolV_X.X folder after installation, the tool stops working. Both the free and full installs include the same requirement: Viewport 2.0 inside Autodesk Maya needs to be set to DirectX 11.

Versions and pricing

The version split is straightforward on paper. RefTool v2.1 is free and is described as having the core functionality. RefTool v3.0 redesigns the interface and adds extra functionality. The published price for version 3.0 is USD $14.48.

Where this fits in real work

The strongest signal here is not a single feature, it is the focus on keeping the artist in the flow. Reference matching is foundational for portrait work, but it is also a repeated micro-task across creature blockouts, prop modeling, and any job where a specific camera-to-image relationship matters. RefTool targets those repeated touches by putting the camera adjustments and reference image controls in one place.

The JSON export for camera setups adds a pipeline-friendly hook. Reusable setups can reduce churn when a project revisits the same asset type across multiple shots or deliverables, or when a team wants consistent camera matching conventions for a specific modeling task. As always, new tools and workflow tweaks should be tested before you let them anywhere near a production deadline, especially when the tool depends on specific viewport and graphics settings.

https://www.artstation.com/marketplace/p/PBWgY/maya-reftool-the-ultimate-camera-reference-manager-new-version

The post Handy RefTool 3.0 speeds Maya ref matching first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The problem NanoGS tackles

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

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

Supported engine versions and what you actually install

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

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

The controls that decide whether it feels stable

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

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

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

Debug commands that make problems obvious

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

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

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

Best practice: do not feed it one giant splat brick

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

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

Proof of concept, not a miracle

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

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

Release, license, and what it costs

NanoGS is released under the MIT license.

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

The plugin is free.

https://github.com/TimChen1383/NanoGaussianSplatting

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