Character rigger Julen Armendariz has released WaveManager, a free Python-based tool for Autodesk Maya. The script generates procedural wave motion on any hierarchy of controls, using Maya’s native expression system instead of keyframes. WaveManager operates entirely through driven expressions, allowing a single driver control to manipulate the entire wave behaviour across a chain of objects. This approach makes it especially suitable for rigging and animating tentacles, tails, ropes, wings, or any FK-based control structure.

One Control to Rule Them All

All motion parameters are centralised in one driver. The available attributes—amplitude, speed, length, falloff, and offset—can be tuned independently or together, and they act simultaneously on the X, Y, and Z axes. The tool applies the wave procedurally, so timing and spacing adjustments propagate across the hierarchy in real time. Armendariz includes an optional Create Offset Group function. When enabled, the script inserts an additional node above each control, isolating the wave expression from the original animation channels. This keeps rigs non-destructive and clean for keyframed animation.

Fully Expression-Based

Unlike tools that rely on dynamic simulations or baked motion, WaveManager uses pure expressions in Maya. The result is a lightweight, deterministic system: behaviour is fully defined by a mathematical expression, with no simulation cache or physics overhead. Expressions can be removed per control or cleared globally with one command, returning the rig to its original state. The tool also includes Select Childs, an option that automatically collects all children of a selected control, simplifying setup for long FK chains.

Installation and Workflow

WaveManager is distributed as a single Python file. Installation is straightforward: drag and drop WaveManager.py into the Maya viewport, or execute it from the Script Editor. Users can create a custom shelf button for faster access. To use the tool, select the controls that should carry the wave, assign a single driver, and configure the desired parameters. All motion remains non-destructive and can be adjusted interactively during animation.

Non-Destructive, Animation-Friendly Design

Because expressions are stored separately from animation channels, artists can combine procedural motion with hand animation. This workflow is particularly valuable for rigging setups that require secondary motion or layered deformation without simulation. All expressions can be deleted at any time, leaving no residual data in the scene. The tool is entirely Python-based and uses only Maya’s built-in features, which ensures compatibility and avoids reliance on external plugins or compiled code.

Availability

WaveManager version 1.0 is available now as a free download under a pay-what-you-want model (listed at €0+). It can be obtained via Julen Armendariz’s release page. As with any utility, users should test the tool thoroughly before integrating it into production pipelines.

The post Free WaveManager Brings Procedural Motion to Maya first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Houdini users can now play chess directly in the viewport, courtesy of technical artist Mohamad Salame. The interactive chess tool relies entirely on VEX scripting for move logic and game state tracking. That means no simulation nodes, no rendering pipelines, and certainly no Python backdoors. It’s all handled inside Houdini’s SOP (Surface Operator) context, with every rule of chess implemented as raw VEX code. If you lose, don’t blame your renderer.

Learning Tool or Just Fun? Yes.

While not meant for production (unless your project is a very confusing FX-heavy Queen’s Gambit remake), the project highlights how logic systems and user interaction can be prototyped in Houdini using just VEX. Think of it as a conceptual playground rather than a feature request for SideFX.

Where to Download

The Houdini chess tool is available for free on Gumroad. No license fees, no royalties – just 64 squares of procedural decision-making. If you’re wondering whether chess belongs in your postproduction pipeline, the answer is: probably not. But if you’re curious how far VEX can be pushed for interactive logic and UI inside Houdini, this checkered curiosity might be worth a look. Or at least a quick match between caching sessions. Check before use, especially if your studio’s pipeline doesn’t include en passant.

The post Pawn to VEX: Chess Comes to Houdini’s Viewport first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

---

Procedural Animation Meets Seamless Loops

The latest addition to Gumroad’s asset library targets environment artists and animators looking for a reusable 3D looping animated tree. The asset comes with a key feature—its looping animation ensures uninterrupted playback for endless sequences, ideal for background motion in scenes demanding visual continuity.

Built for Flexibility

This animated tree is crafted using procedural techniques, enabling clean and customizable results. Procedural animation minimizes manual adjustments, saving time while ensuring the asset remains adaptable to various environments. The loop is engineered for smooth transitions, preventing noticeable starts or stops in animations, which can otherwise distract from the main visuals in your project.

Compatibility and Download Details

The asset, available for free on Gumroad, is optimized for seamless integration into industry-standard 3D and VFX tools. Whether you’re working with software like Blender, Maya, or Unreal Engine, the tree’s universal format makes importing hassle-free.

Price and Practical Notes

Cost: Free.
While the tree offers high adaptability and loop-ready functionality, production artists should evaluate its quality and compatibility within their pipelines before committing it to large-scale projects. Free assets are often excellent for experimentation but may lack the polish needed for high-stakes delivery. If you are happy with the tree, there is a library for little Money with many more of the green things :)

Looking to explore? Download the tree now and see how it fits into your next environment design.

The post Free 3D Looping Animated Tree Asset first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

A wild, prehistoric landscape – herds of dinosaurs roam the frosty plains, or sail through the snowstorm over the mountain ranges. In the undergrowth stirs a completely different, small group – primitive humans, but in this world they are among the hunted. They lie in wait for a creature that haunts their tribe, hoping to defeat it once and for all. But nature has other plans: they are surprised by a gigantic T-Rex and are forced to fight. However, they are powerless against the monster; their primitive weapons have no effect. In the end, only one of them remains, who bravely confronts the giant with his daggers..
This is how the short pilot film “We Hunt Giants” ends in terms of content; but the production began much more harmlessly.

The beginnings

Although Titus took the lead on the script, it was important to him to involve me from the first version of the book. On the one hand, I was able to think about the quantity and realisation of the VFX shots at an early stage. At the same time, I was able to give him critical feedback on the contrast with my own perspective on film and offer further creative suggestions from my side. One of these suggestions was, for example, to introduce the film with a vignette of different dinosaurs for a better worldbuilding – even if this would mean creating several additional dinosaurs in CG, which would be counterproductive.

While Titus was making revisions from his side, I began to create the first storyboard sketches and to build and cut a 3D pre-visualisation based on them. This gave me creative freedom to design the resolution & composition, as well as giving Titus the option to plan the shoot in a more focussed way. As the 3D scenes & cameras were scaled to real-life specifications, this allowed us to plan the technical side of the work on set in advance and identify any potential obstacles that could cause problems for the VFX work. This was particularly helpful when talking to cameraman Marcus Möller, as he not only got a better idea for the shoot on set, but was also able to contribute his own expertise. With a finalised 3D previs, shooting schedule and a well-rehearsed core team, nothing should now stand in the way of production.

The shoot

A few days before the shoot in February 2022, cameraman Marcus unexpectedly showed severe Covid symptoms and tested positive. However, giving up was not on the cards, as the equipment and transport had already been booked, and fortunately Andrés Rignell was found at the last minute to stand in for him. He had also already gained experience with VFX as a professional on various shoots and was very familiar with the camera system (RED Gemini). So we found ourselves for a weekend in Tyresta National Park south of Stockholm, and perfect for the first morning we were presented with an untouched winter wonderland, as it had snowed freshly overnight. So deep that even some of the rental cars got stuck in the snow on the last few metres to the film location.
To gain time, Andrés & I went off separately and started shooting various VFX plates while the rest of the crew freed the cars and prepared the actors. This allowed us to find a rhythm on the fly to gather references & camera data alongside the main takes. This was also important as we had to work with less daylight due to the winter season in the north, so some scenes were shot in a rush.

As soon as director Titus & I were happy with the takes of one shot, the actors were prepared for the next shot or recorded sound. Meanwhile, we were shooting quick cleanplates, noting camera specs, taking shots of lens grids, chrome & greyballs and a toy dinosaur for reference. This initially attracted some strange looks, but after a few shots there were always a few interested people around the camera monitor who wanted to catch a first “preview” of the prehistoric star. In every free minute or general break in filming, I also had to take separate photos of all possible references – actors, props, the surroundings & set design (a mini attrape for the dino trap) as well as additional Chromeball photos at different times of day so that an appropriate selection would be available depending on the shot.

Another result of the tight schedule was that almost all the shots were shot on location without any additional equipment – a blue screen was only used for a few specific shots where the VFX work would otherwise have been enormously complicated. After two intensive days of filming in the snow, I flew back to London to start preparing the VFX, while the material went into editing for the next few weeks.

Plate Prep

Finally, all the footage from the shoot was sent to London in the post as RED raw files, along with the first rough cut. Nuke Indie allowed the EDL of the cut to be imported directly and the individual shots to be exported in separate Nuke scripts. For further processing, the plates were reduced from 5K to 2.5k and saved locally as OpenEXR sequences. As the editing was still in progress in Sweden, the sequences were exported with extra leeway to be on the safe side and all tracked in 3D in Nuke Indie for the matchmoving. Thanks to the quality of the shots and the rich texture of the environment, an automatic 3D track usually produced a high-quality result, and it was rarely necessary to intervene with manual tracks or further manual work.

Based on the 3D track, 3D meshes of the environment could also be generated in Nuke at the same time using point clouds. Fortunately, despite initial fears, only a few shots had to be retouched to remove isolated references to the park such as fences or signs. However, the small amount of bluescreens would mean that every interaction with VFX would have to be rotoscoped by hand – some of the shots would end up spending several days or weeks exclusively in rotoscoping. Luckily, a friend and former colleague, Dominik Platen, stepped in towards the end of post-production and took care of the rotoscoping for some shots.

Dinosaur assets

Before filming began, thorough internet research was carried out for each dinosaur. Drawings & photos of skeletons, artistic reconstructions & screenshots from films, as well as material from related species were collected to provide further references. For the main dinosaur in particular, we initially considered a range of large theropods, but Titus was keen to use a T-Rex as a homage to Jurassic Park. In the end, we allowed ourselves a little variation – the bony dorsal crest was inspired by another theropod, the Acrocanthosaurus.
All 3D models were first roughly pre-built in 3ds Max, and then detailed and textured in Mudbox. A method that had proved successful in previous work was again used for the texturing:
For each dinosaur, a small library of base textures, masks and further grunge maps were painted onto the surface, which were then combined together with normal & displacement maps in Nuke via compositing to create a finished texture.

This process, although hardware-hungry, allowed free experimentation with various options & details, all simultaneously on multiple UDIMs in a non-destructive environment. In addition to the main texture, maps for shader attributes could also be “combed” in this way.
This was particularly important for the T-Rex: the model should give an idea that the dinosaur led a rough existence, in the form of scars and wounds from past confrontations. Other ailments such as frostbite & inflammation should indicate that it is actually not welcome as an invasive species in the cold.

With the texture compositing in Nuke, a suitable balance could be found quite quickly over a few iterations. At least one dinosaur was spared all the work, as the CG asset from “Tucki”, a past project, could be directly reused for a small guest appearance. You can read all about Tucki in DP 21:02, or download it for free here is.gd/tucki_pdf.

Rigging & Animation

For the rigging we went back to 3ds Max. As a tried and tested module, each dinosaur was given a special rig in the Character Animation Toolkit, CAT for short, which could be saved as presets for the subsequent animation process.
To save time during rigging and animation, shortcuts were built into the rig for each asset. For example, the flight membranes of the pterosaurs were animated using a cloth simulation, and the tails of all dinosaurs were procedurally controlled with spring constraints to create a flowing organic movement without further manual intervention.

In turn, the T-Rex received an additional upgrade due to its presence in the film: a simplified skeleton and part of the musculature were modelled for the asset, which in turn formed the basis for a tissue simulation in Houdini using the newer Vellum-based Tissue System. The result was subtle, but provided better deformation and volume on the final animated asset. One advantage of working via CAT rig presets in 3ds Max was that the animations could be saved as separate clip files and transferred to identical rigs later. In this way, the animation scenes were kept very performant without having to load the entire asset. Possible revisions could also be quickly transferred to the corresponding main 3D scene later using a new clip.

For the animation, which was done exclusively with keyframes, it was important that all dinosaurs should reflect natural behaviour. In addition, the T-Rex should appear more aggressive than usual, which may also be due to the injuries. Smaller tics such as snorting, snarling and more impulsive movements helped with this. The animation would also have a strong influence on the editing; scenes were often extended to give the dinosaurs more time to perform.

For one particular scene, which features a herd of 20 dinosaurs, a crowd system was not used. Instead, I spent a weekend animating various actions with excess length – eating, head shaking, sleeping, looking out, running, etc. – which were then placed by hand using animation caches and staggered in time to get the appropriate variation. For a quick turnaround, it was advantageous that the individual animations did not have to be too detailed, as they would all blur together in the mass.

FX simulations

A critical point in the project was the FX simulations, as all the dinosaurs had to interact with the cold snow world. A few systems could be prepared directly in 3ds Max & Particle Flow, but Houdini was used for the rest.

For the most part, snow tracks were created procedurally using geometry; a few shots were even given a dynamic simulation with Houdini Grains, insofar as the interaction had to be represented much more subtly. An important component was also frozen breath for the T-Rex and finely swirled snow dust, which were simulated with PyroFX in Houdini. All Houdini project files were created in such a way that, depending on the shot, only the
correct assets for dinosaurs & environment had to be loaded & exchanged, with a little adjustment afterwards.

Otherwise, separate simulations were created for one or the other shot in the respective tool where it was best suited – such as a flock of birds in Particle Flow (3ds Max) or water splashes with fluids in Houdini. For simpler particle effects such as atmosphere, snowflakes, sparks and more, we even used Nuke Particles, which were incorporated as part of the compositing process.

In contrast, the most prominent FX interaction – where the T-Rex violently squeezes through two trees in one moment – was primarily animated by hand. Springs were again used in the rigging so that the bending of the branches did not have to be simulated. A secondary layer of different FX sims from 3ds Max & Houdini combined gave the moment the finishing touches.

Rendering & compositing

All elements were lit & rendered in 3ds Max with V-Ray; caches from Houdini were exported and imported as either VDBs or Alembics. All dinosaurs & snow elements were rendered directly with surface scattering, whereby the intensity of the scattering was slightly exaggerated in order to benefit from the additional details in the shading.
The lighting rig was kept quite simple to limit the amount of render passes – after all, all shots had to be rendered on a single desktop PC. For each CG element there was an average of 3-4 setups, one for each light and a separate data pass with geometric or vector-based render layers such as Zdepth, Velocity & Position.
As each element in this multi-pass setup was rendered separately, this resulted in countless renders, but only in rare cases did a pass exceed a render time of a few minutes per frame. The immense advantage of this setup was the compositing; the lighting & shading could be manually adjusted for each individual CG element without the need for a second render
a second rendering process was required. A comp template in Nuke, which had been refined over the years for V-Ray passes, helped with this, and changes could later be copied directly from one shot to another. Additional details such as dirt, blood and snow were often projected onto the surface of the dinosaurs using the geometric render layers, either as procedural setups or with prepared textures.
Thanks to the references & cleanplates on set, the integration process for the dinosaurs was quite effortless and the compositing template proved to be very robust.
Some shots also required a few more invisible compositing tricks: for example, in the final shot of the film, one of the hunters faces the T-Rex, but it was not possible on set to make the fur jacket flap in the wind as it roared. So a CG plane was generated in 3ds Max via Cloth-Sim and exported to Nuke, where it served as the basis for a 2D projection of the rotoscoped fur. Additional distortion filters created the impression of turbulent fur.

Environments

Environments also played a major role in the VFX. To keep the shooting schedule efficient, all shots were filmed in the same location – for example, during the first half of the film, the actors stared at the same hill in the distance where they would later be chased down by the T-Rex.
So with the help of digital matte painting, the hill had to be transformed into a flat plane, which was primarily done with alternative plates & more photographs. In addition, a somewhat more threatening sky and more atmospheric fog from the snowfall were added. The forest in the background, on the other hand, could be partially retained and was merely expanded; plates from the shoot with shaken trees helped to give the impression that a larger animal was in the background
to give the impression of a larger animal stalking around in the distance.
The trap was also collaged together from photographs of the smaller set on set, and a CG pole with a chopped off leg from one of the existing dinosaur assets added the finishing touches. In view of the fact that the DMP would be visible over an entire sequence, it was designed from the outset as a 3D projection in Nuke with simple geometry. Depending on the shot, the Matchmove camera or the DMP could be easily moved into position.

The opening shot of the film, in which a couple of pterosaurs fly through a snowstorm, was based on a drone shot of a mountain range at sunset, and followed a group of sled dogs. A new stormy sky was added, the dogs and other anachronistic objects were painted out, and Nuke Particles were used to generate a completely new atmosphere for the pterosaurs to freely interact with.

Digital double, weapons & wounds

During the confrontation, one of the humans, Hunter (played by Urban Bergsten), is scooped up by the T-Rex and thrown around. It was clear from the first draft of the script that a digital double would be needed for this moment, and during the shoot there was an extra photoshoot with the actor Urban in costume. The corresponding asset was built quite simply, as it would only be visible for a few seconds with a lot of blurring.

A male figure from the open source programme ‘MakeHuman’ served as the basis, with the model being slightly adapted to Urban in advance. The photos from the shoot were projected directly onto the models of the body and clothing; to suggest more details, while the model could remain quite simple. Instead, cloth simulations & a simple hair groom helped to make the character look more organic, animated with keyframes.
All the weapon props were also photographed on set and recreated quite simply on the base. With a little secondary animation, it was possible to create the impression that the weapons were dangling from the body and could be detached if necessary.
The digital props were also used in other shots. In one case, a digital bow was placed in the hand of one of the characters to cover up a mistake in the editing; another time, a spear throw had to be digitally replaced so that it could interact with the dinosaur.
Plates were originally shot for another shot in which Urban is grabbed directly, but because the moment was redesigned in post-production, the digidouble was also used here. With the help of a new camera, an environment assembled from various cleanplates and a few animation tests, the desired shot was found and was now realised entirely in CG. After the high-altitude ride, Hunter/Urban lands violently in the snow, and the (graphic) consequences are clearly recognisable – his body is torn open from the bite & the fall, and he is missing an eye. Despite a bit of practical facial make-up on set, the result wasn’t scary enough, so a bit of a rush job had to be done towards the end. After an initial (stomach-churning) online search for references, digital DMP patches or projections for wounds, blood spatter and torn clothing were created directly in Nuke for each individual shot. Depending on the situation, individual parts of the body were tracked in 3D or analysed using Smartvector in order to project the elements. Small variations were incorporated into the track for each level, giving the impression, for example, that wounds/skin and clothing moved independently of each other as the person squirmed.

The hunt continues.

In mid-May 2023, after around a whole year of work, all the VFX shots were finally finalised and delivered. The film went into colour correction & final mixing for another month, followed by the premiere in early June in the heart of Stockholm.
As the short film was also conceived as a pilot/pitch, they are already striving for higher things – while the film is enjoying initial success at festivals, the makers are already working on the first script version for a feature-length film. It is still far too early to say what the outcome will be. But we can only hope that the journey into this primeval world is not yet over, despite its dangers.

The post We Hunt Giants first appeared on DIGITAL PRODUCTION and was written by Andreas Feix.

There are features in Blender that users have been waiting decades for. Until now, these have included a new particle system developed from scratch. In Blender 3.6, an alternative to the outdated, conventional particles is now finally available: The “Simulation Area” in the Geometry Nodes. As a side effect, not only particles can be simulated, but also cloth, soft bodies, etc. However, you still have to create the simulation manually from scratch. And that’s what we’re going to do in this article using a particle system as an example.

Burn, logo, burn!

As a concrete example, an object should burst into flames, because the fire simulation in Blender also has its quirks, so we use an old-school particle simulation for a stylised fire effect. The Digital Production logo serves as an example object, but you can use any other 3D object.

What actually is a Simulation in Blender?

In Blender, all processes whose state in a frame depends on the state in the previous frame are a simulation.
This classically includes particles, Cloth, Soft Bodies, Rigid Bodies, Fire, Water, Smoke and the Blender speciality “Dynamic Paint”. On the other hand, there are tools such as the modifiers from the “Modify”, “Generate” and “Deform” categories as well as
geometry Nodes, where each frame can be each frame is independent of the others.

Simulation Zone

In Blender 3.6, you can now set up a so-called “Simulation Zone” in these geometry nodes zone”, which is the area in which the simulations run. You can visualise this as follows. At the input of the simulation zone you can feed in data. These are read out once and remain in the simulation zone from then on Simulation zone. Processed data can be output. These are then fed back into the simulation in the next frame via sent back to the simulation zone via the input and can be further processed there. This can be the position of a particle, but also its size or any other property size or any other property, which can be accessed with Geometry Nodes. Changing the size with the lifetime of a particle, for example, was previously not possible at all. Thanks to geometry nodes, we now have almost complete freedom when it comes to the structure of particle systems. However, this is still accompanied by the requirement that you have to create everything yourself. On the geometry node side, Blender 3.6 only offers the simulation zone and the associated features such as baking, but not yet any high-level tools such as emitters or force fields. These will probably be delivered in the future as nodegroup assets similar to the hair assets that have found their way into Blender 3.5. Until then, however, manual work is the order of the day.

Create a new scene and leave the default cube

Leave the default cube alive for a change. It should act as a container for our particle system. It is best to give it a suitable name such as “Particle Nodes Container” using the shortcut F2. Then switch to the Geometry Nodes workspace and click on “New” to create a new node tree. Assign a suitable name here too, such as “Fire Particle System”.

Enter the Zone

Use “Shift A – Simulation – Simulation Zone” to create a sub-zone in which the simulation will take place later. This is highlighted in burgundy and has its own input and output. If nodes are interposed, the highlighted area becomes larger. Nodes that are located within it have access to simulation data and are themselves part of the Simulation. Nodes from outside can be connected to the nodes in the zone, but then have no access to the simulation themselves, which will prove to be practical later on.

Distribute points on surfaces

A particle system is based on points, so our first task is to add them. For now, the geometry of the default cube will serve as the emitter. Add a “Point – Distribute Points on Faces” node and place it between the geometry inputs and outputs of the simulation zone. Nothing should happen yet, however, as the simulation zone is not yet connected to anything. Drag the geometry output of the simulation output node to the geometry input of the group output node and the geometry input of the group input node to the input of the simulation input node with the same name. If the playhead in the timeline is set to frame 1, points should now appear in the viewport.

Set in motion

However, the dots are not yet moving, i.e. we have a particle system but not yet a simulation. A node that changes or updates the position of the particles in each frame is still missing. Add a “Geometry – Write – Set Position” node and place it between the Points output of the Distribute Points on Faces node and the Geometry input of the Simulation Output node. Under “Offset”, set the value for Z to 0.1. If you now start the animation from frame 1, the particles move upwards at a constant speed, as 0.1 is added to the Z position in each frame.

My first Particle system

Congratulations, you have just created your first own particle system with the Blender Simulation Nodes. It consists of an emitter that distributes particles on the surfaces of the input object. These particles are shifted upwards by a constant factor in each frame. The structure corresponds to a legacy blender particle system in which the start and end of the particle emission fall on the same frame.

Influence from outside

Another typical way of emitting particles is recurring emission over several frames, a kind of inflow object. This is also the default setting of the legacy particle system. In the simulation nodes, we have to regularly add new particles from outside the simulation area. This requires an additional object. At this point, the previous cube becomes the container of the particle system and another object takes on the role of the emitter.

It’s a logo!

In our example, we use the DP logo, but you can use any mesh objects. Add an “Input – Scene – Object Info” node. This has an orange input socket. Connect it to the empty socket of the group input node. An input field for objects now appears in the modifier. You can name it by opening the sidebar in the Node Editor with the N key and entering a suitable name such as “Emitter Object” in the Group tab under “Inputs”. You can even define a tooltip here.

Degraded to a mere container

Switch the object info node to “Relative” so that the points also appear in the correct position later if you move, scale or rotate the object. Then connect the geometry output to the mesh input of the Distribute Points on Faces node and disconnect the geometry input of the Simulation Input node. This cuts the connection to the original geometry of the cube; it is now just a container for the simulation.

Union

Add an object of your choice to the scene and select it in the Geometry Nodes modifier of the container. If you now play the animation from frame one using the space bar, particles will only appear once again. In order for the emitter to emit particles permanently, the newly added points must be merged with the existing ones in each step.
Add a “Geometry – Join Geometry” node and place it on the connection between “Distribute Points on Face” and “Set Position”. The Join Geometry node has a slightly elongated input socket. This illustration is intended to indicate that any number of nodes can be plugged in here. Connect the geometry output of the simulation input node to it.

Randomness at any time

If you now start the simulation from frame one, you will see a stream of particles from the emitter. But they still look like threads because they are generated from exactly the same position on the surface of the object at each frame. However, we need a different distribution in each frame so that it looks like particles are being emitted from the entire surface. Add a node “Input – Scene – Scene Time” and connect the frame output to the seed input of the Distribute Points on Faces node. Also connect the Density input of the node to the empty socket of the Group Input node in order to be able to control the emission density from outside.

Animated particle emission

If you now play the animation, you will not only see a particle beam flying away from your object, you can even animate how many particles the emitter generates per frame. This was previously not so easy to do with the legacy particle system in Blender. This is where the strength of Simulation Nodes comes into play, because you no longer have to worry about such limitations.

For life

Another feature of particle systems is the option of giving each particle a lifetime and reading out its current age. In the simulation nodes, we achieve this by setting an “age” attribute for each point at birth, which is then incremented by one in each frame. Add a node “Attribute – Capture Attribute” between Distribute Points on Faces and Join Geometry. A float with the value 0.0 is now assigned to each point when it is created. Connect the attribute output to the empty input socket of the simulation output node. A corresponding output now appears at the simulation input node.

Marry

Just as with the Join Geometry node for the points, we also need to find a way to “marry” the age of the existing particles with the newly added ones. Add a “Utilities – Math – Math” node. This is already set to the correct “Add” operation by default. Now all particles have the attribute and it is looped through the simulation. However, we are not yet counting up. Duplicate the add node and place it between the existing add node and the simulation output node and set the value in the lower input to 1.0. Now one is added to the age with each frame.

Age vs. lifetime

Age has not yet had any effect. We can use it to make particles die or disappear after a certain time in frames. Duplicate one of the add nodes and place it in a free area in the simulation zone. Connect the upper input to the second add node and change the The operation to “Greater Than”. Add then use “Input – Group – Group Input” to add another Group Input node and connect the threshold input of the Greater Than node to the free socket of the Socket of the group input node. Name the new parameter “Lifetime”, a default value of 50.0 makes sense here. Add a “Geometry – Operations – Delete Geometry” node and place it between the Geometry output of the Set Position node and the Geometry input of the Simulation Output node. Connect the Selection input to the the Value output of the Greater Than Node. From now on, all particles that are older than their lifetime will be removed from the simulation. If you play the animation now, the particles will disappear again from frame 50.

Normalisation

We can also use the age of the points as an output attribute so that we can later colour the particles differently in Cycles depending on their age. As Cycles likes to be fed with values between 0.0 and 1.0, we should normalise it to this value range beforehand. First connect the attribute output of the simulation output node to the free socket of the group output node. If you now open the Ouput Attributes panel in the modifier, you will see an empty field. Here you can later give the attribute a name so that you can access it in the shader, e.g. “age”. It will then also appear as a separate column in the Spreadsheet Editor. You can change the labelling of the field and the tooltip again in the Group tab of the sidebar of the Node Editor, for example to “Age”.

Force fields

The second component we would add to the legacy particle system would be force fields to control the movement of the particles. In the simulation nodes, this is done within the simulation zone via vectors that control the offset of the Set Position node. In our case these would be two components. A kind of wind that blows the particles in a desired direction and a field for swirling. We can simplify the wind extremely by assuming a constant movement in one direction. If we add a Z component, we have also integrated the buoyancy.

Drift

Connect the offset input of the Set Position node to the free socket of the Group Input node and name the newly created input “Wind Force”. A value of 0.05, 0.01 and 0.025 causes the particles to drift gently and slightly backwards.

Swirl

We need a second force to swirl the particles. We can extract this from a noise texture. This is because the RGB colours of the texture can also be interpreted as XYZ values of a vector. These must be merged with the previous forces, again using maths. Add a “Utilities – Vector – Vector Math” node and place it between the wind force socket of the Group Input node and the offset input of the Set Position node. Click on the lower, free vector input of the add node and drag the mouse to a free position. There should be a plus symbol next to the mouse cursor. If you now release the mouse, a search field will appear. Enter “Noise” there and select “Noise Texture – Colour” from the search results.

Adjustments

A noise texture appears whose colour output is directly connected to the vector input of the add node. If you now play the animation, the particles shoot off at a diagonal. This is because the noise texture only outputs positive values between 0.0 and 1.0 for each channel. The result should be colours, and their channel values are defined in Blender as a Range between 0.0 and 1.0.

Negative

However, the particles should move in all directions, even in the opposite direction to an axis, i.e. in a negative direction. To achieve this, we have to subtract 0.5 from all channels, then the range is between -0.5 and 0.5. Duplicate the Vector Math node, place it between the colour output of the Noise Texture node and the existing Vector Math node, which is currently set to “Add”, and set the operator of the new node to “Subtract”. Enter 0.5, 0.5 and 0.5 in the lower vector field.

Buzz

If you now play the animation, you will see quite a hustle and bustle. The turbulence caused by the noise texture is still much too strong. Duplicate a Vector Math node again, place it between Subtract and Add and set the operation to “Scale”. Set the lower input to 0.2 and connect it to the free socket of the to the free socket of the Group Input Node. Name the new input parameter “Turbulence Strength” and view the animation. Set the Lifetime to 100 and the particles will now be swirled around by the noise texture.

Control

How coarse or fine the turbulence is can be controlled via the scale input of the noise texture node. Set it to 1.0 and also connect it to the Group Input node and name the parameter “Turbulence Scale”. If you now play the animation, the particles will flow as if you had added a turbulence force field to a legacy particle system and set the flow value to 1.0. However, this stream-like flow is not quite the way fire moves. The flames flicker and constantly change direction.

The fourth dimension

To simulate this effect with the Noise Texture, switch the drop-down in the Noise Texture to “4D”. A new input “W” has now been added. This can be used to permanently change the noise texture. In other programmes, the parameter is called “Evolution”, which really is a good name. To animate this, you do not need to set any keyframes. Instead, connect it to the Seconds output of the Scene Time node and the particles will wobble and flicker when the animation is played.

Set material

Before you can move on to shading, you need to give the particles a material. To do this, add a “Material – Set Material” node between the geometry output of the simulation output node and the geometry input of the group output node. Select an existing material from the drop-down menu and edit the name and the shader in the next step.

Rendering in Cycles

To render the particles, we need the Cycles render engine, as Eevee cannot yet display the points. In the Render tab of the Properties Editor, change the render engine to Cycles and switch to the Shading Workspace. Switch on the Render Preview in the viewport; the particles now appear as small spheres. In the Shader Editor, select the same material in the material drop-down that you have also assigned in the geometry nodes. Now you can also change the name, e.g. to “Particle Material”.

Cycles should recognise them by their name

Add a new node “Input – Attribute” and enter the exact name you have given to the Age attribute in the “Name” field and connect the Fac output to the Base Colour input of the Principled BSDF node. The particles are now coloured in a gradient from black to white, depending on their age. The perfect input for a colour ramp.

Ramp

Insert a “Converter – Colour Ramp” node between Fac and Base Color. Set another stop by pressing the plus icon of the node and set the stop on the far left to a light, desaturated orange. Then set the value for “Value” in the colour wheel to 5.0. Now the particles reflect more light than hits them. A nice effect, which is not physically correct at all, but gives a little more detail than when using emission. Set the second stop to a rich red with a value of 2.0 and the last stop to pure black. Also set the interpolation in the dropdown in the top right-hand corner of the node to “Ease”.

Fadeout

The spheres are now coloured, but it would be nice if they fade out as if the flames were burning out or dissipating like smoke. Connect the Fac output of the Attribute node to the Alpha input of the Principled BSDF node. Now it looks as if the logo is smoking at the beginning and the smoke is turning into fire. For the fire to finally fade out, we need another colour ramp. Set three stops again and the interpolation to “Ease”. The centre stop is given a pure white and the right-hand stop a pure black. The left stop is given a value of 0.1 so that the particles on the emitter are still slightly visible and virtually envelop it.

Artefacts

Black artefacts should now have appeared in the tips of the flames, depending on how many particles you use. The black spots are caused by the fact that Cycles only visits a certain number of surfaces, the so-called bounces. And every time a ray passes through one of the spheres, that’s two transparent bounces. Set the number of transparent bounces in the Light Paths panel of the Render Properties to 256. Now the flame tongues fade out cleanly.

Light and shadow

As the particles in our setup are dependent on light from outside to glow, it is worth loading an HDRI texture into the world. You can achieve the black background by opening the “Ray Visibility” panel in the world properties and unchecking “Camera” and “Glossy”. The latter is a small preparatory step for the next step.

Laying the floor

Add a tarp to the scene and scale it by a factor of 50. Then add a new material and set the value for “Metallic” in the Principled BSDF node to 1.0. You can adjust the strength of the reflection by making the base colour lighter or darker. For an exact replication of the result, set the value of “Value” in the colour selection of the base colour to 0.5. Next, delete the light source that is still present and, if necessary, make the material of the emitter object darker so that it is clearly recognisable in contrast to the light “smoke”.

Bake a cake

After placing the camera, it’s time to render. You can render both a still image and an animation. It would be practical if the simulation data could be saved so that you don’t have to simulate again and again. This process is called “Baking” and can be found for the simulation nodes in the Physics tab of the Properties Editor. Open the Simulation Nodes panel there and click on “Bake”. All frames in the timeline are now simulated and saved. A new simulation is not necessary.

Outlook

This article was intended to provide an overview of how particle systems in the new are structured in the new simulation nodes. From this basis you can proceed further. You could also change the radius of the particles with age. A feature that is also not so easily possible with the legacy particle system. Or you can modify it so that the time-dependent calculations always take place in seconds instead of frames, making your system independent of the project’s frame rate. In order to make the fire flicker even better, you could also
also modulate the emission with a safely time-varying noise texture. Even more: you can make the result more realistic by giving the particles a very slight initial velocity along the normal of the emission object.

Conclusion

With the new simulation nodes in Blender 3.6, particle systems can be created whose thickness exceeds that of the existing legacy particle system. Thanks to the power of the geometry nodes, there is enormous potential ahead of you, but it still needs to be realised. Because there are still no high-level nodes, you have to click together things like an emitter or a force field yourself. It is to be expected that there will be numerous node groups and assets in the future, both from the developers themselves and from the community.

The post Your own particle system with simulation nodes first appeared on DIGITAL PRODUCTION and was written by Gottfried Hofmann.