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.

A tasting of the dynamics and geometrys side (of) effects

This release is not about the number of features, but about finishing what was started, achieving true production readiness, robustness, performance, and ease of use. It’s a version focused on quality of life. Feature sets like MPM simulations and Karma have matured like a good wine. The machine learning tools respect the artist’s skill set and have left their state of play are actual usefull in production.

Even though SideFX remains modest in its official statements, Houdini 21 is a massive release. For the feature-hungry among us, the highlights include a fully matured APEX; a refined and clever animation and rigging framework; a simulating Copernicus (think Substance on Dope), and in the VFX realm, the production-ready MPM Solver. On top of that, we’re seeing machine learning tools popping up in all the right places (AI for people who don’t expect a Pixar film from a single click), faster and expanded rendering with Karma, and a healthy dose of quality-of-life improvements.

Since our editorial cat can only count to 300, we can’t tell you the exact number of new or improved features, but we’re impressed nonetheless. And soon, you will be too. To avoid overwhelming both writer and reader, we’re breaking this article into a mini-series. We’ll start with VFX & Geometry, followed by Solaris & Karma, Copernicus & Terrain, and the massive Animation & Rigging tools.

MPM

One of the most exciting additions in H20.5 was without question the MPM Solver. The MaterialPointMethod truly allows you to simulate a wide range of different materials. From water, snow, and sand to honey, metal, and concrete, all within a single Solver setup. The geometry is simply substituted by points or particles, which are then simulated. The different materials interact physically accurate and constraint-free, purely based on their assigned parameters.

The initial release was already impressive, but it left users standing somewhat in the simulated rain when asking: “How do I get a proper mesh with UVs?” That exact issue has now been beautifully solved in H21. Any MPM simulation, whether rigid body or fluid, can now be meshed (as polygons or SDF volumes), including UVs, color, and other attributes, using no more than two nodes.

A nice and usefull addition to this workflow is the MPM Debris node, which generates new points along fracture lines as sources for smoke, dirt, or secondary debris effects. So let’s take a look at meshing hard and fluid or granular surfaces across a few setups and scenarios and wrap things up with a creamed cookies drink while watching the official and very excellent MPM demo.

Surfacing MPM Simulations

Testing time! For this test setup, we’ll have a clay ball smash into a vase model, paying close attention to UV transfer and the generation of smaller fragments through the Debris Source. The easiest way to start an MPM simulation is by typing “MPM Configure” into the node search. This gives you a complete set of starter nodes right away. (Under MPM Configure, you’ll also find plenty of additional example setups for study or creative repurposing.) By the way, the MPM container on the far right controls the overall resolution of the entire simulation.

We replace the default sphere with our own model and can now assign materials directly inside the mpmSource node and tweak them to our liking. It’s genuinely fun. Feels a bit like a mini-game. Since a concrete material would be more realistic but also quite boring as a vase material, we went with Chunky Snow instead. The environment comes in via an Object Merge directly into the mpmCollider Sop, ready to go. Our clay ball, the antagonist of this little simulation, isn’t a collider per definition but another mpmSource ready to be smashed, merged with the vase and given its own material behavior, Chunk Soil.

To make sure the particles can actually see and “love” each other, we need to enable Particle-Level Collision in the solver. The new Auto Sleep feature helps keep the vase passive until the collision happens, preventing it from collapsing at frame one and saving quite a bit of compute time.

Since the clay ball will be meshed as a fluid and granular surface and the vase as a rigid object, we first separate the MPM particles using a Blast node, filtering them by their respective source names.

For surfacing the vase, we use the mpmPostFracture node, which takes the rest-geometry and the MPM particles as input. This node essentially breaks the geometry apart “end to start,” so it needs to be fed the final frame of the simulation. After that, we choose either Voronoi or Boolean Cut as the fracture method. The latter can generate interior details, subtle irregularities on the inner faces of the fracture, that weren’t visible before, and it’s also faster to compute. We can further control the number of pieces as well as define the minimum fragment size at which new pieces should be generated.

The final node in the chain is mpmDeformPieces, which transfers the newly generated fracture geometry onto the MPM particles and just like that, the vase shards, physically convinced they’re made of snow, go flying through the scene, complete with perfectly intact UVs. For more of a muddy mess, we could have generated a liquid or granular surface instead, but we’ll save that for the clay ball. The result from the Debris Source, which lets you precisely define when and where particles based on fracture are emitted, is then passed into a POP network, including collisions from the vase and background).

Time to get serious:

Continuos Emissions & Surface Tension

With this new option, you can quickly fill containers, simulate expanding materials, or layer different materials on top of each other. The option is located in the mpmource node and spreads new particles apart using positive pressure.

Let’s take our vase and let a thick, viscous something ooze out of it. A good chance to show how simple MPM can be: if we want things to float inside the fluid, they just need a lower density. A few cubes are generated and assigned a jelly material. Two geometries, two MPM Sources, merged and fed into the solver. That’s all it takes. Just as easily, you can mix different fluids within the same setup. And for a bit more drama, we can dive into the solver and add a POP Wind node with some turbulence.

Surface tension allows for realistic effects such as droplets, tendrils, and flowing water. H21 introduces two new ways to control surface tension for both liquid and viscous materials inside the MPM Solver. The Point Based method offers higher accuracy and stability, making it ideal for small and detailed simulations. The Grid Based method, on the other hand, is optimized for performance and handles millions of particles more efficiently, which makes it better suited for large-scale scenes. External forces and friction can be increased if objects keep moving when they shouldn’t. Otherwise, you might end up with a scene straight out of Terminator 2.

To achieve high levels of detail without an unnecessarily large number of simulation points, the new, more precise collision detection allows you to use the fracture edges of a simulation as the source for a targeted secondary simulation. The attribute Jp (Plastic Compression/Stretching) is key here. It can be used to isolate the fractured areas and feed them into a Surfacing node set to VDB mode. This resulting volume can then serve as the source for the second simulation. And don’t forget to use the main simulation result as a collider.

And finally to top it off, the official demo. A detailed breakdown of that beautiful cookie shot.

Machine Learning in Dynamics

You won’t find any generative AI native in Houdini, but rather a growing collection of smart, locally running models, often trained by yourself, designed to simplify or speed up time-consuming tasks.

Surfacing Flip, Vellum & Particle Simulations

Alongside Neural Point Surfacing for MPM, the new Neural Point Surface and proven Particle Fluid Surface nodes now bring neural meshing to FLIP, Vellum, and POP simulations as well. Until now a bunch of points are trying to reconstruct the surface of a material. With neural meshing, you can now achieve much sharper, more detailed surfaces across a both high and low frequencies. The result: surfaces that are no longer uniformly fuzzy, but crisp, structured, and temporally stable. As before, you can train your own models, but even the included presets already produce finer details. And thankfully, the whole thing is GPU-accelerated.

Volume Upres

The core problem behind volume up-resing: for efficiency, artists often create and approve low-resolution simulations. But once the voxeldensity is increased, the overall shape of the sim tends to change. With the new tools, a low-res simulation can now be upscaled while preserving its exact shape. This not only keeps previously approved versions intact, but also allows for far more iterations. A model that’s been trained on a specific motion or behavior can now upscale multiple variations of it.

The Billowy Smoke recipe (or shelf tool) comes with a pretrained up-res model already integrated. Let’s start by looking at a comparison between the low-res input simulation and the 3× up-res result.

Details are nicely added, while the overall shape is preserved impressively well. Caching took a bit of time, but it’s still far faster than running a full high-res simulation. The real idea, however, is that we can now reuse this up-res model for all our future Billowy Smoke setups and honestly, we probably should. So, let’s quickly modify the setup and see if we can break the upscaler.

This time, the solver runs at a voxel size of 0.05, using the 2× upscaler. The 3× model didn’t really add more detail, just extra waiting time. For a bit more fun, a Gas Wind with random direction and a collision shape were added. That collision shape, as it turns out, gives the upscaler a bit of trouble as seen below.

But when comparing the up-res result to a true high-res sim, it’s clear that the system is really good at preserving the base form. Doubling the voxel size in the high-res sim, on the other hand, changes the overall shape and eats up a ton of time but stays artifact-free. Or, if you really want perfection, you could just train a model specifically for this type of collision.

If you want to train your own model, this Equinox Hive talk walks you through every detail:

Zibra AI VDB compression

With this plugin you can save up to 99 percent of storage space when caching VDB simulations, which makes it perfectly suited for use in real-time engines such as Unreal Engine 5. The Zibra toolset, distributed via SideFX Labs, provides three dedicated nodes.

The first, zibravdb_compress, writes and exports .zibravdb files for use in Unreal and similar environments. The second, zibravdb_decompress, brings those files back into Houdini. And finally, zibravdb_filecache acts as a modified File Cache node that automatically handles compression, loading, and decompression for further use inside Houdini. Before diving in, you’ll need to download the model and obtain a license, potentially a free personal one if your revenue is below 100 K USD. The license management can be accessed directly from any of the three nodes.

For a quick benchmark, I used the Fireball Recipe and cached one regular VDB sequence alongside two Zibra versions with different quality settings. The original VDB sequence weighed 294 MB. The Zibra compression at a quality setting of 0.2 came in at only 5 MB, roughly 98 percent smaller. At a quality setting of 0.9, the result visually matched the original VDB almost perfectly while staying at just 36 MB, around 88 percent less.
That insane low file size at 0.2 naturally comes at the cost of lost detail, as visible in the comparison graph below. Still, the results are impressive and they open up the possibility for bringing volumetric simulations into real-time pipelines far more efficiently than before.

Pyro Shelve Tool Presets

Another way to get artists up to speed faster are production-ready presets, not just educational examples, but tools meant to be customized for your very real projects. Each of them comes with a ready-to-use Solaris network, fully set up for rendering straight out of the box. Even better, the Help section now includes a short guide and exploanation of important Nodes for every preset.

SideFX strikes a noticeably new tone here, aiming to flatten the learning curve rather than overwhelming newcomers with endless options (which, to be fair, they still do from time to time). These guides can be found under Documentation → What’s New → Pyro. In this section, we’ll take a closer look at three fundamentally different presets, each showcasing its own approach and creative use case.

Stylized Flame

With the refined Copernicus toolset, entirely new worlds open up: stylized fire based on a classic Pyro simulation, right inside Houdini. And if needed, even live-rendered in Solaris.

To put the claim of “easy adaptability” to the test, we took the Pyro Fireball preset and gave it a Toon-style makeover. Adding the VDB field “Flame” inside the solver’s output was all it took to make it work. The output from the Cop node, by the way, can be merged directly into the scene for further Houdini style editing.

Ground Explosion B

This shelf tool sets up a sparse pyro simulation featuring a large-scale explosion, smoke trails, and a shockwave. For more control and efficiency, it’s actually made up of two separate simulations, layered on top of each other and interacting through their velocity fields.

Candle Flame

A candle flame might not be the most exciting thing visually, but it’s one of those Pyro results you end up needing again and again. What makes this preset interesting, though, is the procedurally modeled candle that comes with it. Exploring that setup is almost more fun than the Pyro sim itself.

Thruster FX

In true H21 fashion and in the spirit of overall efficiency boosts, the new Thruster FX tool makes its debut: a setup designed to create engine and propulsion emissions with ease. It’s not just a new node, but rather a complete Recipe, a preconfigured network of nodes that some might, in hushed tones, simply call “presets.”

With a cheerful click on Thruster Exhaust in the Pyro Shelf Tools (or via Configure Thruster in the Tab menu), you’ll get a fully adaptable node tree, including a ready-to-render Solaris network. The effect itself isn’t a simulation but a cleverly layered, art-directable procedural system built around VOP Nodes. Multiple pyrothrusterexhaust nodes are stacked in layers, each responsible for different components like sparks, fire, and plasma. All working together to form a surprisingly easy to use thruster system.

So, what does it actually look like? And can it really be used straight out of the box, as promised? The short answer: pretty much, yes. The rendering comes surprisingly close to the viewport preview. To get it running, only a few connections inside the included Solaris network needed to be adjusted. For our small test scene, we did a bit of kitbashing inside Solaris, then added some glow and polish in Fusion.

Let’s take a closer look at the node, both from the outside and under the hood. The node expects a primitive as input, and a simple circle usually does the trick. It outputs both particles and a volume containing density and temperature fields. In the General tab, you can control speed, length, and the overall shape via a spline ramp. The Exhaust section handles the color ramp and lets you tweak the underlying noise pattern, which has a strong impact on the overall form. Under the hood, the node generates a VDB from Polygon, then modifies the result with a Volume VOP and a Volume Adjust Fog node.

As part of the ongoing effort to simplify things and lower the learning curve, SideFX has also released a good and detailed tutorial mini series: sidefx.com/tutorials/how-to-create-thruster-fx

Car Destruction FX

So that we can also crash the rigs built with the Car Rig SOP introduced in H20.5, Houdini 21 brings us the new Car Destruction Tools, led by the mighty RBD Car Fracture SOP, supported by the RBD Car Transform SOP. The first one takes care of fracturing and constraint creation, automatically handling the typical materials you’d expect in a vehicle: glass, metal, wood, and rubber. The RBD Car Transform SOP, similar to Transform Pieces, ensures that all pre-fractured parts are efficiently transformed based on the simulation points. You’re not limited to cars, by the way. Anything that follows the same basic logic can be blown apart. From motorcycles to helicopters, it all breaks just fine.

Destruction-hungry artists will find a detailed yet easy-to-follow example scene in the SideFX Content Library, the same visuals you might recognize from the keynote: sidefx.com/carbd-dual-car-collision/. A fitting go-through video can be found here:

Geometry, Viewport and other tasty QoL

Coming from its deep VFX roots, Houdini has taken quite a journey to establish its own distinct style of procedural modeling. With H21, that journey continues, extending existing nodes and adding a few genuinely useful new ones along the way. This time, even the viewport got some well-deserved love, now powered by Vulkan and capable of loading Gaussian Splats directly.

Sculpting in Time

The Sculpt SOP, introduced in H20.5 and (surprisingly) quite useful, now gets a genuinely groundbreaking new feature called Shot Sculpting allowing time-based, keyframe-free sculpting. Originally intended as a correction tool for character animation, the node turns out to be just as handy for VFX and motion design work.

Temporal control is handled through the Shot Sculpt panel, which at first glance looks a lot like an NLE timeline and, in principle, works much the same way. Sculpting can be organized into layers that can be offset in time, faded in and out (complete with easing), muted, or adjusted in opacity. Alternatively, you can use mask_track to paint time-based attributes, which can then be passed downstream and used in other nodes, for an obvious example, as masks.

Otherwise, the same rules apply as for the regular Sculpt SOP, whose updates we’ll take a look at next. In line with the new Shot Sculpting feature, the mask system has been reworked. Masks can still be painted manually, but can now also be loaded from an upstream float attribute, saved permanently, and blurred or sharpened as needed.

There are also new brushes. My personal highlight, the Elastic Grab brush:

Of course, the complexity and depth of ZBrush remain unmatched, but for many tasks, artists can now comfortably stay right inside Houdini.

Geometry Masks

There are also updates when it comes to masking. Several well-known nodes now include a Mask parameter, allowing the effect to be restricted to a painted or procedurally generated mask. Among them: Peak SOP, Soft Peak SOP, Inflate SOP, Flatten SOP, and Point Jitter SOP.

UV Flatten from Points

The latest addition to Houdini’s already powerful UV toolset could just as well be called “UV from Voronoi” since that’s exactly what it’s based on. The node distributes random or precisely placed points across the surface and uses them to calculate clean, non-overlapping UVs. It’s primarily designed for complex, high-resolution meshes, where traditional unwrapping tends to get messy fast.

Vulkan Viewport

Now enabled by default, the new Vulkan 3D viewport offers noticeably improved lighting, Ambient Occlusion, shading and ray tracing with built-in denoising, and a more accurate texture display though performance can take a hit if you push it too far. New worklights including a fully adjustable Dome Light, Physical Sky, and Three-Point Light setup now serve as the default viewport lighting.

Looking toward the future, the viewport can now display Gaussian Splats directly. Since splats are essentially just point clouds, and Houdini is fundamentally point-based, this opens up a rather promising combination. The .ply file can simply be loaded via a File SOP and passed into a Bake Splat SOP for further processing. From there, you can treat and manipulate the splats just like any other geometry using the usual SOP tools. More on rendering those Splats in the upcoming section on Solaris & Karma.

Curve Tools

The new Extract Contours SOP can generate object outlines from a camera’s perspective either directly as edges or as an edge group. Quite handy for toon-style effects.

The well-known Curve SOP now allows you to interactively split points into branches (with unique vertex numbers) or fuse them back together.

Unsubdivide

If things ever get a bit too much, this node can reconstruct a low-res input geometry based on Catmull-Clark.

Conclusion after some bottles of VFX

Even though the stated (and achieved) goal of H21 was mainly polishing existing systems and adding plenty of quality-of-life improvements, it still manages to sneak in a massive load of new features along the way. And we’ve only scratched the surface here. Deep dives on Copernicus, Solaris, Karma, Rigging, and Animation are already in the works.

What’s also refreshing is the ongoing effort to flatten the learning curve through better documentation, tons of in-house tutorials, and solid example files in the Content Library. Many things have become easier or let’s say, more accessible, without losing depth, at least for those who want to go there. As always, most nodes can still be cracked open and modified at their core. Nice one, SideFX.

The post Houdini 21: Like good wine (Part1, VFX & Geo) first appeared on DIGITAL PRODUCTION and was written by Manuel Kotulla.

If you’ve ever watched your pyro sim clip through a collider and thought, “Physics has left the chat,” this update is for you.

Headline Features

The big one is collisions: animated colliders and narrow geometry now hold up better, with smoke and fire retaining density and velocity instead of evaporating into numerical limbo. On top of that, the sourcing workflow has been redesigned, so setting up emitters feels less like solving a puzzle box and more like… well, just setting up emitters. The interface has also gone through a detox. Parameters are now sorted into sensible tabs, with advanced options politely tucked away, which means less scrolling and more simming. Performance has had a small but noticeable bump too, with simulations running between 5 and 15 percent faster depending on scene complexity. On the CPU side, fallback multithreading now relies on Intel TBB, giving more stability when GPU memory runs dry. And yes, it’s time to check your Houdini version: Axiom 4 supports Houdini 20.0, 20.5, and 21.0, with 19.x officially stamped “legacy,” which is dev-speak for “upgrade already.”

What It Means for Artists

The gist is simple: smoke looks better when it interacts with geometry, simulations tick along faster, and you’ll spend less time digging for hidden parameters. For artists cranking out pyro in production, Axiom 4 is less about flashy new features and more about shaving off headaches per day.

Pricing

Nothing has changed here. The commercial license stays at $199, the indie license at $99, and if you’re running Houdini Apprentice you can keep setting digital buildings on fire for free.

Outlook

Axiom 4 isn’t about reinventing the solver wheel but about refinement. With sturdier collisions, smoother sourcing, and faster turnaround, this release makes it easier to trust that your smoke won’t ghost through a wall. For production artists, that’s often the only feature that really matters.

Release Notes

The post Axiom 4 for Houdini: Faster GPU Pyro With Better Collisions first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Theory Accelerated has released a first look at Axiom 4.0, its GPU-accelerated sparse volumetric fluid solver for Houdini. The preview highlights more accurate collision handling, a rebuilt sourcing system, and 5–15% faster simulations.

Cleaner Collisions

Axiom 4.0 improves fluid–geometry interactions, particularly with animated colliders. Simulations show better volume retention and fewer artefacts in tight or complex spaces.

Sourcing Overhaul

The sourcing workflow has been restructured, paired with an updated Output tab for finer control. The new design aims to simplify parameter handling and make feedback loops clearer.

Performance Gains

On the performance side, Axiom 4.0 adopts Intel’s Threading Building Blocks for CPU multi-threading. This brings an overall 5–15% speed increase, especially when running outside GPU acceleration.

Release and Compatibility

Axiom 4.0 is in closed beta with no release date announced. It is previewed as compatible with “the latest Houdini builds” and the upcoming Houdini 21. The current stable release, Axiom 3.3, runs on Windows, Linux, and macOS. Pricing remains unchanged at $199 (commercial node-locked), $99 (Indie), and free for Apprentice users.

Industry Use

Axiom has been adopted as a faster alternative to Houdini’s native Sparse Pyro solver. It has already been used in production by Riot Games, Valve, and Muse VFX. The solver supports CUDA, OpenCL, and Metal, covering a wide range of GPU hardware.

The post Axiom 4.0 Sneak Peek for Houdini first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Freeing the VDB Pipes

Zibra AI has made ZibraVDB, its AI-powered volumetric compression tool for Houdini and Unreal Engine, available at no cost to indie artists and small studios earning or funded under $100,000 per year. This applies to both Houdini and UE5 editions, including for commercial use.

ZibraVDB compresses OpenVDB files, used for effects like smoke and fire, down to approximately 3 percent of their original size and claims to render them about twice as fast as Unreal Engine 5.3’s native Sparse Volume Texture (SVT) system.

What Changed—and What Remained

Until now, the free trial edition restricted users to compressing only five VDB sequences. With this update, the restriction is gone: indie users can compress an unlimited number of sequences and play them back in real time within Unreal Engine. Previously, individual subscriptions cost $10 per month or $150 per year. Those options remain for users outside the indie threshold, while studio-level subscription pricing is available on enquiry.

System Support and Availability

• Unreal Engine edition: Compatible with UE 5.3 or higher on Windows only. It’s distributed via Epic’s Fab online marketplace under a Standard license.
• Houdini edition: Compatible with Houdini 20.5.619 or newer, on Windows, Linux, and macOS. Available via SideFX Labs, an experimental plugin repository for Houdini users.

Installing either requires registering for a license key on Zibra AI’s website.

Final Note for Professionals

All claims of compression ratios and render-speed improvements are vendor-reported. Users should test ZibraVDB in their own environments before adopting it in production.

The post Zibra AI Frees ZibraVDB for Indie Artists (Briefly, Because Less Is More) first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

4Dviews has announced a major upgrade to its HOLOSYS+ volumetric capture system: native support for 4Dviews Gaussian Splatting as an export option alongside the traditional mesh‑and‑texture output. This marks the first time a volumetric capture system offers both formats natively, giving pipeline teams technical and creative flexibility without changing capture workflows. The company emphasizes that Gaussian Splatting is another tool to fuel narrative control—not constrain it. This approach underscores the modular and scalable fidelity design that underlies ongoing R&D at 4Dviews. 4Dviews will demonstrate Gaussian Splatting support at SIGGRAPH 2025 in Vancouver from August 10 to 14 at Booth 417.

4Dviews Gaussian: Splat or Mesh, You Decide

The new dual‑export pipeline enables creators to choose between standard mesh‑and‑texture assets or Gaussian Splatting output from HOLOSYS+ captures. Gaussian Splatting excels at rendering complex material characteristics, such as hair, fur, reflective or translucent surfaces, and fine props, while maintaining compatibility with existing HOLOSYS data pipelines.

4Dviews states that this integration is engineered for stability and visual fidelity under challenging capture conditions. The system supports dynamic performance capture suitable for low‑bandwidth streaming or high‑fidelity offline rendering while preserving backwards compatibility with all previously captured volumetric assets.

What It Means for Teams

Production teams now have access to two volumetric rendering paths: traditional mesh workflows for compatibility with existing VFX and editing pipelines, and splatting workflows for improved handling of materials and fine details. This dual choice may reduce compromises during capture and postproduction for assets with complex visual traits.

Notably, although Gaussian Splatting enables enhanced surface detail, each production should test the format choice under actual production conditions before integrating into deliverables.

The post Dual Export: 4Dviews Adds Gaussian Splatting to HOLOSYS+ first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Anyone working with Gaussian Splatting in Houdini can thank David Rhodes and Ruben Diaz for the kind of open-source toolkit that doesn’t just patch holes, but gives artists an entire toolbox. Now under the CG Nomads banner, GSOPs 2.6 lands as a free, AGPL‑licensed Houdini Digital Asset package—ready to import, edit, relight, mesh, animate, and export both 2D and 3D Gaussian Splats, all from inside Houdini 20.5.

Built for Houdini Artists, Not Marketers

Installation isn’t a mystery hunt: clone the develop branch, open the bundled installer HIP file, and (optionally) grab sample data with a checkbox. The full suite is compatible with Houdini 20.5 on Windows and macOS; Linux gets no official love, at least for now. Documentation and a detailed wiki are live on GitHub, and yes, it really is free—unless you want Early Access, which adds some exclusive toys for $10/month.

Not Just 3D—2D Splats Arrive, Too

While GSOPs has supported 3DGS (.3DGS) files for a while, v2.6 brings in support for 2DGS (.2DGS) files as well. Artists can load, render, and edit both 2D and 3D Gaussian Splat models right in Houdini’s viewport, with real-time GPU rendering and full attribute support. No more conversions or third-party hops just to view your splats.

Viewport Renderer and a Node Roster for Everything

The GSOPs SOP suite is far from a one-trick import node. Here’s what you actually get:

• Importers for .ply, .2DGS, .3DGS models, converting them to native Houdini point clouds, including spherical harmonics (SH) for view-dependent rendering.
• Viewport Source SOP: Real-time GPU-based splat rendering.
• Alignment and Transformation: Tools like gaussian_splats_align_by_points and gaussian_splats_transform allow full reposition, rotation, and per-point scale, with SH support baked in.
• Clean-Up Nodes: Use gaussian_splats_dbscan to remove noise or isolate regions with gaussian_splats_crop.
• Attribute & Color Control: Adjust SH coefficients, tweak attributes, or drop a Hald CLUT for color corrections.
• Deformation & Animation: gaussian_splats_deform enables mesh-driven deformation, and a set of “toys” includes advect, font, and jellify (Vellum soft-body splats).
• Mesh Generation: Convert splats to coarse meshes using nodes like vdb_from_gaussian_splats, or build sparse polygon graphs for further edits and downstream workflows.
• Synthetic Data Output: The gaussian_splats_generate_training_data SOP renders out training datasets (PNGs, COLMAP cameras) and is compatible with Karma and third-party renderers.
• Relighting and IBL: Relight splats with image-based lighting (gaussian_splats_relight_ibl), exploiting SH for dynamic effects.
• Exporters: Dump splatted models back to disk with full point and SH data for round-trip pipelines or external use.

Early Access: Karma & Solaris—Now with USD Integration

Those who support CG Nomads on Patreon get a little extra: USD integration and Solaris-native LOP nodes, including the “Gaussian Splats Import LOP.” This node injects splats into the Solaris USD pipeline, baking SH into Houdini’s v@Cd color attribute. Result? Real splat relighting, shadows, and reflections in the Karma renderer—and direct compatibility with USD-based lookdev and lighting workflows. Early Access also unlocks premium demo scenes.

Motion, Synthetic Data, and Feature Analysis

GSOPs isn’t just about static scans. It supports playback and editing of motion sequences—one splat file per frame—for workflows in Unity, Postshot, or SuperSplat. The toolkit also generates synthetic data for AI training or procedural content, and includes nodes for statistical analysis and data cleanup, giving artists deeper insight into their splat clouds.

Community, Support, and Licensing

GSOPs is AGPL-licensed—so it’s open for most studios and indie teams, with custom licensing for larger commercial studios if required. Community feedback and bug tracking are handled via GitHub, with further community showcases on LinkedIn and video reels linked in the repository. GSOPs recently placed third in the SideFX Houdini H20 Tech Art Challenge, earning a nod from the developer crowd.

What’s Missing? Official Linux Support and Caution

No official Linux support yet—Windows and macOS only. Documentation is extensive, but as with any new rendering pipeline, test every feature in your own environment before deploying in production. Real-time viewport speed depends on GPU horsepower and splat count; massive scenes may challenge Houdini’s interactive preview.

Closing Note for Cautious Professionals

GSOPs 2.6 is the most comprehensive Gaussian Splatting toolkit yet for Houdini, opening the full edit–relight–mesh pipeline for both static and animated point-based volumetric models. Karma and Solaris USD integration makes it genuinely production-minded, not just a tech demo. But, as always: test before you trust, especially if your deadline depends on it.

Cited Sources

// GSOPs official docs, feature list, node breakdown, licensing, installation // GSOPs – cgnomads/GSOPs GitHub
// GSOPs node documentation // GSOPs Wiki – github-wiki-see
// Karma/Solaris features, demo scenes // LinkedIn post by Ruben Diaz

The post GSOPs 2.6: The Swiss Army Knife for Gaussian Splatting in Houdini first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Toolbag 5.02 introduces an experimental Low-to-Low Baking mode, letting artists bake from one low-poly mesh to another using a dual-material setup. The new Bevel Shader supports hard-edged UVs, and baking previews can now be edited in the interactive mode. That’s good news for everyone who enjoys less guesswork and fewer bake group tantrums.

Decals, Tubes and Smudges

The new Decal Layer is almost finished, allowing drag-and-drop decal painting directly onto models. These decals are fully adjustable in size, projection, falloff, and rotation. Vector decal projection is also in beta – project curves as 2D vectors, combine them with booleans, snap them to grid, and yes, tubes and solids are supported, even if brush or symmetry settings aren’t yet.

Smudge Tool finally makes its debut, letting users smear paint layers across UV seams, geometry borders, and UDIMs. And Tile Strips can now be used to place tube textures as modular start/mid/end patterns, complete with tapering and tiling. For even more painterly control, a new Tube Mode for vector painting is included, letting you paint curves with warp, taper and brush profiles, and project Tile Strips directly.

For masking, you can now Sample Layers from paint or fill and convert them into reusable masks – non-destructively. Groups now support Sync Points, including adaptive anchors with isolation toggles.

The Fog Rolls In

In rendering, Toolbag 5.02 beta adds Ray-Traced Fog – still experimental, but already supporting multiple fog volumes, height-based falloff, and god rays. Raster rendering also supports fog, though it currently lacks falloff. Ray tracing also gets leaner on memory: Toolbag automatically switches between RTX and generic backends based on available VRAM, with a new GPU Auto mode in preferences that doesn’t require a restart.

If you’ve been longing for more control over your shortcuts, rejoice: the Hotkey Editor is finished. You can bind, reset, export/import and view all key assignments – including a conflict detection view that avoids shortcut chaos. The Scene Search bar is live, letting you filter your scene objects as you type. Multi-selecting scene items like meshes, lights and cameras is now supported for batch transforms. The new Render Window provides a dedicated space for render settings, separated from object properties. Finally, users can now add custom folders to their Asset Library, move/delete assets and folders freely, and even bulk import using “Apply to All” – though drag and drop from the OS still isn’t working.

Price and Availability

Toolbag 5.02 is currently available as a beta. Pricing details remain unchanged and can be found on the Marmoset Toolbag official site. As always with beta releases: stability is not guaranteed. Artists should evaluate these features in non-critical environments before integrating them into production pipelines.

Marmoset Toolbag 5.02 Beta

The post Baking, Decals, Fog and a Smudge of Beta in Marmoset Toolbag first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

VFX artist Thomas Marco has released a free stylised cloud shader for Blender, aimed squarely at artists working with procedural shading and volumetrics. The shader is 100% procedural and node-based, requiring no additional plugins or third-party libraries – just Blender and the will to render some puffy sky furniture.

https://twitter.com/thomas__marcos/status/1914291332324929951

Packaged in a downloadable .blend file, the shader includes a volumetric cloud setup with user-friendly control parameters. These custom properties are exposed in the Modifier tab, offering sliders for direct manipulation without diving into node spaghetti. Marco provides control over overall cloud shape, contrast, and edge softness – useful whether you’re shading a morning mist or sculpting a stylised thunderhead.

The shader is built for Cycles, Blender’s path-tracing renderer, and was created using Blender 3.6. While the file is compatible with newer versions, results may vary, as always. If things break, blame the Blender gods – or at least check if your version has changed shading behaviour.

Marco explicitly mentions the shader is made to be stylised, so while it leans into soft, painterly looks rather than physically accurate cumulonimbi, it’s perfectly suited for non-photoreal animation, game cutscenes, or surreal VFX inserts. It’s a procedural tool for aesthetic cloudscapes – not meteorology.

The shader is distributed under a Creative Commons Attribution license (CC-BY), meaning you can use it in both personal and commercial projects, with credit. He also includes a short demo animation and a preview render. The file is around 70MB, so no, it won’t choke your bandwidth.

As always: before integrating free tools into your production pipeline, test thoroughly. Especially when working with stylised procedural setups, version compatibility and render performance can vary. This shader is a strong candidate for lookdev and previz, but your render farm might have opinions.

---

Price
Free under CC-BY license. Download it from Thomas Marco’s Gumroad.

The post Free Blender Clouds Shader Floats into Your Scene first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Epic Games has unveiled Twinmotion 2025.1, a significant update that enhances real-time rendering capabilities for professionals across architecture, automotive, product design, and filmmaking. This release focuses on delivering advanced atmospheric effects, improved lighting tools, and refined rendering techniques to elevate the quality and realism of visualizations.

Advanced Atmospheric Effects

A standout feature in Twinmotion 2025.1 is the introduction of volumetric clouds. This system enables users to incorporate dynamic, voxel-based cloud formations that interact realistically with environmental lighting. Users can customize cloud properties such as altitude, coverage, density, color, and puffiness, allowing for precise control over the atmospheric conditions in their scenes. These clouds are responsive to wind dynamics and cast accurate shadows, enhancing the depth and realism of outdoor visualizations. Several presets are available to expedite the setup process, and users can save custom configurations for future projects.

In addition to volumetric clouds, the update offers enhanced control over the dynamic sky system. New parameters for turbidity and atmospheric density allow users to simulate various weather conditions and times of day with greater accuracy. The sun’s color and temperature are now adjustable, providing the ability to replicate different lighting scenarios, from the warm hues of sunrise to the cool tones of an overcast day. The exponential height fog feature has also been improved, introducing sliders for height and color adjustments, as well as a reworked density control. These enhancements enable the creation of atmospheric effects such as ground fog or mist, adding layers of realism to scenes.

Enhanced Lighting Tools

Twinmotion 2025.1 introduces Projector Lights, a versatile lighting tool that allows users to project textures, including images and videos, onto surfaces within their scenes. This feature is particularly useful for simulating effects like patterned lighting through windows, dynamic signage, or the interplay of light and shadow in complex environments. By projecting caustic patterns, users can mimic the dappled light effects seen on surfaces beneath water bodies or through translucent materials, adding a sophisticated touch to visualizations.

Another significant enhancement is the support for Virtual Shadow Maps (VSM) in real-time rendering modes. VSM technology offers more accurate and consistent shadow rendering compared to traditional methods, closely aligning real-time shadows with those produced by path tracing. This advancement ensures that shadows behave predictably across different lighting conditions, contributing to the overall realism of the scene. While VSM provides performance benefits in most scenarios, users should note that it may be slower when rendering scenes with precipitation effects. Currently, this feature is available exclusively on Windows platforms.

Refined Rendering Techniques

The update brings substantial improvements to the rendering of orthographic views in both Standard and Lumen lighting modes. Previously, orthographic views lacked shadow support and included black outlines around objects, which could detract from the visual quality of technical illustrations. With Twinmotion 2025.1, orthographic views now support real-time shadows, and the undesired outlines have been removed. This enhancement enables professionals to produce high-quality plan and elevation views directly within the real-time engine, streamlining workflows and ensuring visual consistency across different representation modes.

Interactive Configurations

Addressing the need for dynamic presentations, Twinmotion 2025.1 introduces a Configurations toolset. This feature allows users to create interactive 3D presentations that showcase various design alternatives or product variations. By setting up trigger points within the scene, stakeholders can seamlessly switch between different configurations in Fullscreen mode or during local presentations of images, panoramas, videos, or sequences. This interactivity is invaluable for design reviews, client presentations, and real-time decision-making processes, offering a more engaging and informative experience.

https://cdn2.unrealengine.com/new-trees-in-twinmotion-2024-1-1-1920×1080-6ca8b55bac65.jpg

Conclusion

Twinmotion 2025.1 represents a significant leap forward in real-time rendering technology, providing professionals with advanced tools to create highly realistic and interactive visualizations. The integration of volumetric clouds, projector lights, virtual shadow maps, and enhanced orthographic rendering empowers users to achieve greater creative control and efficiency in their projects.

Note: Before integrating any new software into your workflow, it’s essential to assess its performance and compatibility with your existing systems.

The post Twinmotion 2025.1: Real-Time Rendering with Advanced Atmospheric and Lighting Features first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

ZibraVDB, a volumetric simulation plugin, is now available in a free version for Unreal Engine 5.3 users. Designed to generate smoke, fire, and other volumetric effects in real-time, ZibraVDB aims to make high-quality simulations accessible for artists working on tight budgets—or with even tighter deadlines.

The plugin processes VDB (volumetric data) files and visualizes them directly in Unreal Engine. This feature enables creators to work with effects like smoke or fire without requiring pre-rendering, making it particularly useful for game development and interactive simulations. Whether it’s a raging fire in a game or a smoky explosion in a cinematic, ZibraVDB ensures the effect looks sharp without disrupting your workflow.

The new free version is a slightly pared-down version of the paid edition. Users can process VDB files up to 256³ voxels, making it a good fit for smaller-scale simulations. While this may not replace high-end tools in production pipelines, it offers an excellent entry point for artists looking to test volumetric effects in real-time. For larger or more complex simulations, the paid version supports resolutions beyond 256³.

ZibraVDB is compatible with Unreal Engine 5.3, though no word yet on support for future versions. Artists interested in integrating the tool into their production pipeline should check for compatibility and stability before committing to a project. As always, bleeding-edge tools like this should be tested thoroughly before being unleashed on client work.

Pricing? The free version costs exactly what it promises—nothing. For more advanced features, you’ll need to fork out for the full edition. Pricing details for the full version aren’t mentioned in the source, but you can find more information on the official ZibraVDB website.

ZibraVDB continues the trend of making high-end tools more accessible to indie developers and small studios. While its free version is unlikely to dethrone heavyweight simulation software, its real-time functionality and ease of use make it an appealing option for Unreal Engine users. Plus, who doesn’t like free smoke and fire?

For more details and to download the free version, visit ZIbraVDB on Fab.com.

The post Free ZibraVDB for Unreal: Smoke, Fire, and Simulated Chaos first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Pilgway has released 3DCoat 2024.30, bringing a suite of new features and improvements tailored for digital artists in VFX, game development, and CGI. This update focuses on enhancing workflow efficiency and expanding creative possibilities, all while keeping the user experience as smooth as a well-polished mesh.

Photogrammetry Integration with RealityCapture

A standout addition is the integration with RealityCapture, Epic Games’ photogrammetry software. Users can now generate 3D models from photographs or videos directly within 3DCoat, streamlining the creation of digital assets from real-world references. This feature is particularly beneficial for artists seeking to incorporate realistic textures and forms into their projects without the need for external applications.

Enhanced Volumetric Boolean Operations for 3D Printing

For those venturing into 3D printing, 3DCoat 2024.30 introduces the ability to perform volumetric boolean operations with an additional shell. This function is crucial for creating matching parts in 3D models, ensuring that components fit together seamlessly. By accessing the “Remove intersection with…” option in the SculptTree’s right-click menu, users can set up subtractions with an additional shell, facilitating the production of prototypes and complex assemblies.

New Array Tools in the Sculpt Room

The Sculpt room sees the introduction of two new tools designed to enhance modeling capabilities:

• Array Tool: Allows the creation of various arrays of volume objects along curves, enabling the efficient duplication of elements in a controlled manner. This is particularly useful for generating repetitive structures such as chains, fences, or architectural details.
• Surface Array Tool: Enables the distribution of objects across a created surface or selected faces of a low-poly mesh, providing flexibility in populating surfaces with multiple instances of an object, which can be invaluable in creating complex surface details or patterns.

Map to Mesh Conversion

In the Painting room, a new feature allows the conversion of normal maps to actual geometry. This reverse workflow enables artists to reconstruct high-poly source models from low-poly meshes adorned with normal maps. It’s particularly advantageous for refining AI-generated prototypes or enhancing existing models by adding intricate details that were initially represented only in normal maps.

Additional Enhancements

• Blender 4.2 Applink Support: The update includes support for Blender 4.2 Applink, facilitating smoother interoperability between 3DCoat and Blender, which is a boon for artists utilizing both platforms in their workflows.
• Real-Time Non-Modal Search/Filter: A new real-time search and filter function has been implemented for all item containers, including alphas, materials, objects, layers, and presets. This enhancement allows for quicker access to assets and tools, reducing downtime during the creative process.
• Improved RAW Voxel Export/Import: The RAW voxel export/import functionality has been improved to support PBR (Physically Based Rendering) data, including color, gloss, and metalness. This improvement is particularly useful for developers looking to integrate voxel data into proprietary engines while maintaining material properties.

Pricing and Availability

3DCoat 2024.30 is available for Windows, macOS, and Linux platforms. For individuals, perpetual node-locked licenses are priced at €379, with subscription options starting at €20.80 per month or €169.85 per year. Studio licenses and additional pricing details can be found on Pilgway’s official website.

Fact Check Note: While these new features enhance 3DCoat’s capabilities, it’s advisable to thoroughly test them within your specific production environment to ensure compatibility and stability before integrating them into critical workflows.

---

The post 3DCoat 2024.30: New Year, New Tools for Your 3D Arsenal first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

With the new version 4.3 of the Godot Engine, the developers have integrated numerous improvements and new functions that are specifically tailored to the needs of CG artists. The focus is on optimising and expanding existing tools to make complex digital projects more efficient and flexible.

Volumetric fog: more realism in the visualisation

The introduction of “Volumetric Fog” in Godot 4.3 offers you an improved representation of fog and smoke in real time. The engine now supports the simulation of light scattering within fog volumes, which makes for more realistic and atmospheric environments. Especially for scenes that require a dynamic atmosphere, such as in film production or real-time visualisations, this is a welcome enhancement.

The new fog function is fully integrated into the pipeline and works efficiently with the existing lighting and shading engine. However, the complex calculation of the light interactions within the fog can require high computing power, depending on the scene and project. Users should therefore test the new functions thoroughly before integrating them into production projects.

Meshlet rendering: Efficient rendering of complex geometries

Meshlet rendering is another important new feature in Godot 4.3. This technology makes it possible to divide large and complex models into smaller parts, so-called meshlets. This leads to more efficient processing and visualisation of geometries, as only the visible parts of the model need to be rendered. For VFX artists working with highly detailed scenes, this is a significant relief as it can considerably reduce render times. Especially in real-time applications, such as games or interactive visualisations, meshlet rendering can help to optimise performance on different hardware configurations. Here too, however, it is advisable to evaluate the technology in detail before using it in production.

Improved animation tools: Precision and flexibility

The animation toolset has also been revised with Godot 4.3. The new functions offer you as a user more precision when creating and customising animations. The “Animation Retargeting” feature allows you to easily transfer animations to different characters, which greatly simplifies the workflow for projects with multiple characters.

The integration of Animation Trees has also been improved, allowing you to manage and customise complex animations more efficiently. These new features are particularly useful for artists working on projects with many animated characters or objects. Improved control over timing and transitions allows for more realistic motion sequences, which is important in VFX and game production.

Extended file format support: More flexibility at work

Godot 4.3 extends support for different file formats, giving you greater flexibility when importing and exporting your projects. The engine now supports a wider range of 3D file formats, including FBX and OBJ, and improves integration with external tools such as Blender. This expanded format support facilitates the exchange of assets between different software solutions and enables smoother collaboration in mixed production environments. Although the new formats have been extensively tested, artists should ensure that all imports are correct and lossless before using them in current projects.

Further optimisations: Improved performance and stability

In addition to the major features, Godot 4.3 offers a number of smaller optimisations that have a positive effect on the general performance and stability of the engine. These include improvements to the rendering backend, which increase the general frame rate and responsiveness of the engine.

The developers have also worked on the user interface to further improve the workflow. This particularly affects the scripting and debugging areas, where new tools and options have been added. These changes are aimed at providing you as a user with an even more pleasant and productive working environment.

Licence model and availability

Godot 4.3, like the previous versions, remains available under the MIT licence, which means that the engine can be used free of charge. This openness makes Godot particularly attractive for indie developers and small studios who want to benefit from the professional features without having to pay high licence costs.

For more information and detailed instructions on how to use the new features, you can consult the official documentation. Information on downloading and installing the latest version can be found directly on the manufacturer’s website.

The post New functions in Godot 4.3 for CG Artists first appeared on DIGITAL PRODUCTION and was written by Jürgen Firsching.

Six of us started our studies with Professor Michael Coldewey in the 2020 winter semester. Thanks to his extraordinary commitment, we were the first VFX class at HFF to start giving free rein to our ideas early on. When Professor Jürgen Schopper took over as head of the specialisation in spring 2021, we were confronted with realistic project planning, which meant that the projects could be completed in July 2021. For the most part, we succeeded and it was an extremely important experience for us.

by Chris Kühn, Nicolas Schwarz and Christian Geßner

Jonas Kluger, Pipeline TD at HFF Munich, set up the Shotgrid software for us to manage the projects. With regard to time tracking, which is common in the industry, we quickly realised how much time is actually needed for some “small” changes. We received cinematographic input from Rodolfo Anes Silveira, who also supported us in all audiovisual matters.

The two films 01 of the new VFX class at the HFF Munich 

Jürgen Schopper took over the professorship of the VFX specialisation in April 2021. The first students have now completed their film 01. The result is the animated short film "Sleep Tight" and the fully animated fictional teaser "17 Souls". 

Jürgen Schopper started as head professor of the VFX specialisation at the Munich University of Television and Film (HFF) at the beginning of April. The specialisation is anchored in the HFF Department of Visual Design (headed by Prof. Tom Fährmann). The first VFX students started there in the winter semester 20/21. 

Prof. Jürgen Schopper: "I really enjoyed planning the VFX specialisation and supervising the very first two films in this new degree programme. I would like to thank our President Prof Bettina Reitz, without whose support this new direction at HFF Munich would not exist, Prof Tom Fährmann, who has always supported me in the planning, and above all Prof Michael Coldewey, who was such a great mentor during the first semester before I was appointed to HFF Munich. I would also like to thank Prof Dr Peter C. Slansky, who was a great help with all the technical aspects. With Petra Hereth (Team Assistant), Rodolfo Silveira (Artistic Associate) and Jonas Kluger (Pipeline TD), we have now set up a great VFX team in our department, which is supplemented by external lecturers. This ensures the most up-to-date references in the curriculum and the exchange of students with the VFX industry from the very first day of study. We have opted for an end-to-end VFX workflow - from brainstorming to the finished film - which is also state of the art in the industry. But it's best to let the students themselves have their say and describe their impressions and experiences in the process of creating their first two films."

The first film and an immediate crash

What do “Der Schimmelreiter” by Theodor Storm and a missing passenger plane from the 1940s have in common? The teaser “17 Souls” tells the beginnings of a mystery story about a ghost ship based on true events.

At the end of the 1940s, several “Avro Tudor” aeroplanes disappeared over the Atlantic Ocean in the infamous Bermuda Triangle. To this day, it is still not clear how these crashes could have happened despite the best weather conditions. Based on these events, the 3D animated teaser “17 Souls” was created at the HFF Munich, supervised by professors Jürgen Schopper and Michael Coldewey. We were very fortunate to be supported by people with industry experience from the VFX and animation film industry departments.

Brainstorming and conception – the visual claim

The long-standing tradition of the HFF Munich actually stipulates that the students’ first film must be shot in black and white. The various areas of VFX bring with them many innovations, which means that HFF Munich has finally created a link between analogue and digital. As a result, we were lucky enough to introduce a bit of colour into our film.

We initially pursued a visual ambition rather than a profound narrative. As pioneers of the new VFX programme, we knew at the beginning of the semester that we wanted to create images that would impress our viewers. We already had enough material for initial concepts from our research. With the first storyboard, we were able to cut together a pre-visualised film and use an initial sound design layout to better capture the mood and direction we wanted to take. We used the weekly meetings with Prof Michael Coldewey, Prof Jürgen Schopper and Rodolfo Anes Silveira to get suggestions and feedback. From this point on, we moved up a dimension from the flat 2D drawings to the 3D software.

Modelling – design first, history second

Due to the coronavirus pandemic, we were unfortunately unable to visit the nearby aircraft museum in Schleißheim for research. Nevertheless, we stuck almost exactly to the original model of the “Avro Tudor IV” for the external shape. Thanks to blueprints and discussions in aircraft forums about the Avro Tudor series, we were able to get a good idea of the aircraft and block out the first settings with a rough model.

As the pre-visualisation gave us an accurate picture of the perspectives that would be seen of the aircraft, the focus of the model was placed more on the front and side views, which allowed us to save unnecessary work on details that were not visible.

For close-ups of the engines, the outer turbines were moved a little further towards the bow so that they are easily recognisable in the blur. The interior of the aircraft is very different from the original and is largely based on our own design, as the original aircraft interior nowadays is more like that of a train compartment. Nevertheless, we have always orientated ourselves on the designs of the time. The cockpit is a combination of modern spaceship seats, control elements from various aeroplanes and several duplicated elements.

Texturing – You snooze, you lose!

The assets were then all given a used look through texturing. It was important to create a dilapidated surface without telling the story of a completely destroyed aircraft. Different camera angles meant that different levels of detail were required on the aircraft. For example, a single wing and the foremost metre of the aircraft nose each have their own 8K texture for base colour, bump, metallic and roughness.

Rigging & animation – a turbulent affair

Due to the stormy environment in which the aircraft is located, we were aware that it had to be shaken up properly. This meant that the aircraft rig had to have several controllers in order to be able to control the shaking independently of the aircraft’s direction of movement. We then implemented the interior in a similar way. Assets such as the seats in the cockpit and passenger area were given their own controller for each seat, which could be animated in the classic way or procedurally.

Problems only arose when changes were made to the geometry of the aircraft, which usually led to less than pleasant surprises in the rig. We were very lucky to work with Prof Melanie Beisswenger from the Ostfalia University of Applied Sciences via Zoom on specific problems in the animation.

Light(n)ing – Let there be light!

Most of the film takes place in a wild thunderstorm. For planning purposes, we created a light sheet under the guidance of creative director & CGI artist Kathrin Hawelka in order to pre-define the right lighting mood. The indirect lighting of the lightning between the different layers of clouds created a special atmosphere. As most of the clouds were actual volumetrics, we were also able to place the lightning, which was generated in Houdini using L-systems, freely in the 3D scene.

In addition, a very transparent volume over the whole scene created an impressive weather glow when lightning struck. To create a gloomy mood, the entire film is lit low-key and is often limited to a single edge lighting. Inside the aisle of the aeroplane, we used flickering neon lights and occasional bright flashes to maintain the basic nervousness.

FX – Smoking heads and burning engines

To keep our finger on the pulse, Houdini was our first choice for all simulations. The industry standard software demanded a lot from us and has become a real asset, especially with the help of our lecturer Felix Hörlein.

The animations of all shots were exported as Alembic from Maya. To keep the simulations as stable as possible, the aircraft was animated at the origin of the coordinate system and not moved forwards at cruising speed.

The climax of the tension in the film is the burning engine. Fire and smoke were created using the sparse solver “Axiom” and controlled with a particle simulation. The time advantage provided by the GPU acceleration of the plug-in was the decisive factor in our decision.

The rain that hits the windscreen consists of particles that are measured to form a water surface. To do this, we created clusters that generate several particles simultaneously and shoot them at the cockpit’s collider geometry. The windscreen wipers do not interact directly with the individual particles, but generate a force field that is responsible for the streak-like distribution of the droplets.

We have created proxy geometries with a significantly reduced number of polygons for all rigid body objects. The collider geometries also only consist of rudimentary geometry such as cuboids. We used Vellum for all pockets in the interior and soft bodies. As it was not possible at the time of production to have Vellum objects and RBD objects collide with each other, we also opted for Vellum for the suitcases in the luggage rack net.

Rendering – If you don’t render, you freeze!

The rendering was carried out using the in-house render farm – a network of 7 workstations. For reasons of time and cost, a CPU render with Arnold or Mantra was out of the question. The original plan was to render in Maya with Redshift. In the end, however, Houdini (also with Redshift) became our lighting and rendering software.
In addition to the classic back-to-beauty layers, we also rendered a depth channel and the cryptomat for all shots for compositing. The distribution of the individual render jobs was monitored with the Deadline Monitor software, which woke us up a few times during the night if a rendering was faulty. The result was wonderful 32-bit multilayer EXR files.

Compositing – Cloudy with a view of rain

For the compositing we were able to use additional layers of rain as well as self-created matte paintings to give our images more depth and realism. For the clouds in the storm, we opted for a mixture of rendered volumes interacting with the aircraft and 2D plates of procedurally generated noise. Compositing artist Heike Kluger showed us the endless possibilities of noise algorithms, which we used for rain, haze and clouds, among other things.

Colour grading – showing your colours

We also noticed the freshness of the course in colour grading, when the in-house colourist, Claudia Fuchs, was very pleased with images with a colour depth of 32 bits. You don’t even get that with the raw codec from RED. Together with the colourist, we created an aesthetic black and white look with a few colour accents.

Sound design – boom, crack, hiss

When we marched into the HFF sound studio with the finished film, we didn’t realise how important the sound design would be for our film. Together with sound designers Gerhard Auer and Rodolfo Anes Silveira, we filled the images with sound. When the first thunderclap was set, a broad grin spread and suddenly the film felt like great cinema. Pattering rain, a burning engine and the distant rumble of the storm resounded through the cinema. The trembling of the low tones and clinking of the flying glass provided the final immersion of the teaser.

Happy accidents & virtual meetings

Virtual feedback loops, digital beer drinking and lectures in all kinds of transport: This is what life was like during the project. Review rounds initially took place exclusively online. We were all the more surprised when we got to see an interim result on the HFF cinema screen for the first time. The initial anticipation quickly evaporated in view of the amount of work that still needed to be done. That evening we also realised that the films were designed for the cinema and not for the monitors we were working on. The joy was all the greater a few weeks later when – back on the screen – we realised what had happened in the final stages. The biggest hurdles had now been overcome.

One example of such a hurdle was moving the 3D models from Blender to Maya. This tended to work smoothly via an FBX export. Only the naming made the Maya file almost unusable. Dots in object names were replaced by a long string after the import and all constraints were included in the object name. The solution to this was a self-programmed Blender add-on that replaced dots with underscores and a checkbox in Maya to hide the name spaces.

Outlook

The first film of our studies is finished. But what are we going to do with it? The teaser and the collected material are perfect for a pitch-vis to push the development of the feature film, which shows the whole story around the mysterious disappearance of the plane. A series of festival submissions is also planned to network even more closely with other filmmakers and gain new experiences. And if you want to see it all in motion, you can find the making-of at is.gd/hff_17souls.

The team 
Cast: Maximilian Klampfl, pilot voice 

Crew:
Producer: Michaela Mederer 
Director / Script / Modelling / Texturing / Rigging / Animation / Compositing: Chris Kühn 
Director / Concept / Matte Painting / FX: Nico Schwarz 
Director / Concept / Modelling / Texturing / Lighting: Christian Geßner
Project Supervision: Prof. Michael Coldewey & Prof. Jürgen Schopper
 
Project Consultant: Rodolfo Anes Silveira 
VFX Pipeline TD: Jonas Kluger 
Line Producer: Ina Mikkat 
Team Assistant to Line Producer: Jenny Freyburger 
Team Assistant: Petra Hereth 
Colour Grading: Claudia Fuchs 
Sound Design: Gerhard Auer & Rodolfo Anes Silveira 
Postproduction Supervisor: Christoffer Kempel 
Technical Support: Benedikt Geß & Florian Schneeweiß 
Conforming: Martin Foerster 

Department Mentors: 
Melanie Beisswenger (Animation)
Kathrin Hawelka (Lighting & Shading)
Felix Hörlein (FX)
Heike Kluger (Compositing)
"Super" Dirk Mauche (Modelling & Texturing)
Moritz Rautenberg (Camera)

The post 17 Souls first appeared on DIGITAL PRODUCTION and was written by HFF Hochschule für Fernsehen und Film München.

And who would have thought we would get the chance to talk to Kevin Meek, lead environment artist for Anthem, who was involved as the Character and Environment Director in the legendary edition. He is an alumnus if such varied title as “Mechwarrior Online”, “Transverse”, “Duke Nukem Forever” and now the “Mass Effect” Universe.

DP: To get a rough idea of the project: How many people were involved?
Kevin Meek: The “Mass Effect Legendary Edition” (MELE) was largely driven by BioWare Edmonton itself and here we have a fairly small, but quite senior group of people. Around a dozen developers, where everyone has at least 10 years experience. And the vast majority has already worked on the original trilogy. Then there was a handful of people like myself who came at it as fans and did not work on the original trilogy, but almost everyone has probably 20 years of experience working in games.

With a smaller size team, it almost feels like an indie team – just a whole bunch of people wearing a bunch of different hats. They’ve all been through the process before, so they know what they’re doing and just did get down to business really fast.

That being said, we also had a lot of external help – we were able to push some of the work to outsource studios and just find specific experts in certain fields. For example, Blind Squirrel (blindsquirrelentertainment.com) was a programming partner for us, because they have lots of experience with porting from other remasters and remakes – specifically with Unreal Engine 3, which we are using. They are very involved in the whole intricacies of taking something up onto DirectX 11 and getting it onto the next generation of consoles.

That’s a big amount of work for us regular developers of BioWare. We would be able to get our way through, but if you can find people who are experts in that field, we can bring them in and partner with them. Also, there’s a handful of experts in Unreal 3 from Europe called Abstraction (www.abstraction.games). They came onto the project for a couple of months and really added a lot. But everything went through the Edmonton Studio.

DP: With the “Mass Effect” trilogy being made in Unreal 3, did you have newer technologies from Anthem, for example, to add?
Kevin Meek: The last time we, as a company, used Unreal 3 – or Unreal at all – was with “Mass Effect 3”. At that point, “Dragon Age Inquisition” and then “Andromeda” and “Anthem” switched to Frostbyte. It’s almost ten years since any of us have touched Unreal … except for private projects.

DP: With 10 years since the assets have been active, did you switch to newer versions of your toolset, or did you use legacy versions on newer hardware?
Kevin Meek: Well, it’s a decade long trilogy, so the tools in ME1 weren’t even the same as in ME2 and ME3. Sometimes, in order to get a file to open, so we could export it into something current – for example a very specific version of ZBrush.

But we also didn’t want to dust off and maintain three different sets of tools with their respective underlying infrastructure and engine code, so one of the first things we did is unifying that. Generally speaking, that meant going up to the most recent version, so we went up to a more recent version of Unreal 3 – more recent than “Mass Effect 3”, actually. For ME1, that was a pretty substantial upgrade, for ME3 it’s a handful of newer tools and a few iterations.

For our underlying tools – like mesh exporters and so on – the latest version in which everything was working is 3ds Max 2018, so we just unified everything to that. There were even a handful of tools that required Max 2018, because we couldn’t get the old ones compiling.

For the rest of the pipeline, we used whatever the original developers used. We opened up the assets, and then there were mesh files, and ZBrush files, and Mudbox files and Photoshop files … the development ran from 2006-ish through to 2015. That’s quite a lot of time in the games industry for a lot of tools and different pipelines. And on top of that, people were still figuring out how to use certain technologies – how to make and incorporate normal maps and high-poly /low-poly baking, for example.

DP: Do you have any tips for getting older stuff to work again?
Kevin Meek: Yes, anytime anything was documented at all was such a lifesaver – if you ever work on something that has even the slightest chance of being remade, save copies of the installation files for the programs you use. Especially near the end of a project, get everyone to work clean in the organisation of assets. It is sadly quite common to modify the texture directly, and not go back into the Photoshop file. This might get the game done, but it makes the work for the remaster or remake a LOT harder, when you have to become a archaeologist, and scroll through final_2_2.xyz.

DP: And how about technologies that weren’t possible when the games came out?
Kevin Meek: There are definitely effects, that you expect from the current generation of games. You expect some ambient occlusion, some sort of (at least faked) subsurface scattering, volumetrics …
Especially volumetrics, which came in the latest version of Unreal 3. It adds so much life and depth to a scene. We found that in ME1 and even in ME2, there was not a lot of movement and dynamic attributes to the levels. And that was largely technical constraints. Either the stuff hadn’t been invented yet, or the things were very expensive in terms of performance. Translucency and sorting and having half your screen filled up with transparent pixels. That’s still expensive, mind you – you can really catch yourself out with particle effects creating overdraw issues.

In MELE, we couldn’t go crazy, but consoles are ten times more powerful, and we have all this understanding what we want games to look like. And we could add that sense of life and dynamic. And since we brought all three parts onto one level, we could add certain types of tech into ME1 and 2.

There are other tools we had to write by hand – like our version of the ambient is custom. And the wrap lighting or the custom depth of filed is either custom, or ported back by hand from how you do it in modern day. Thankfully, with Unreal 3, there is troves of knowledge online on how to fake things like subsurface scattering these days – we took from well documented graphics bibles and user cases and tutorials. That’s one of the really big perks of working in Unreal – you just have to google it, and there’s the answer, sometimes in 10 different ways.

DP: When we look at the textures: How did you upscale all of those, and what tools did you use?
Kevin Meek: We used a number of things – we knew going in, that current AI-tools would be only level 1 for us. So, we did that as the first step – before anyone touched anything, we got that done. Myself and one programmer analysed a bunch of AI upscaling methods (Upres), and I was a bit of a sceptic before those tests. It’s like that meme “Zoom and Enhance”.

We did a lot of tests with textures, UI and FX, all the way to environment and character art. We had internal tools, and we had some out-of-the-box solutions. I was impressed with the results, but you have to test a lot and pick and choose, specifically for games.

We exported (and reimported) large batches of Targa files straight from the game files, so any last-minute changes were available – like I said, when you are close to finish, artists don’t always use the source-PSD-files, but work in engine.

Basically, we got everything from the game, and on that we ran the AI upres. At this point we had to pay close attention to the file-types, like normal maps and stacked textures. Every texture is a red-green-blue and sometimes an alpha channel. They usually don’t know about each other. So, if you upres, you suddenly get a lot of bleeding – because in the resolution change, they are not ignorant of each other, and they are suddenly mathematically incorrect.

Same thing with the stacked textures – basically a bunch of masks, for a character’s armour for example, where the different versions are just in some free channel in the texture. We had information about how shiny the armour is in the red channel and in the green channel you have the information which colours can go were. Or vice versa.

And if you process that, you get a lot of garbage – so we had to split those out into four different textures. Now we have four PNGs and then we upres those, and recombine them into a colour map and convert it back to Targa. There’s a little bit of a stepping processes.

With that approach, we ended up well north of 30,000 textures for the characters alone. But that worked really well, and bumped up the picture quality of the game. And we only upscaled one step in the source art – so from a 128-texture up to a 256-texture. Or a 1,024 to a 2,048.

DP: What was your pipeline for that heap of assets?
Kevin Meek: We had a really good tools programmer – and we tracked everything. The batch tool put the texture somewhere, split it apart, and create an Excel sheet of tens of thousands of lines, with “here’s the texture name, here is its new name (times four), here is what type of texture it used to be, and where does it go now”. And as long as you keep that Excel sheet saved, then all the tools can reference from that.

And we’d update the tools as we find things going wrong, and then you’d end up having to run the whole process again. A number of times we just reverted everything back to that “Safe Revision 01”. We babysat the AI upres and we only ran a few thousand threw it at once, just in case it crashed or anything went wrong. Largely it was just like a bank of computers working on that, as we slept or went home for the weekend.

DP: And, on the creative side, where is the tipping point where you need an artist?
Kevin Meek: Well, coming from the AI upres, we basically had the game up and running, and then the artists started coming in – and they used their trained eyes. Let’s take for example environment art: I would assign an artist to a level and they would own that level, play through it a number of times and create a list of assets they critiqued as not good enough. Those assets got ranked by priority, based on how bad it was versus how often is it used, or if it is a hero-piece, and then you just hit through your list of ugliest assets. When you play through the level again, the standard is raised – and you walk through that cycle a couple of times, and it is getting good.

But with iteratively getting the things better until the point where nothing catches your eye as bad, you still have to remember: A remaster is very art-focussed, but at the end of the day, “Mass Effect” is a story-driven game, with the characters and their interactions in the foreground – and therefore, our job as artists was to make sure that you are never distracted by the art in a negative way.

The AI upres gives us a great base to work off of, but it doesn’t make bad art good. If something is noisy or boring or shifted, you just have to recreate that texture. And then there is everything else we layered on top. AI upres is fine, but it isn’t doing anything to the meshes or the shaders or to the lighting. All of this stuff, the big-brush coating of the levels, which makes it feel more like a current generation game, has to be done by hand. There is no AI solution for relighting the level. Maybe one day there will be …

DP: Aside from the textures, did you re-do the riggs or the animations for finer details?
Kevin Meek: (laughs) Our animation pipeline did not do well after 15 years. Often it was just Perforce sitting there in the server, getting server dust on it. So, we found that often, if we would redo an animation and reimport it into the game, that took a long time just to get going in the first place. And then secondly, there were a lot of ripple effects of bugs that came from basically touching the system at all. That could be anything from underlying Unreal issues, where we’ve upgraded the version from whatever version it shipped on to the current version. Also, there were some mathematical changes, which happened a lot with lighting. Some piece of averaging, how light affects a character, changed, and now the system reacts differently. These might be little things that you don’t even pick up until you worked some time with it.

With the animation, we couldn’t really do anything about that, without devoting a huge amount of time into it and setting up the system again. What we ended up doing was change how the underlying system works with the animation – like animation trees. In a video game, you don’t animate every single thing the character could possibly do – you animate independently and blend the actions together through an animation tree – turn left, look up, aim at, these are animations that are blended, and there were a lot of issues in the tree for how things can blend together. That ended with a lot of cross-eyed moments – which was almost funny – especially when Shepard and the team go to cover, and you see their faces, and they would pull a gun and their eyes would roll up in their head. That kind of stuff, we were able to change and clean up.

The riggs stayed the same, but we had to reskin every single armour and piece of clothing we touched, because we upressed the meshes themselves. There are more poly­gons for smother shoulders and the details, that might just have been texture before, are now polygons and cut-outs and extrusions which catch the light. So, our tech-department reskinned the verts to the skeleton. These new polygons need to be connected to the bones to move with them.

DP: With your background in environment art: How did you treat the planets, some of whom were quite barren in ME1?
Kevin Meek: For the uncharted worlds, they were the most barren. They are all Unreal-terrain-based and not a static mesh. That gives you a few semi-procedural options, but still works well within the tools that existed in Unreal 3.

What we would do is like a scatter mesh system, instead of just green texture on the ground. Now we have green texture on the ground, which is upressed and looks better and has a better material to it. And finally, it is actually projected on the ground instead of UV stretched everywhere. But also, on top of that, there is an actual mesh on top, like of blades of grass or rocks.

That’s basically a system you tell “on this type of texture, given this angle allowance, how dense do you want these rocks to be”. Every time you load the level, it is different. But nothing so large it needs collision, so trees we would stay away from. That would have created a whole swarm of ripple effects, because you would be stuck on the tree, but it is not always there, because it is generated. So, we kept everything level enough that you can walk around without collision.

The mesh of the terrain we upressed, and the materials we used are now triplanar shaders on the terrain. In the original, it was just top-down-projection. A polygon on a cliff would have the UV stretched all the way down the cliff, because it doesn’t know about angles. But with a triplanar projection shader, it actually shoots the texture from X, Y and Z and then it blends those intersection points. So now your cliff actually looks like a cliff instead of melting rock. That’s not new tech, but it is much more expensive, and they obviously couldn’t have afforded that back in the day. But it makes a world of difference when you’re driving around those levels.

DP: When you remastered all three parts: Did you use assets from ME3 in ME1, since they were already better quality?
Kevin Meek: Yeah, actually there were a lot of assets that are shared between the entire trilogy, so as they finished work on “Mass Effect 1”, “Mass Effect 2” would start and they have the library of assets to start from and a number of those made it through all the way up into “Mass Effect 3”.

Certain ones got improved in Mass Effect 3 and we were able to use those as a starting point. Especially with characters and also placeable props. Your job as an artist would be to ask: “Does this exist in ‘Mass Effect 3’? And does it look better in one of the other games?” It was baked into every single character armour and faces with the morph head system and wrinkle maps and all of your character customization options and more. But all came from whatever the best version was, which is generally ME3, but not always. Then we improve that and then brought it across the trilogy. But crates were unchanged. Some of the crates, which are so prevalent in a cover shooter, were the exact same crates that existed in “Mass Effect 1”, and it was kind of rough, but it was the exact same asset in ME3.

DP: What are you telling your colleagues working in upcoming games, now that you finished the remastering of a decade–long project?
Kevin Meek: I think for any game that we’re working on, it is good to have naming conventions and documentation – and get the artists to understand the best practice for that. The original Devs of the “Mass Effect” trilogy did a really good job with those. We can go back into the original Perforce and search files.
On the other hand, there is no documentation whatsoever of how to rebuild lighting in the levels, which is like a baked static lighting. But what layers do you show? And in what order? All because there’s just not a single page somewhere in some internal wiki that says: okay, here’s how to do it, guys.

It was all tribal knowledge, so that’s the main thing: Always assume that you are off the project in a week and that your tribal knowledge is going to be lost with you. I think, if you take that approach to everything and just over-save and over-document, then you’ll be in an okay state 15 years later, when someone says you’re amazing game is worth remastering.

The post Legendary Scaling – Mass Effect Returns first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Volumetric effects such as clouds, fog, plasma etc. are a frequent task in the daily work of a 3D artist. Technical approaches for the creation in Cinema 4D would usually be simulations with plug-ins such as Turbulence FD and X-Particles or the use of the ageing, voxel-based Pyro-Cluster system from Cinema 4D.

In the following, however, we will get to know working methods that enable volumetric effects in a very simple yet elegant way using only the onboard tools of Cinema 4D – and without the usual techniques mentioned at the beginning. We will focus on two possible applications with increasing complexity: 1. thin clouds and nebula fields and 2. stellar nebulae.

Thin clouds and nebula fields

The simplest and most direct approach to creating basic atmospheric effects is to use Cinema 4D’s inbuilt light sources as the actual clouds or nebulae. With a light source option to create foggy visible light and some inbuilt noise features, you can create thin, non-shadowy clouds or fog patches in no time at all.
But before we go into detail, let’s look at some of the basic functions of light sources in Cinema 4D. As soon as you create a light source in Cinema 4D, the corresponding attribute manager displays a series of tabs (Figure 01):

Light source – General tab

In the General tab, the colour selection and the intensity scale are the first noticeable parameters. The type of light source can be selected in the Type drop-down menu below. The types of light sources are listed below according to their degree of relationship to each other. The shape of the light emission determines the shape of its visible / volumetric effect:

• Omni: concentric light emission
• Spot: conical light emission
• Square spot: pyramid-shaped light emission
• Parallel spot: parallel, cylindrical light emission
• Square parallel spot: parallel, cuboid light emission
• Parallel: parallel light emission
• Infinity: parallel light emission from a point infinitely far away
• Surface: spatially extended light emission with a definable geometric shape
• IES: simulates the manufacturer-specific behaviour of lighting systems with photometric intensity

The Shadow drop-down menu offers a choice of three types of shadow generation:

• Shadowmaps (soft): generates a shadow texture from the perspective of the light source with selectable resolution, blur radius and proximity tolerance (bias).
• Raytraced (hard): creates an infinitely hard shadow from the perspective of the light source. This is by far the
  oldest and most unrealistic way of creating shadows.
• Area: the only type of shadow that becomes sharper or more diffuse depending on the distance to the object casting the shadow. This type of shadow is mainly intended for use with area lights or infinite light.

To create thin clouds or fog patches, we do not need to use shadows as the visible structure comes from the light source itself. However, to create fluffy, shadow-casting clouds, we will come back to area shadows in the next article.
The Visible light drop-down menu in turn creates the actual effect with which we simulate thin clouds or fog: misty and therefore visible air.
It offers three modes:

• Visible: Objects in visible light do not cast a volumetric shadow, even if a type of shadow is activated.
• Volumetric: Objects in visible light cast volumetric shadows – even if no shadow is activated (!).
• Inverse volumetric: Visible light is only generated in the volumetric shadow of objects.

Light source – Visibility tab

The Visibility tab refers to the Visible light drop-down menu in the General tab and offers numerous parameters for defining the visible light and its visibility along the axis or radius of the light sources:

• Axial decrease reduces the visibility along the Z-axis of the light source (e.g. for spots).
• Radial decrease reduces the visibility along the radius of the light source (e.g. with parallel spots).
• Inner/outer distance defines the start and end point of the strength of the visible light starting from its origin. These decrease parameters work independently of the decrease parameters in the Details tab – however, the handles of these parameters can easily be confused with each other in the editor.
• Brightness controls the intensity of the visible light.
• Dust adds a black component to the visible light at low brightness values, which creates the impression of an opaque cloud of dust.
• Relative size allows you to compress and stretch the visible light disproportionately and independently of its actual shape (e.g. for point lights).

If the Volumetric option is selected in the General tab / Visible light drop-down menu, the visible light creates volumetric shadows – even if no shadow is activated for the light source (!).

Sample-based calculation

The resolution of the visible volumetric light is determined in the Visibility tab by the Sample density parameter. You have to think a little outside the box with this parameter and its name: The sample density must be reduced in order to increase the number of samples. A high value (low sample density) speeds up rendering, but can lead to disc-like artefacts in the light volume. For a homogeneous result, you need a higher sample density, i.e. a lower value, e.g. 5 m instead of the preset 25 cm. However, this can slow down the rendering – see image 02 (low sample density) and image 03 (high sample density).

Tip for rendering

Especially if you combine volumetric light and a complex scene setup (complex objects, high-resolution textures, strong anti-aliasing), rendering can be slowed down considerably. You should therefore always render volumetric lights separately on black and then combine them with your scene in compositing. This can save you a lot of rendering time. Cinema 4D’s take system and the “Single material” option for overwriting all materials with just one material (render presets) provide the ideal tools for this (Fig. 04). You can find more information on this procedure in the Cinema 4D Help using the keywords mentioned.

With the parameters presented up to this point, we are already able to create effects such as search spots, halos etc.. For clouds and fog, however, we need to give our visible light one thing above all: irregularity. To this end, let’s take a look at the Noise tab.

Noise tab

The Noise tab gives light sources random irregularities in terms of visibility and/or illumination. The former varies visible light (if activated), the latter purely the lighting effect. There are 4 noise functions available for both purposes: Noise, Soft Turbulence, Hard Turbulence and Wavy Turbulence.
These noises can be adjusted in terms of octaves (number of calculation passes and therefore level of detail), brightness and contrast. Size defines the size of the noise only in relation to visible light, illumination size defines the size of the noise only in relation to illumination.
A movement of the noise can be set via the parameters speed (movement in itself), wind (direction of a uniform movement) and wind speed (speed of this uniform movement).

The Local coordinates checkbox determines whether a global or local noise is used. If deactivated, moving light sources are moved by a global noise; if activated (default setting), moving light sources virtually take the noise with them.
As visible light sources with noise are a fairly old but still current feature of Cinema 4D, the four types of noise are not directly related to the onboard noise shaders.

Case study – Nightmare Flying

This project for the TV documentary series ZDF “Leschs Kosmos” stages the hidden dangers of aviation in several animations. For the two sequences about the ditching of US Airways flight 1549 in the Hudson River and about the functional principle of radar, we used simple point lights for thin, turbulent clouds in the foreground (image 05, image 06).

In both cases, the point lights were set to Visible, but not to Volumetric. The Lighting checkbox in the General tab was deactivated to prevent the clouds from emitting light. The point lights were flattened using the Relative size parameter in the Visibility tab.
A hard turbulence was used as noise in the Noise tab. The trick to creating defined cloud structures lies in the combination of a strong negative (!) brightness and a strong positive contrast (Fig. 07).

The dense, fluffy clouds in the two scenes were created with the Ozone Cloudfactory 2015 plug-in – a plug-in for Cinema 4D R17 that enabled the creation of impressive cloud fields, but was cumbersome to use. The plug-in was discontinued by the manufacturer e-on Software at the end of 2018. A detailed making-of of the project can be found as a recording of my talk at Siggraph 2015 in Los Angeles here.

Case study – Steigenkogel

This free project is based on the Intel® benchmark scene“Mountainvista“, which I created for Intel in spring 2018. The landscaping of the scene is completely procedural – from rocks, pebbles, roots and dirt to valleys, mountains and clouds.
Large patches of fog in the distance were created using the same simple technique as described above: large, flat point lights with only visible light and an activated hard turbulence in the Noise tab (image 08).

Conclusion

Only with point lights, visible light and some high-contrast noise functions can thin, non-shadowy clouds or fog fields be created. This procedure is absolutely easy to master and is available at any time with just a few clicks.
The main limitation of this technique is the very basic use of 4 types of noise, which can neither be coloured nor combined with practical Cinema 4D shaders. So let’s take a look at another technical approach that allows us to overcome these limitations.

Stellar Nebulae

A more advanced approach to creating volumetric effects is based on the principle of texturing visible volumetric lights: you can easily apply any material to a light source – for example, if the active transparency channel contains a 3D noise shader, the volume of the light source uses this shader for three-dimensional volumetric texturing. The light source thus becomes a kind of aquarium for every volumetric shader that takes place within the transparency channel of the material! Important: This principle only works with visible volumetric light; visible light alone cannot be textured volumetrically.
With such a light container, it is easy to create more complex structures such as gas fields or stellar nebulae. The method of texture projection in the texture tag only plays a subordinate role here – as long as you use three-dimensional shaders 3D colour gradients or noise shaders in Room: Object or Room: World.
Let’s take a look at a simple example first: In Figure 09, a 2D tiles shader is applied as a texture to a parallel spot with visible volumetric light. In the texture tag, the projection has been set to surface mapping. The 2D texture follows the surface mapping and penetrates the volume of the spot in a rather boring way.

In Figure 10, a 3D noise shader is applied to the spot as an alternative. The surface mapping now no longer has any effect, as the noise shader has a three-dimensional or volumetric effect in relation to the light source due to its Room: Object parameter
(Noise parameter, see below).

One of the limitations of the thin cloud technique described at the beginning was the strict use of only 4 built-in noise functions. In order to use Cinema 4D’s more complex noise shaders as 3D textures for volumetric lights, it is important to first familiarise yourself with the basics of noise shaders:

Noise shaders – systematic randomness

Natural phenomena such as clouds, rocks or water surfaces are characterised by random structures with varying behaviour and complexity. In computer graphics, noise shaders approximate such natural structures. Noise makes it possible to give surfaces a random but reproducible irregularity, making them appear more analogue and natural. Noise can be used to modulate all aspects of a material. Compared to 2D textures, noises offer the decisive advantage that they can also be applied to objects in three dimensions, eliminating all the issues of correct texture projection or UVW mapping.
The US mathematician Ken Perlin was the first person to dedicate himself to the development of a noise shader. in 1981, as an employee of MAGI in Elmsford, New York, he was involved in the development of the Disney classic TRON. With his pioneering work on noise shaders, Perlin wanted to give the generated objects a less perfect and more natural look. in 1985, Perlin published a Siggraph paper on the resulting Perlin Noise, and in 1997 he received an Oscar for his achievements.
Through various further developments (e.g. Steven Worley’s Cell/Voronoi Noise from 1996), a handful of noise shaders found their way into Cinema 4D Release 5 as early as 1998. As part of the Smells Like Almonds (SLA) shader plug-in developed by David Farmer, two dozen more complex noise shaders were available for Cinema 4D from 2001, with exotic names such as Poxo, Luka, Sema or Pezo. Since Cinema 4D Release 7.2, they have been an integral part of Cinema 4D and are still on board today in an extended version.
With the classic channel-based material system of Cinema 4D, noise shaders are available as channel shaders and can be found in the shader drop-down menu of the material editor under Noise. From Release 20 of Cinema 4D, noise shaders are also available as nodes of the new node-based material system.
You can find them under the keyword Noise in the Asset Manager of the Node Editor. As the customer projects shown in this article were created with Cinema 4D R19, we will focus on the channel shader version.

Perlin, Turbulence, Luka & Co.

Cinema 4D’s noise shaders have very individual properties and are predestined for different purposes. Let’s take a look at a few examples:

• Noise as the default choice is nothing other than the original Noise Perlin: All components are of the same size, gradients between light and dark are represented by soft gradients. Higher octaves, i.e. further calculation passes, are not available.
• The closest relative, Turbulence, is basically a noise with additional octaves and can be used to create thin, turbulent clouds (Fig. 11).
• Luka, with its vividly different, partially scrambled details, provides a good basis for fine, thin clouds (Fig. 12).

An unequal kinship

At first glance, the noise shaders appear to be a loose collection of characters, but they are obviously close relatives: Turbulence with only one octave looks confusingly similar to Noise (test it out!), FBM seems to be a higher-contrast sibling of Turbulence, and the smeared versions such as Wavy Turbulence, VL Noise etc. already bear the kinship in their names (Figure 13). All these similarities have a reason: All noises in Cinema 4D are the offspring of a parent pair: Perlin and Voronoi.
For the selection and characterisation of noises, Cinema 4D’s help offers comprehensive and large-format overview images. An additional description of the shaders can be found in the somewhat older Noise Reference from cg.tutsplus.com.

Use of noise shaders

Regardless of whether you use noises as channel shaders or as nodes – noises follow a basic function and have almost all parameters in common: The type of noise is selected via the Noise drop-down menu. The Octaves parameter specifies the number of calculation passes and thus adds detail as the number increases.
This is followed by parameters for size, animation speed and gradation (clipping, brightness etc.).
Noise is applied in various reference systems. These can be selected via the Room drop-down menu. Four of these reference systems are of practical importance for everyday use:

• UV (2D) projects the noise onto the UV coordinates of the texture. Deformations of the object are taken into account.
• Texture uses the mapping specified in the texture tag
  specified in the texture tag. Deformations
  of the object are ignored.
• Object applies the noise three-dimensionally to the axis system of the object. Rotations, movements and scaling of the object are taken into account.
• World applies the noise three-dimensionally to the axis system of the world so that the noise remains in place while rotations, movements and scaling of the object are ignored.

In terms of our topic, the creation of volumetric effects, Room: Object is our reference system of choice, as in this case the noise permeates the volume of the object in three dimensions – or the volume of a visible volumetric light source. (You just thought “Aha!”, didn’t you?)

Layer and colour gradient shaders

To create more complex volumetric structures, it is important to have the ability to combine, overlay and mask different shaders within the same material channel. For this purpose, Cinema 4D contains the layer shader.
In order to be able to combine shaders in Cinema 4D in a modular and flexible way, the layer shader is the linchpin. The layer shader acts as a kind of container in which layers (shaders or bitmaps) can be mixed in a Photoshop®-like style, masked with others or used in different layer modes. The layer modes include common methods such as normal, multiply and copy into each other etc., but also a layer mode mask. In this mode, the layer above is masked with the grey levels of the layer below.
In the layer shader, bitmaps can be loaded by clicking on the Image button, shaders are created by clicking on the Shader button. Bitmaps and shaders can also be copied (Shader / Copy image) and pasted (Shader / Paste image) by right-clicking on a layer.
For better organisation, folders can be created by clicking on the corresponding button. To paste into a folder, drag a layer onto a folder until the mouse pointer changes to a small vertical arrow. You can also use the Effect button to create manipulations such as colour tone, saturation, contrast, distorter etc. on the layer below the effect.
Tip: If you load a shader or bitmap into a material channel such as transparency and then create a layer shader in the same place (by clicking on the small triangle to the right of “Texture”), the shader or bitmap is automatically moved into the layer shader as a layer.
Masking is an important topic within a layer shader, as you may want to restrict certain aspects of your shader setup to specific areas of your light volume. Gradient shaders are ideal for this.
Note on the corresponding node counterpart: The equivalent of the layer shader in the node material system is the layer node. In the layer node, it is also possible to mix layers with different opacities and layer modes. Each layer offers an open port for feeding in a suitable shader or image node. There are no folders or layer effects as in the layer shader. There is also no explicit layer mode for masking – instead, a layer is masked by connecting a suitable node to the opacity port of a layer. This is created in the layer node by right-clicking on the corresponding layer.

Colour gradient shader

The colour gradient shader creates 2D colour gradients on surfaces or 3D colour gradients through objects (or volumes of light). A 2D colour gradient can run linearly along the U or V texture axis or in certain shapes such as a circle, box or star. They can be rotated by specifying the angle, broken up by turbulence and frequency with animated irregularities and applied independently of texture tiles by deactivating Cyclic.
3D colour gradients, on the other hand, penetrate the volume of the object or the volumetric light source. The start and end values of 3D colour gradients refer to the reference system selected in the Space drop-down menu, e.g. the axis system of the object or the world. A pair of start and end values of -100 cm and 100 cm along the X-axis (the left of the three value pairs for start and end) means that a linear 3D colour gradient in Room: Object starts at -100 cm on the X-axis of the object and ends at 100 cm on the X-axis of the object. Start and end values on several axes can be used to angle a linear or cylindrical 3D colour gradient.
Note on the corresponding node counterpart: The equivalent of the colour gradient shader in the node material system is the node colour gradient or basic colour gradient. The only difference between the two variants is the richness and depth of detail of the available parameters.
In Release 20 of Cinema 4D, colour gradients come with some long-awaited features for interactive editing:

• Right-clicking on the colour gradient now offers the Size option to change the size of the display.
• You can now use the familiar hotkeys 1 and 2 to pan and zoom through the colour gradient, as you are familiar with from the Cinema 4D viewport. To reset the changed view, simply press H or click on the small black brackets to the left and right of the colour gradient.
• Click in the gradient, drag a frame with the mouse and select several nodes at the same time.
• As soon as several nodes are selected, you can move several nodes or several bias points together, change the common interpolation and execute various commands by right-clicking, e.g. invert nodes, etc.

Masking volume noises

And now let’s bring it all together: 3D colour gradients are ideal tools for masking 3D noises in a layer shader. Let’s look at a simple example: In Figure 15, the three-dimensional Sema-Noise is finished exactly cut off by the edges of the parallel spot (radius 100 cm).

In image 16, a colour gradient in 3D Cylindrical mode is used as a layer mask. The gradient is created using start and end values along the Z axis of the light source. This gives us the direction of the cylindrical 3D gradient. The radius is defined as a generous 150 cm and a large-area turbulence is applied (please note that a large turbulence structure requires smaller values and vice versa). The cylindrical 3D curve used in this way breaks up the edges of the 3D noise with a natural-looking irregularity.

Case study: A question of time (stellar nebula)

This project for the TV documentary series ZDF “Terra X” stages the process of stellar nuclear fusion, the molecular structure of salt and the principle of uranium-lead dating of fossils. For the sequence about hydrogen and helium atoms in stellar nebulae, I used exactly the principle described above: a (!) volumetric light source as an aquarium for mixed and mutually masking 3D shaders. The result can be seen in the title image.
If we take a look at this stellar nebula from an oblique angle, the whole dizziness becomes apparent (Fig. 17): The camera moves linearly through a visible volumetric light of a parallel spot – nothing else. A hard turbulence noise roughly characterises the large-scale structure of the light in the Noise tab.

In the Visibility tab, the brightness of the visible light is set to a huge 8000 % in order to also display darker noise details. A material called “fog” is applied to the light source, which contains only one active transparency channel with an integrated layer shader.
Within the layer shader, 3D noises and 3D gradients are organised in folders that relate to the logical structure of the stellar nebula: Mega structures, medium structures, small structures (“Nebula Blue” etc…) folders are in turn treated like normal layers and masked by noises or colour gradients.
When folders are expanded, their contents are revealed: noises of different types are coloured by a colourizer layer effect and restricted / masked to certain areas of the light source by 3D colour gradients. For a better overview, all layers are named accordingly.
In addition, the scene contains an environment object (Main menu / Create / Environment), which creates a simple but efficient black fog along the camera’s Z-axis by ticking the Activate fog checkbox. This fades out superfluous optical details in the distance that would otherwise only distract the eye.

Conclusion

With this article, we have learnt about two approaches to using visible or visible volumetric lights to create clouds or complex fog-like structures. In the upcoming second article in this mini-series, we will explore how to create an animated solar corona and even shadow-casting fluffy clouds.

The post Cloudy to fiery – Volumetric effects in Cinema 4D (Part 1) first appeared on DIGITAL PRODUCTION and was written by Bela Beier.