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.

For those who don’t know the tool: Nature Generator is a procedural asset library add-on that lives inside Blender via the Asset Browser and an N-panel, sold on Superhive Market, so you can kitbash nature without leaving your DCC.

The whole point is staying in your scene

Nature Generator builds natural assets directly inside Blender. Rocks, terrains, plants, water, and other environment bits all come in as editable, generated assets rather than fixed meshes. You drag an asset into the scene, the side panel recognizes it, and the controls you need show up without a detour to another app. The comparison to Quixel Megascans is obvious, being fully procedural and customizable.

The minimum version requirement is Blender 4.1 or higher. Hardware requirements call for a modern GPU from NVIDIA, AMD, or Apple Silicon. There is an optional texture options folder with 1K, 2K, and 4K texture resolutions. By default, the add-on uses low resolution preview textures, and the guidance recommends keeping the texture folder on a fast local SSD because it affects performance.

Installation stays simple. You drag and drop the zip into Blender, click OK, and the library sets up inside the Asset Browser. The Nature Gen panel appears in the side panel and opens with the N key. From there, drag and drop assets into the scene and start tweaking.

Geometry controls that reward restraint

Every asset follows a similar structure: shader settings and geometry settings, with slightly unique controls per asset. Geometry includes a resolution section, and most assets support a low-poly option. Viewport and render resolution can be controlled separately, and resolution can be subdivided or voxelized depending on the asset.

The documentation also includes the most honest feature statement possible: resolution can go infinitely high, and every asset can crash Blender if you push it too far. That makes the control powerful, but it also makes self-control part of the user interface.

Base shapes come from primitive forms you can alter in edit mode. Some assets follow the structure of a mesh and react to topology. Some are planes. Some are driven by curves. Displacement settings include multiple texture and noise displacement controls, with patterns such as noise breakup, stratification lines, and crack patterns. Many categories expose basic settings and an advanced subcategory for deeper tuning.

At around the moment you start dialing prcoedural detail like it is free, that crash warning stops reading like documentation and starts reading like prophecy.

Custom shaping can use a gradient with its own displacement, falloff, location, and scale settings, with viewport gizmos available when the modifier is selected. Alternatively, a custom curve object can influence the terrain, with a radius setting and a distance based falloff where farther from the curve means weaker influence. A secondary custom shape can be added, such as one curve for valleys and another for mountains.

Scatter was rebuilt to be more direct

The latest update changes how the scattering system works. If you have an older version, the update workflow shown is to download the new version from Blender Market and drag and drop it into the scene so it overrides the old version.

The new scatter setup aims to be simpler with fewer settings. The key change is the import flow. You import the specific assets you want to scatter, then assign them into the scatter collection. After importing, you can toggle an exclude option so the collection does not sit visibly in the scene, while still being used by the scattering system.

Core scatter behavior remains familiar. You can adjust density, and you can still use slope based scattering, altitude based scattering, and noise based scattering. Scatter zones remain part of the tool, controlled by empties with viewport gizmos so you can define a local area for scattering.

The update also introduces threshold softness controls across settings. The stated purpose is scaling down scattered assets toward the edges of masks. That creates a smoother falloff where a hard cutoff would look like a stamp.

Draw where the scatter goes

A major addition in the update is a scatter curve or grease pencil option. You can assign a curve or a Grease Pencil object and use it to decide where scattering appears and where it does not.

The workflow shown is straightforward: create a blank Grease Pencil object, draw directly on the surface, then select that drawing as the scatter guide. The same idea works with a curve object. You get controls for draw radius and radius softness, and the falloff scales down scattered assets toward the edges. There is also a noise option to distort the shape and avoid a too clean, too perfect outline.

Remove the draw object, and scattering returns to the default behavior. That makes the feature easy to test and easy to abandon if a shot changes direction.

Viewport survival mode, now with choices

Scatter can get heavy. The update adds a display mode control in the instance settings. You can display instances as originals, as boxes, or as wire box. Instance scale stays, but the update adds a secondary scale and a secondary scale probability. That lets a minority of instances become much larger than the rest, adding variation without requiring a second scatter layer. Rotation controls remain.

There is also a new wind animation option for scattered assets. Wind time is a value you animate, with an example workflow of adding a driver expression using hashtag frame and optionally dividing to slow it down. The update explains why this stays manual: using a scene time node inside node trees made performance drop sharply, including an example of frame rate dropping to around seven. Removing the time node restored smooth playback. With many scattered objects each carrying the scatter system, the update keeps wind time explicit to protect performance.

Terrains, water, and the new step look

Terrain and mountain assets use a separate X and Y resolution, because resolution on those axes influences the shape and form of erosion. Terrain maps include a random seed, and terrain can generate from noise or be influenced by a custom shape.

Noise displacement includes control over influence on X, Y, and Z, plus a noise seed and standard noise settings. Texture displacement adds rock detail. Erosion settings apply erosion from a selected height, with placement, falloff, and an option that can add mountains and inverted valleys. Boundary falloff can flatten edges.

Water effects add a cube with a procedural water shader. Controls include height and depth, and rivers can be created by combining a water effect value with custom curve shaping that pushes terrain down so water appears in selected areas. Water shader settings appear in the shader tab, including animated noise controls to create the illusion of moving water with separate speed controls on X and Y.

The update adds terrain presets, including a forest preset and a canyon preset. The forest preset uses the scattering system, and trees can default to box display for performance on lower-end systems, with the option to switch back to originals. The update also adds a terrain steps feature on some presets, described as a stepping effect. Controls include the number of steps, detail, strength, and blur, with noise-based selection and influence. Terrain steps can be found in erosion settings, in noise settings, and when drawing along a custom curve.

Trees arrive, and snow gets more physical

The update adds tree assets. Tree shaders follow the same structure as flowers, including leaf color controls and translucency. Leaves can be pushed toward an autumn look by changing colors. There is also a setting for a leaf mask, and leaf shapes are generated procedurally, with controls for scale and mask threshold.

Scatter categories shown include plants such as flowers, wheats, grass, ground cover, shrubs, plus rocks, snow, and trees. Scattered rocks are procedurally generated and have their own settings such as resolution, shape distortion, size ratio, and a seed.

Snow scattering gets a notable twist. Importing a snow object can be recognized and turned into a volume style approach for creating snow on objects rather than only shader based snow. Snow settings sit in the geometry tab, including resolution and displacement settings. Particle detail adds small particles with alpha textures, intended to improve realism for close-ups. The tool also notes that foamy snow detail may require higher transparency bounces.

Materials, uniqueness, and the new override option

Materials are shared by default. The tool includes Make Material Unique to create a new copy of a material for the selected object, and Revert to return to defaults. The update also adds a use custom material feature for the new scatter effect. The workflow shown duplicates a material and assigns it as an override for the scattered assets, so you can make unique changes without affecting the original material used elsewhere.

Scatter effects can stack, and the update shows renaming modifier labels to organize multiple scatter effects. This is the part where it starts feeling less like an asset pack and more like a small ecosystem.

Pricing and what is actually specified

Pricing is specified on the product page. A Personal License costs $99. A Commercial License costs $169. A Studio License costs $259.

https://superhivemarket.com/products/the-nature-generator?ref=586

The post Nature Generator update brings procedural nature to Blender first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: The Grove by F12 is a biologically driven tree growth system for Blender and Houdini. It simulates yearly growth and exports animated meshes for DCC and real time pipelines. It sits between modelling and layout, replacing static tree assets with parametric growth.

A measured update, not a rewrite

Dutch developer F12 has released The Grove 2.3, a new version of its procedural tree generation system for Blender and Houdini. The update focuses on workflow refinement, storage reduction and export behaviour rather than introducing a new simulation model. The Grove simulates tree growth year by year using a biologically inspired algorithm. Parameters control branching, apical dominance, tropism and environmental factors. The result is a procedural tree that can be edited non-destructively and regenerated at any stage. The software is delivered as a Blender add-on and as a Houdini plugin.

Version 2.3 does not alter the core growth algorithm. Instead, it introduces new interaction tools and structural changes to data storage. Growth simulation data now occupies roughly 75 per cent less storage than in previous versions. This reduction is achieved by limiting the recording of certain editing operations, including Prune, Bend and Draw. As a result, older files may load with reduced edit history in some cases. The release notes describe this as a trade-off between storage footprint and full historical edit retention.

The reduction is significant for productions that store multiple growth iterations per asset. Vegetation assets are often versioned across layout, look development and lighting. A three-quarter decrease in simulation data can materially affect scene management, particularly in large environments.

Drawing trees directly in the scene

A key addition in 2.3 is the expanded Draw tool. In earlier versions, artists could draw branches onto existing trees. The updated Draw tool now allows users to draw complete trees directly into the scene, either from the ground plane or from arbitrary surfaces. Drawing can begin from geometry, allowing trees to be placed on terrain meshes or architectural elements without manual alignment. This shifts some layout tasks from object instancing to interactive placement of growth.

Drawn strokes are converted into growth instructions. The tree then grows according to the defined biological rules rather than remaining a static curve structure. This maintains the parametric nature of the asset. For layout artists working in Blender or Houdini, this means that trees can be sketched into position rather than generated from presets and repositioned after the fact. The difference is subtle but practical. It moves early composition decisions into the growth stage itself.

Subdivision for cleaner branch geometry

Another addition is a Subdivide option intended to smooth segmented branches. Procedural tree systems often represent branches as chains of nodes connected by straight segments. At lower resolutions, this can produce visible angular transitions along the branch.

The Subdivide option adds additional nodes between existing ones, reducing visible kinks. Subdivision is applied selectively and is not equivalent to a global mesh subdivision modifier. It operates at the growth-structure level rather than purely at the mesh output level.

For rendering pipelines that rely on displacement maps or high-frequency bark detail, smoother base geometry can reduce shading artefacts. The release notes include before-and-after comparisons showing reduced angularity along curved branches. These images suggest a visible improvement, although final render quality will still depend on your shading and tessellation settings.

Automatic bark texture scaling

Texturing adjustments form another part of the 2.3 update. The Grove now automatically scales bark texture repetition around the circumference of branches based on their thickness. In previous versions, artists needed to manually adjust bark scaling to prevent visible stretching or excessive tiling on thicker trunks. The new behaviour calculates scaling from the branch radius, automatically aligning texture repetition with geometry.

This is an automatic scaling of bark texture, which repeats around branch circumferences. No additional user input is required. This is a small change, but in vegetation workflows, small changes reduce repetitive corrective steps across dozens or hundreds of assets. No new shading model is introduced in 2.3. The change concerns UV scaling behaviour rather than material definition. The Grove continues to output meshes compatible with standard Blender and Houdini shading systems.

Export adjustments for real-time engines

Export behaviour has also been revised. The release notes state that The Grove now uses a split seam structure intended to align better with real time engines and modelling tools such as three.js, WebGL and Rhino. The split seam structure separates end cap geometry and allows per point normals and UVs where supported. In practical terms, this affects how branch junctions and cut ends are represented in exported meshes.

Real-time engines often rely on explicit vertex normals and clean UV seams for correct shading and normal map interpretation. Adjustments at export level can reduce the need for manual cleanup in downstream tools.

The vendor supports common interchange formats, including FBX, OBJ, and USD. Animated exports, including growth over time and wind motion are available via Alembic. These formats are standard in both offline VFX and real time pipelines.

Houdini Indie and Blender support

The Grove 2.3 expands support on the Houdini side by adding compatibility with Houdini Indie. Houdini Indie is the lower-cost edition of Houdini from SideFX, targeted at individual artists and small studios. Previous limitations restricted some editions of The Grove to full commercial Houdini licences. The addition of Indie support broadens access for freelancers and small teams.

According to coverage by CG Channel, the update makes The Grove available in Houdini Indie environments, although the vendor release page remains the primary source of technical detail.

On the Blender side, The Grove is compatible with the Blender 5 series. Blender is developed by the Blender Foundation. The Grove is distributed as a Blender add-on and integrates directly into the host application interface.

Editions and pricing

The Grove 2.3 is available in three editions: Starter, Indie and Studio. All editions include the Blender plugin. The Studio edition adds full Houdini support.

At the time of writing, pricing listed on the vendor site is 99 euro for Starter, 199 euro for Indie and 799 euro for Studio. The vendor also offers separate Twigs geometry packs containing leaves, flowers and fruits, priced individually.

Production considerations

The Grove remains a specialised tool focused on biologically plausible growth rather than purely parametric mesh generation. Its value in production depends on whether growth behaviour is part of the creative requirement or simply a means to an end.

Version 2.3 does not introduce a new solver or simulation paradigm. Instead, it refines interaction, reduces storage overhead and adjusts export behaviour. For studios already using The Grove, the update appears incremental rather than disruptive.

For new users, the addition of Houdini Indie support lowers the entry barrier. The storage reduction may also make the tool more viable in asset dense scenes where file size becomes a concern.

As always, new tools and updates should be tested in a controlled environment before deployment in live productions. Behavioural changes in data storage and export structure should be validated against existing pipeline assumptions.

// F12 The Grove homepage
// https://www.thegrove3d.com/

// F12 The Grove 2.3 release notes
// https://www.thegrove3d.com/releases/23/

The post The Grove 2.3 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Tradigital3D describes ShapeScape Studio as “a comprehensive toolkit for the digital painter.” It merges procedural generation with manual artistic control. Users can either pick from included presets or import their own meshes and texture maps to generate foliage in a custom, hand-painted style. The system allows procedural generation from any mesh, letting artists feed trees, bushes, or grass models through the modifier setup to create stylised structures. Hand-painted textures can be applied directly, either from the six included foliage texture presets or from user-created sheets.

The shader and colour parameters are fully adjustable, making it possible to simulate different seasons or moods by editing colour gradients and hue ramps. Built-in animation parameters allow for wind-driven motion, producing stylised movement in EEVEE renders. While the vendor claims “life-like simulation,” the exact deformation method is not documented and has not been independently verified at press time. The system remains fully non-destructive: artists can replace meshes, adjust textures, or retune shaders at any time without rebuilding the scene, thanks to its procedural node design.

What’s in the package

The toolkit includes more than 100 ready-to-use base models of trees, bushes, and grasses, and six NPR texture presets that can be freely replaced with personal hand-painted textures. ShapeScape operates as a node-based procedural system built on Blender’s modifier stack, including shader variations for trunk and leaf layers. Wind animation is built directly into the node graph and works in EEVEE without external plug-ins. The product supports Blender version 5.0 and newer, and requires no dependencies beyond the default Blender installation.

According to the vendor, the setup is lightweight enough for real-time viewport previews in EEVEE. Compatibility with Cycles is not confirmed, though Blender’s shared shader architecture would likely allow it to function with minor adjustments.

Technical implementation

ShapeScape Studio runs entirely within Blender’s native node framework, with no compiled Python components. It behaves as a modifier-based geometry nodes system, allowing users to inspect and modify the procedural graph directly. Textures are standard image maps, mapped via shader nodes to define the look of foliage and bark. Artists can tweak colour gradients, saturation, and value contrast to produce painterly light effects.

Wind animation appears to rely on procedural deformation using mathematical nodes, probably sine wave oscillation, allowing stylised motion at minimal computational cost. Because these parameters live inside the node tree, users can keyframe amplitude or speed values to tune movement per asset. The non-destructive nature of the setup means that animation can be disabled or modified without rebuilding the asset, making it easy to repurpose trees for static illustrations or stylised environments.

Workflow integration

ShapeScape Studio integrates cleanly into existing Blender projects. Artists can append the modifier setup or node group from the provided file into their own scenes and then replace the base meshes or materials with project-specific assets. Since it relies on EEVEE’s lightweight shading model, it is particularly well suited to stylised game backgrounds, animated short films, or concept visualisation.

Its workflow encourages NPR-style shading, prioritising brushstroke simulation, colour layering, and painterly gradients over physically based rendering. This makes it distinct from realism-driven vegetation tools such as Botaniq or Graswald, which focus on physically accurate materials and light scattering.

Pricing and licences

ShapeScape Studio is sold on Superhive Market under three licence tiers. The Editorial / Personal Licence costs USD 30 and is restricted to non-commercial use, suitable for hobbyists, students, and personal experiments. The Freelancer / Indie Commercial Licence, priced at USD 60, covers one artist for commercial or monetised projects, including commissions and freelance work. The Studio / Multi-Seat Commercial Licence, at USD 120, grants unlimited seats within a single organisation and allows full commercial deployment in professional productions.

All licence tiers include the same content and features; only the usage terms differ. The product page reports more than forty sales and lists the release date as nine days ago, indicating recent release and early adoption within Blender’s stylised-art community.

Context and ecosystem

ShapeScape Studio enters a well-populated ecosystem of Blender vegetation tools. Most existing packages such as Botaniq or MTree focus on physically based realism, aiming to match real-world botanical appearance. ShapeScape differentiates itself through its painterly focus and non-photorealistic shader design, offering a bridge between traditional digital painting and 3D environment construction.

For concept artists, illustrators, and stylised animators, the toolkit presents a fast way to populate scenes with vegetation that matches hand-painted backgrounds. Its procedural node foundation also makes it a useful teaching example for artists studying Blender’s geometry nodes system or non-destructive workflows.

Test before you grow

As with any procedural add-on, production users should test ShapeScape Studio in-house before applying it to commercial projects. Shader appearance, wind animation consistency, and modifier performance should be validated on target render pipelines and hardware setups. NPR toolkits often behave differently under different lighting models, and EEVEE’s approximation-based rendering may produce colour deviations that require manual compensation.

The post Painterly Trees for Blender: ShapeScape Studio Blooms first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The Lost Bus is a 2025 survival-drama directed by Paul Greengrass for Blumhouse Productions in association with Comet Pictures and Apple Original Films. The film is based on the non-fiction book Paradise: One Town’s Struggle to Survive an American Wildfire by journalist Lizzie Johnson. Set against the 2018 Camp Fire in Paradise, California, it follows a school-bus driver and a teacher who fight to guide 22 children to safety through an encroaching inferno. Combining Greengrass’s documentary-style direction with large-scale visual effects and environmental reconstruction by RISE FX, the film depicts one of the deadliest wildfires in recent history with stark realism.

Supervising the inferno: Oliver Schulz (IMDB | Linkedin) is a senior Visual Effects Supervisor at RISE FX, the Berlin-based VFX studio. Over more than a decade at RISE he has guided VFX supervision on major international productions including Fantastic Beasts: The Secrets of Dumbledore, Blue Beetle and Megalopolis, among many others.

His background spans concept art, digital matte painting and 3D environments; skills that helped him to take the creative lead on blockbuster-scale environment and FX heavy shows. In this interview he reveals how he and his team at RISE tackled the challenge of recreating a burning landscape for The Lost Bus, combining procedural geography, wind-driven vegetation, deep-rendered volumetrics, and machine-learning techniques for depth integration, to bring the inferno to life on screen.

DP: How did you get onto the Lost Bus? 

Oliver Schulz: I came on board after wrapping up on Megalopolis and jumped onto the very first meeting with Charlie Noble and Gavin Round, Production VFX Supervisor and Producer. The project was already awarded at that time so we directly started talking about the Sequences and the scope of the Rise portion of work.

Luckily or better sad tragically this was a real event so in regards of look, there were many references and documentation of this day. So our first meeting was looking through a lot of real world footage from all available sources. Charlie had been prepping reference reels from the very beginning, so we could hone in on a lot of specific ones for each portion of the work because he had references for all of them!

DP: Roughly how big was the RISE team on The Lost Bus, and how long did you spend from first build to final comp?

Oliver Schulz: We started with a very small core team in May 24 and delivered the last shots at the beginning of 25.  I think around 50-60 people worked on the show in total during the production with up- and downramping based on specific project needs like temp deliveries for example.

DP: The antagonist of the movie is the geography of a very particular area, and the fact that it is on fire – how did you make sure that it was recognizably that specific part of the world? 

Oliver Schulz: We started with real world data derived from elevation models. That gave us a pretty good grounding in reality. We got lidar scans for very specific locations like the Pulga Bridges for example which was invaluable as this is usually something one doesn’t get from any publicly available sources. We spent quite a bit of time to get us a very good foundation of all key locations, which meant that everything had a geometrical base until the very last mountain you see on the horizon.

Our Lidar Supervisor David Salamon was instrumental in setting up this base. He used some maps imagery to give a rough base color to all those individual geometries that served as a rough guide later on in layout and surfacing for distributions of materials or assets. One has to keep in mind that most data was post 2018 so for instance vegetation had to be recreated from mostly photographic references shot before the fire. We tried to stay as true as possible to real world geography, but later on of course things had to be changed for storytelling reasons. 

DP: When merging New Mexico plates into your California canyon builds, how did you maintain scale and geological continuity?

Oliver Schulz: As production did not have access or in case of some very sketchy roads didn’t shoot at the original location for safety reasons, they did some scouting through the US and chose some New Mexico locations as stand ins for some of our sequences. The most prominent was the Pulga road for sure. In the film, the first responding firefighters trying to get to the origin of the camp fire first get sight when they are on top of the Pulga Highway bridge crossing the Feather River Canyon.

Without any better option they decide their best shot is to try and get to the fire following a very narrow road on the slope of the canyon. All shots on Pulga Bridge were shot on a Studio Backlot featuring full CG Environments including the FG bridge. This narrow path however was all shot on the New Mexico location with two big fire engines driving a slightly wider road. 

In production that meant that we replaced most of the visible Environment due to a couple of reasons. First of course it needed to have the right roadwidth and the correct canyon in the background. Second we needed to have very windy vegetation everywhere. Third in case all of that worked in camera which was pretty rare we still needed to put FX Elements into every shot consisting of dust, debris, smoke and later also embers. With those guidelines in place probably 90% of the shots became full CG exteriors only keeping small bits of photography for fire engines and some road pieces.

Once all those went into layout we made sure to keep a senseful progression to those shots meaning having the firefighters travel along the road during those shots in cutorder. The topography of the shooting location though was pretty different from the storypoint progression on the pulga road, so was the framing in camera when pointing at the fire from the fire engine interiors.

That of course meant as good and real our base was, it needed to be heavily augmented to make sense with storytelling and framing choices. Most shots feature the correct BG canyon but the midground is totally made up to allow for good view to the fire origin. All of this had to be understandable even with very frenetically moving handheld cameras.

DP: Let’s talk vegetation: How much botanical creative freedom did you have? 

Oliver Schulz: Vegetation was a big part of the environment and one of the reasons for the rapid spread of the fire. All FVX vendors had to tackle it in one way or the other which meant all were contributing to the research for which plant goes where. The foundation was once again the research and material collection from Charlie and his team.

We focused on the most common species found in this region of CA and made sure the level of dryness and the distribution made sense. So in this sense there was not too much freedom here as everyone tried to make this as real as possible from this point of view. For the build we actually just used the most common ground which is Speedtree with some augmentations done in Houdini. Part of the assets were also shares from other vendors which just needed ingestion and rigging in FX.

DP: You mentioned building a hierarchical “ecosystem” in Houdini. How modular was this system, and how much hand-authoring did artists still need to do per shot?

Oliver Schulz: This was something we actually invested a bit of time in at the very beginning and was overseen by CG Supervisor David Schulz and Layout Lead Mareike Loges / Senior Layout Artist Björn Markgraf. The core idea is nothing new and hierarchical just means that you start from the biggest Elements in your kit and than go smaller and smaller based on the previous distribution of Elements. First step is to either scatter or handplace big trees for example, following this you end up with a certain distribution. 

Based on this the system places smaller entities like younger trees or seedlings and smaller shrubs and bushes around or between the big trees. This distribution is based on simple rules like distance or terrain steepness. In case of the Pulga road we divided it up in two categories: mountains and roads. Both had similar procedures. We would always start with the rough blocking geometries matching either scan data, elevation data or sometimes just made up. From there we would generate the base coverage of rock cliffs which would hold out trees mostly in those areas. Following this we created the trees and bigger vegetation which would determine the ground coverage of rocks vs more pepply ground.

Roads were pretty similar but less complex as they mostly feature small stones. Again here we used some manually created maps to drive the distribution of small vs bigger pebbles that mostly accumulate on the side for example.

The toolset itself worked pretty well and as it was applicable as a template we could have a fully laid out shot in a day. Shot specific adjustments were applied on almost every shot though, mostly for continuity, visibility or art direction purpose. 

DP: Vegetation, environment, and FX were all dependent on one another. How did you keep versioning sane between departments?

Oliver Schulz:  That was a big topic indeed and it only is possible with two things: a rigorous approval system and a good pipeline that helps you track those approved layouts. We rely on our usd pipeline to do exactly that for us, it makes it somewhat easy (Im sure layout and production will hit me for this) to track department versioning. For each layout update we`d always get automatic QC renders that run through our inhouse “slapstick” system which is our inhouse auto comp engine.

When Layout would do a specific change it would publish this either on a shot or on an Sequence/Environment level. This will trigger a QC render from the shotcam of the affected shots. Once the rendering is done it will have a postjob that combines it with the prepped plate in nuke and runs another renderjob that will give you the layout reviewable which is than checked and can be approved and pushed into the pipeline from RV. This Layout than becomes available to the FX department which would run all needed simulations and hand off another QC reviewable for approval. Without those systems in place it would have been a nightmare to stay on top of all these versions!

DP: You said the layout department drove wind direction and strength instead of FX. How did that change your creative workflow?

Oliver Schulz: Yes that was indeed true and one of our early conversations we had internally to determine the approach all Environment builds would share. It was a practical decision based on two factors: We would simulate all vegetation on the asset level in different windspeeds for efficiency reasons and we wanted to keep iteration loops to a minimum.

This meant that I wanted to look at layout versions with moving vegetation as the strong directional wind would make it necessary to consider this already while layouting trees. As the direction is clearly visible you cant rely on spinning a tree 360 deg free in Y to create variations as the direction is “baked” in, so you need to see it moving in order to determine if an environment looks good!

The second reason is that FX needed to take care of vegetation simulation only once and when approved never needed to come back. This system worked really well and was accessible to the layout artists down to the single blade of grass, meaning one could really art direct where and how much specific things should move.

DP: You divided smoke into “hero” and “residual” categories. How did you manage density and readability without losing visual clarity?

Oliver Schulz: These two categories were simply based on the fact that we needed to deal with smoke in almost every shot. The ever present residual smoke needed to inherit a direction, needed to be art directable and also needed to render as fast as possible. Its pretty much the equivalent of atmospheric perspective in a wildfire scenario. Our Fx Supervisor Akin Göcmenli came up with a system of instanced presimulated caches that sometimes could consist of thousands of individual ones.

We started by doing simulations of smoke with a constant wind direction and speed that had a hidden source of emission and diffused pretty soon. That gave us a very soft falloff to the edges of the simulation grid which made these simulations perfect to overlap and look as one big single instance of smoke. On top due to those aspects it was quite easy to remove single containers and punch holes into the wall of smoke for visibility. We also invested a bit of time to develop shaders and render efficiencies to cut down on notoriously long volumetric rendertimes for this element.

Hero smoke was the category which either had a visible emission source in frame or simply had a hero storytelling element. These were usually shot or sequence simulations as they were mostly much denser and most of the time also much closer to camera. We also spend a good amount of time matching shading and simulation to real world references.  The secret to readability also lies in relentless QCing of outputs to make sure once you kickoff the expensive lighting renders, you are as certain as possible all elements are going to work. 

DP: The ember work looks incredibly detailed. How did you simulate believable motion in strong winds without visible repetition or looping patterns?

Oliver Schulz: Embers were a big part of the equations so by now you might guess…. Yes we spend a bit of time in asset prep to build some solid foundations. The first thing is of course the driving factor for all fx aspect: the wind.

FX developed hero wind forces that we used to simulate all elements with. A good amount of chaos and variance is key to not run into issues with readable patterns in any simulation. Another factor is collision. Embers will behave a certain way when they collide and thats what we tried to replicate. Also the ground plays a big role especially with the heavier emberclumps that slide over it.

Reality is unbeaten when it comes to little quirks and anomalies especially for something as complex as this. As no one is able to have a ground as detailed as the real world we also sometimes had a collision geometry that had slightly more displacement in order to have more detailed collisions happening. 

DP: Lighting and volumetrics are natural enemies. How did you maintain physically plausible lighting through that much smoke and fire?

Oliver Schulz: That was one of the biggest questions going into this project, considering that what was shot on set sometimes had very little to do with what ended up on screen, especially in terms of atmospherics. The best base for something to look real is to match the real thing. We did so in our asset phase and made sure our shaders and lightrigs were physically plausible, especially the ones only used to develop assets. 

We would match greyballs and reference macbeth charts in order to make sure scene lighting was correct in terms of lightbalancing. Then from there we developed shaders for all aspects.One of the most common issues I see is that volume and surface renders aren’t lookdeved in conjunction. What you end up having to do is to grade surface and volume render differently. This leads to very unrealistic renders very fast because there is no ground truth you can come back to.

We tried to make sure all our shaders worked with each other to have exactly this common base. Also when dealing with dozens of light sources and those issues on top that’s definitely a position you don’t want to be in when time is running…. All volumetrics do have very different properties to them where one of the biggest is how they scatter light. Back to front scattering can take a volume from being ultrabright to consuming all lighting energy and being pitchblack. So once you matched the real thing, use those tools wisely to deviate from there and support the story. 

We tried to always start with a balancing pass usually done still in lighting. This goes to comp as the foundation to do all the finetuning with. Still there was a lot of tuning left for comp and also we needed to break reality more than once to make sure that what you wanted to read in a frame remained readable when tons of smoke and fire went in front. Sometimes we needed to go as far as use the deep data to pull things in and out of the smoke to make them visible. Still the most valuable tool you have is the artist’s eye to determine the sweet spot of good vs real.

DP: You mentioned deep rendering bottlenecks, like OIIO running out of patience with too many AoVs. What exactly went wrong first?

Oliver Schulz: Haha yes that was one of the issues that came when switching to full deep with our renders. That means you have each component of each lightgroup rendered with deep data to put it back together in comp. That resulted in a lot of channels that apparently were too much for OIIO to handle. Thank god that was fixed otherwise I wouldn’t write this story now ;)

DP: Rendering holdouts took up to an hour per frame. Did you develop any automation or optimisation to make deep rendering less painful?

Oliver Schulz: Indeed rendering times for deep holdouts were quite painful and nothing to speed up really. With so many volumetric elements you need to deep hold out everything with everything to make sure its accurate. If you multiply this with the number of separate elements rendered and with the amount of light Aovs times the amount of components you end up with a staggering number of renders.

Plus in the end you need to denoise all frames so the best solution was try to plan out delivery dates as good as possible to have time for all those thousands prerenders to run on the farm. Still our compositing Supervisor Oliver Hohn and Lead Nicolas Burgers had some longer evenings ensuring all renders were there the next morning to be picked up by the compositing Artists.

DP: You used machine-learning depth generators to create deep data from plates. What tools powered that, and how reliable were the results?

Oliver Schulz: We started testing tools quite early in anticipation of very challenging compositing work. DepthAnything v2 was what we ended up using as a default prerender pass. The results were a mixed bag considering the wide range of plates we worked with, although it proved to be valuable to have. Comp remapped the relative value output of the depth passes to absolute values from deep data with help of lidarscans or renders and was able to create some good integration especially with more wispy type of smoke.

For denser smoke and more accurate holdouts especially for actors we still needed to rely on a lot of manual roto for good integration. The AI passes proved to be pretty successful though for fast temp work as you get something going in no time. Issues were mostly the missing good temporal stability and also the lack of precision. 

 DP: Before deploying new tech like ML depth generators or procedural ecosystems, how do you test them safely inside production?

Oliver Schulz: We implemented those during production directly on our project infrastructure, so developed, tested and used simultaneously. 

DP: Were there any spectacular ML depth map failures, like smoke reading as solid or background cliffs collapsing?

Oliver Schulz: Depth popping or lost shapes were the most common ones. But as none of these passes were used without correction in comp I’m sure I haven’t seen all of them!

DP: With so many volumetric layers, how did compositors manage complexity without drowning in passes?

Oliver Schulz: We have standard workflows for loading CG renders into nuke which do provide a basic level of organization. However the more elements you have the bigger the compscripts and we had some good ones for sure!

DP: Fire colouration is tricky. Did you use any spectral rendering or rely purely on LUTs to match on-set lighting and heat distortion?

Oliver Schulz: That is very true.. Luckily production tried to shoot everything with a practical fire which provided a good level of references in camera. If you than try to render as physically plausible as possible and have something in frame that you can match exposure to you are already halfway there. We didn’t use any spectral rendering here and rendered everything through Houdinis Karma in RGB.

DP: You switched to full motion-blur sampling for embers instead of faked streaks. How much did that impact render time, and was it worth it?

Oliver Schulz: Oh that was worth every minute of rendertime.. Real Motionblur for an element which is mainly visible in motionblur is a good investment. Plus the rendertimes weren’t actually that bad and took only a couple of minutes as you are not dealing with an expensive shading as well. The biggest benefit is getting nice curved and very interesting blurs especially with collisions.  The trick actually is to only invest time where its needed and render other elements with less costly settings. Deep compositing allows for it as you are not bound to any holdouts and you can combine differently rendered motion blur without any problems.

DP: How crucial was RiseFlow for distributing simulations and maintaining consistency across all sequences?

Oliver Schulz: We started implementing RiseFlow at the very beginning once we had our initial workflow for distributing elements figured out. The development was done by our Head of Pipeline Paul Schweizer and the implementation on the show was spearheaded by Jonas Sorgenfrei.

It actually is a very versatile framework that we use for a variety of tasks here at Rise. Its a modular node based System that can take arbitrary inputs and execute them in a chained workflow. FX built templates for various scenarios that got exposed variables like wind direction, speed, inputs for collision geometry etc. These could than be varied per shot and sent to the farm for execution. Once all those Sims were done, QC renders were submitted to the Farm and when completed, auto comped in Slapstick.

That meant that one artist could do changes on a big number of shots by adjusting the template and than resimming and rendering them over night. All render elements were deepcomped with our deep plate workflow and reviewed the next morning. This allowed for rapid adjustments and turnarounds which was a very crucial aspect of this fast paced production. 

DP: How did RiseFlow and Slapstick communicate between departments for reviews and dailies?

Oliver Schulz: RiseFlow and Slapstick are two different things really. The point where they communicate is that Riseflow might trigger a farmjob where Slapstick is hooked in as a post process that gets triggered after completion of the render. Slapstick again is a modular node based system implemented in Nuke that allows for a generalized template to be created. These inputs could take for instance all general elements that comp might use to layer a shot like mainplates, rotos, colorcorrections, lensdistortions etc and comp them together. We use Slapstick in all departments to create automatic reviewables for assetbuild like turntables with reference images, lighting slaps,fx slaps and so on.

DP: You’ve called The Lost Bus the toughest matchmove job you’ve ever seen. How did you solve the handheld, wet, low-light camera challenge?

Oliver Schulz: That was a tough one indeed. To solve this it really just comes down to the excellence of all individual artists that created those matchmoves. So there is no magic recipe to get through so many challenging matchmoves…

DP: Greengrass loves long, continuous takes. How did you manage to iterate and render efficiently on such heavy, unbroken shots?

Oliver Schulz: I guess it is really to choose your battles wisely… Invest into a good foundation early on and make sure to be as precise as possible in prep phase. Once the show is running and you are in full delivery mode there is no time to go back and redevelop anything.

Render optimization as much as possible and then relying on everything that was set up in the beginning is key to not have to think about accuracy anymore when you are trying to finish the shots. We did this and it really paid off, though having a couple of long shots with lots of elements to render we never ran into the issue of having to fear a render didn’t get finished in time.

There were some challenging shots for all departments involved but again the prep phase paid off and we managed to deliver everything in time. It’s really a Situation in which the Production team led by Michelle Cullen and Production Manager Androniki Nikolaou outdid themselves by planning and scheduling every milestone in production to make sure we had what we needed to finish shots in time. Of course that also means adjusting and revising this schedule each and every day based on client comments and changes.. It’s a tough job to make sure the whole production runs like a well oiled machine!

DP: Deep compositing only works if all layers align perfectly in space. Did you use diagnostic tools or pure visual QC to verify deep accuracy?

Oliver Schulz: The good thing about deep is that it’s pretty accurate as long as the sampling increments in depth are small enough for certain elements. It’s a game of keeping error thresholds low enough so you don’t pick them up actually. The balancing is precision versus filesize. Surface renders aren’t an issue really as you are dealing with front and backsides of hard surface objects really.

The fun starts with volumetric elements and this is where you need to tweak the settings a bit to make sure you don’t end up having 5GB per frame in volumetric renders. Still frames could grow to well over 1GB on bigger shots with all elements included, so we needed to do some rough calculations beforehand to make sure we weren’t running out of allocated serverspace.

DP: How did you maintain consistency for fire behaviour across sequences? Was there a single reference look, or did it evolve shot by shot?

Oliver Schulz: One of the big topics obviously here as the quality of the fire not only needed to remain consistent but also serve the story in how it behaves. When you look at fires in reality they all have very different qualities to them depending on a ton of external factors like what is burning, where it burns, what is the actual heat it produces and what is the influence of the wind and so on. So yes it’s crucial to pick a reference and not try to incorporate them all. The initial tactic we used was to create asset based fires with all components.

The two types that production defined as assets were “spotfires” and “forestfires”. Pretty generalized in description though mostly divided up by scale. So we took those two types into asset development and created a little scene with them. Forestfire in the background and spotfires in the foreground. This scene actually was the same one we used to lookdev all assets in. So we had a common ground for all assets really and the fx ones were not different.

We picked a general reference we felt was working well for each category and supplemented that with references that production had shot on set. The shot element though were mostly run by gas so wouldnt really emit any smoke but were a general ref in terms of breakup and edge qualities. Also those would come in native resolution where most of the actual refs are cellphone captures of much poorer quality.

So with all those references in place we started matching the fires again in different windspeeds. We tried to also implement all little details especially on the bigger forest fire like flambursts on dry wood, falling burning pieces of wood etc. Once fire was in place we hooked it up with all secondary elements like smoke and embers. We had already pretty robust setups developed for each of them individually so we could already build on a solid foundation using those as a base.

Once this little scene was successfully approved by production to go into shots we splitted out the individual components as assets again. These had all elements attached like smoke emission, ember emission, lots of different masks for heat distortion and were ready to be dropped into shots.

Using this technique we had a very solid foundation of very similar looking and behaving fires. Of course for hero shots we would need to resim those, but with setups in place and our template system it was mostly straightforward. Of course there are shots that need to tell a certain story like a fire coming right at you towards camera. Solving a problem like reading a perspective of a selfilluminating matter coming right towards camera is a different beast though you can’t prep for! This just takes a lot of creativity and trial and error to get right…

DP: What’s the single biggest creative takeaway from The Lost Bus you’d carry into your next show?

Oliver Schulz:  Don’t try to put out all the fires at once….

DP: Which shot makes you proudest or gives you flashbacks?

Oliver Schulz: Oh there are so many good ones really, honestly when I was watching all shots in a row I was so happy about the overall level of quality the team achieved in every aspect. So hard to pick singles but the Embercam full CG shots looked amazing on the big screen and were pretty spectacular… but getting them to the state we delivered them in was quite a journey…

DP: Finally, if you had to redo The Lost Bus from scratch, what would you rebuild first? Vegetation tools, compositing templates, or your caffeine reserves?

Oliver Schulz: Myself :)

The post Rendering the Inferno at RiseFX: The Lost Bus first appeared on DIGITAL PRODUCTION and was written by Bela Beier.