Procedural Clouds plugs into Blender as a volumetric sky builder aimed at Cycles, letting you rough in atmosphere during lookdev before lighting turns everything into a science project.

How?

Procedural Clouds exposes its controls in the N-panel, so you can steer the setup without opening node graphs. That matters in production because fewer accidental edits land in the wrong graph at 2 a.m.

Solid Preview is the key switch for fast iteration. Turn it on and the clouds show up in Solid mode. There is also an auto mode that watches viewport shading and toggles Solid Preview for you, keeping it off in Rendered mode and on in Solid mode.

The add-on also includes a Pin system that locks the UI to a target object so the controls keep talking to the right volume even when selection gets messy. Pin Auto Switch exists as a preference and is enabled by default, letting the pinned target follow the currently selected supported object. Turn it off and the pin stays glued to the original target.

Scene tweaks you should notice before they bite

Some features can automatically adjust Blender scene settings during use, including volume bounces, step count, and clip distance. If you want your scene settings left untouched, you need to disable those options in the add-on preferences or dial them back.

Clip Start and Clip End are specifically called out for Solid Preview artifacts. If the volume looks sliced or flickers, raise Clip Start. If the cloud gets cut off in the distance, raise Clip End. You also need to set matching Clip Start and Clip End values on the scene camera.

Made by Suzanne studio, the docs also flag that Blender 5.0 changed the algorithm for Voronoi Texture, so presets can look slightly different between Blender 4.5 and 5.0 even when the cloud remains the same and the seed changes.

Scaling rules that keep the look consistent

The scaling behavior is split by mode. Scale in Object Mode and the object changes size without changing internal settings, so the effect parameters stay the same and the visual result stays consistent. Scale in Edit Mode and you change the underlying volume or mesh size, extending the existing content while keeping internal settings and detail density stable.

The recommended starting point is a cloud object around 2 meters, then resizing in Object Mode. After extreme scaling, you may need to adjust Density to get the result back to where you want it, especially if your cluod suddenly looks like it went on a diet.

Knobs that trade detail for speed

Three controls define the look to cost relationship. Point Density controls how full the cloud is. Higher values produce thicker and more detailed clouds, while lower values produce lighter clouds and faster performance. Point Size Min and Max control variation in the cloud shapes. Higher values push softer and puffier shapes. Lower values push finer structure. Volume Resolution controls the final detail of the volume. Higher values sharpen detail but slow things down. Lower values render faster with a softer result. That resolution knob is also where perofrmance usually goes to negotiate for lunch.

Keeping your scene clean while you iterate

Make Unique creates an independent copy of a selected object so changes do not affect others. It is built for the classic moment when you duplicate a cloud, tweak it, and discover you just changed every cloud in the shot.

There is also a note about removing a Boolean Empty cleanly. Deleting the Empty in the viewport may leave it in the scene, so removal can require deleting it from the add-on panel or deleting it in the Outliner.

New tools and innovations should be tested before use in production, especially when they can touch scene settings and when shot continuity depends on repeatable volumetrics.

https://superhivemarket.com/products/procedural-clouds/

https://www.youtube.com/@suzanne_studio3d

Licensing and tiers

Pricing is tiered into three licenses, all of which include creator support and future updates.

The Personal tier costs $25 and is for personal or non-profit projects.
The Commercial tier costs $45 and is for commercial projects.
The Studio tier costs $110 and is a multi-seat license. It also lists custom features request alongside creator support and future updates.

The post Procedural Clouds with Cycles focus first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know: Compositing Academy (Alex Hanneman – LinkedIn | IMDB) is a training and development hub created by professional compositors for compositors. The studio produces practical tools and VFX courses focused on real production use rather than theory.

A True Volume, Not a Trick

Compositing Academy has released Volumetric Noise, a fully three-dimensional procedural noise engine for Nuke. The plugin raymarches genuine 3D volumes in Nuke’s viewer, eliminating the need for 2D cheats to fake atmosphere, fog, or cloud layers. It runs on Windows and supports Nuke 16.0v6 through 17, with limited fallback for 15 if the Vectorise CPU option is disabled in the Blink node.

Raymarching is a rendering technique that steps a virtual camera through a 3D field to calculate light, density, and colour at each point, supposedly allowing realistic fog, smoke, and cloud depth.

Unlike card-based noise projections, Volumetric Noise works as a native volumetric renderer. It allows full control over shapes, erosion, and motion, functioning like a simplified 3D render engine embedded in Nuke. The plugin is aimed at compositors who want realistic parallax, light scattering, and shadowing without round-tripping to Houdini or another 3D package.

Real Depth, Real Shadows

The plugin supports one directional light source, providing reactive lighting, shading, and shadow steps for density control. Shadows can be biased and jittered for fine-tuning. Lighting intensity and scattering parameters emulate volumetric fall off, enabling backlit frog and soft illumination effects.

Density, gain, and gamma settings define softness and depth, while erosion and distortion layers introduce non-repetitive structure. These features enable art-directing density variation, wispy edges, and natural cloud breakup, effects usually reserved for full 3D simulations.

Occlusion and Parallax in Comp

Volumetric Noise supports Z-depth and P-pass occlusion. Volumes can be masked against 3D geometry or plate-derived depth data, enabling integration with live-action environments. Although the tool does not support deep compositing, it provides bias and contour softness controls to reduce aliasing in Z or P data.

Alex states that this approach covers around 60 to 70 per cent of typical atmospheric compositing tasks. Deep compositing remains necessary for complex holdouts, heavy motion blur, or fine geometry such as vegetation. Camera parallax and real 3D movement are fully supported. Artists can fly through volumes and preview them as point clouds in Nuke’s 3D viewer, which aids precise placement and occlusion alignment.

Lightweight and Fast

The developer reports near-real-time playback and rendering speeds of about 1 second per frame, depending on sampling and scene density. Built-in optimisation features include slicing, space skipping, and a heatmap visualiser showing where calculations occur in the volume. Empty space is automatically skipped, improving render efficiency. Motion blur is achieved by exporting motion vectors that combine camera and noise movement for use with Nuke’s VectorBlur node. Internal defocus is not supported; instead, users can split volumes and defocus externally.

Designed by a Compositor

Alex positions the plugin as an artist-friendly tool, just the controls you need, nothing more. Presets include base clouds, ground fog, backlit fog, wispy volumes, and world-space scalable cloudscapes. The developer emphasises that Volumetric Noise is procedural, not a pre-baked VDB loader, and aims to offer infinite variety for shot-specific art direction.

Pricing and Availability

Volumetric Noise is available now from Compositing Academy for USD 99. A free watermarked version is offered for testing, labelled as BETA. The plugin requires Nuke Indie or Nuke Commercial and is compatible with Windows systems. Future minor compatibility fixes are planned. A potential version 2 update may involve an upgrade fee. As with all new tools, users are advised to test the plugin in their own production environments before deployment.

The post No More 2D Smoke and Mirrors: Volumetric Noise for Nuke first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

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

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

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

DP: How did you get onto the Lost Bus? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oliver Schulz: Myself :)

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

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.