May 27th, 2025 - Final Render and Composite

Final Render and Composite

Final Render and Composite Breakdown - Including render layers and composting post-process

May 25th, 2025 - RBD Adjustments and Further Compositing

For this week, given the deadline quickly approaching, there aren’t many changes I can afford to make with my render farm issues, the amount of jobs on the weekend of finals, and family matters. However, I did some further development on my debris from my RBD as it looked very fake and unatural having the small bits break off from the POPs. Here is a new way I am doing the debris, using more particles and rendering the. particles as small objects for a smoke type look.

Here is it within the render. I can make it less subtle when it comes to implementing it onto my comp.

Something new that I have added within my comp is a quick lightning strike. I used a free asset from ActionVFX (https://www.actionvfx.com/) in order to do this. This project has a lot of stretch goals in mind, one of which includes building my own lightning strike within Houdini, however, given my need to focus on rendering this week, I will look into this in the future. Here is my node setup for the strike.

I used a 2.5 projection on cards using an alembic camera from my scene to match the movement.

I used both the beauty of the strike as well a s super blurry version to put underneath my tornado sim to get the best result.

Here is the current simulation as of today.

Some stretch goals for this project include having the lightning hit the turbine and catching fire to it. Having the RBD bend as it is broken. And finally, my camera movement may change to be match the camera movement of a car driving by. Overall, I have thoroughly enjoyed this project this quarter and am excited to keep going.

Professor Fowler gave me some advice for camera changes as the one I am currently using could use some work. I wanted to keep the “driving by” feeling and witnessing the storm but I changed the push in and whatnot. Here are some iterations of it.

May 20th, 2025 - Debris Adjustments and Composite Changes

For Professor Fowler’s critique of my project, the biggest thing to adjust was the debris, the one surrounding the vortex, the bits from behind the camera, and the bits from the turbine. I think the biggest issue I was seeing was the speed of the debris, as well as the look development and motion blur. Here is the original debris simulation.

I did some minor changes to the pop simulation, including reducing the speed and the emit lifetime, which explained the changing debris towards the end of the shot. My pops were disappearing after 7ish seconds, and when I copied to points, this changed due to the ptnum changing rapidly. Which explains the changing geo in the original sim.

I also added some more detail to my bits and pieces, adding different variations of noise and subdivisions.

Here is some basic look dev for my bits and pieces, the detail isn’t much, because they are going to be motion blurred, but this look dev is much better as opposed to the original simple shader I had put on.

Here is the new playblast for my debris simulations.

Here is a side by side of both the new and old debris within the render. The newer one has a much smoother simulation, as well as more believable motion blur.

Here is the full simulation with the debris added. I changed my camera clipping range, which got rid of my playblast artifacting.

Another thing I changed this week was adjusting my simulation to overlap my foliage/grass. Achieving this in the render would be easy, but my foliage is too strong for the farm to handle, which was why I was getting killed GPUs, so to combat this, I decided to render without the GroundPlane matte and used compositing to fix it. Here is the node graph for how I used the alpha from the foliage to adjust the alpha of my simulation.

Here is a clear view of my sim and. the stencil of the alphas added in comp. I created this using a tracked roto to avoid doing a keyframed gradient.

Here is a side by side of the previous render when there wasn’t any overlap of sim and foliage, as well as the new render where it is overlapping.

May 17th, 2025 - Simulation Detail and Test Render/Composite

For this week, I have refined some areas of my tornado sim as well as added some extra debris and dust.

To speed up the process of my tornado sim refinement, I used what we learned from Wei-Lin and wedged some caches to get quick and easy results to see changes made on. Here is the set up within the node graph.

Here are the 3 different caches for the disturbance parameter I set up, done through the wedging technique. The strength was the main adjustment in the wedge, I ended up going with a strength of around 87 for the current cache.

Here is the dissipation changes within the wedge. Done from 0.1 - 0.5. I ended up going with around 0.225 for the dissipation of the pyro solver.

My previous cache reached a size of about 550 gigabytes, likely due to my voxel size being 0.4 for the simulation. I knew this was something I wanted to fix before rendering, so here is the steps I took. First, I set my voxel size to 0.65 to have a lower overall cache size to a bgeo. Second, I turned my pyro sim into a VDB, which reduced my size about 50% without sacrificing quality. Then, to take it a step further, I took my render cam and was able to use a VDB Clip node to cull the sim to the camera frustum. My current simulation is about 60 gigabytes in total using these techniques.

Here is the viewport and playblast of the culled VDB cache.

Since I had changed a lot of parameters, I noticed in rendering I was getting this choppy cloudy look, to fix this easily, I used the same cache and added a VDB smooth node to blur it and keep the detail at the same time.

he next thing I added this week was dust being kicked up around the tornado, which helps break up that hard connection between the tornado and the ground.

I first started very similar to the tornado particles, using a circle of POPs to create the simulation, then feeding that simulation into a pyro solver.

Using the pop cache, I could take the trail of the sim to add more detail within my pyro without having to sim more points.

Here is the POPnet set up I used to achieve my result, this is prior to adding the trail and add. I used my POPs made within the POPnet to create a volume ready for the pyro solver.

My pyro solver was super simple, with some slight changes in dissipation and turbulence. Here is the pyro playblast as well as the same post process changes to save on cache size.

Here is the full current tornado simulation within the viewport.

The next thing I achieved this week was adding some various debris spinning around tornado as well as coming from behind the camera.

Here is the set up for a surrounding debris circle being drawn over the camera and ground towards the vortex.

Here is the POPs created from the surrounding circle, created using the physics of a popcurve node to create the pulling vortex force on the particles.

I then used these POPs as points so I could “sim to points” some small fragmented geometry with varying weight and materials. Here is the setup in the node gragh.

Here is the first pass simulation from the view of the render camera.

I also added some extra debris surrounding the tornado with the same technique of POPs and “simming to points.” Here is the setup, with both random mass and materials.

Here are two playblast for both the POPs and the geo fragments.

Here is the current state of the simulation with both the full tornado and new debris.

For this week, I have been struggling with rendering problems on SCAD’s render farm. However, despite this, I was able to get some frames from the farm, as well as locally, rendered and composited. I separated my scene into 14 different render layers for my composite, not only did this help with the GPU crashing issue and my ability with using the farm, but it also gave me more technical control in compositing with extra AOVs.

Here are all the AOVs I used for each render of both the geometry as well as volume renders.

Here are all the layers that were rendered out of my scene. 1080p resolution for each.

For the depth of my scene, in order to add some Depth of Field, I have been messing with new machine learning driven nodes within Nuke, one of which I have come to like is the DepthAnything gizmo. This is the depth map that it created straight from the node on my tree. I used this within the Bokeh node to have the most control of DOF that I could get.

Here is part of my node tree showing both the tornado renders as well as the grass renders and how I broke down the AOVs and did some post processing for each one.

Here is the the full composite test render for this week.

Here is a breakdown of my composite for an easy view of how I did it.

Long term goals include adding some movement to the grass, lighting the turbine on fire, and having the turbine bend over. However, short term, for this coming week, I plan on doing some minor changes to the RBDs and some lighting/texture development.

May 10th, 2025 - Further FX Developemnt

For this, I did some further development on my tornado as well as the redirection of the RBD of the turbine. For my tornado, I changed some parameters in my solver as well as adding some turbulence in an added forces node. Here are some different versions with different strength and reference scale for my added disturbance.

Here is the new sparse pyro solver with new forces and changes to parameters.

My voxel scale is currently pretty low, given that my vortex is pretty big in the scene. This will likely change to give me small cache sizes and help with render time. I also added some base disturbance and shredding to my vortex in the solver.

Here is a current playblast of my simulation. It is pushing 500 gigabytes for the whole 240 frames, so lots of optimization is to be made, since I am no long able to test out the ZibraVDB tool.

For my RBD sim, I re-used the same fracture method and glue constraints, but instead of pushing with wind, I used two popcurve forces to simulate the pieces being dragged into the vortex. I used a larger one for the slight pull and a smaller one about the size of the tornado for a stronger pull. Here is that set up in DOPs.

Here is the current RBD fracture.

I also adjusted my debris DOPs to react to the popcurve force the same way. Here is that current set up in DOPs

Here is the playblast of the current debris POP.

Here is a combined playblast of both the new tornado simulation as well as the current RBD fracture. I am still running into issue with rendering on the farm, but I will be testing some adjustments to my ROP which might be the trick for fixing my GPU crashes.

May 4th, 2025 - Slap Composite, Test Render, and Simulation Update

This week, I was focused on the final render/composite of my turbine destruction and pyro project. However, I was able to render out 48 frames of the current state of my Tornado. I first did look development on my grass to get the texture and feeling of grass that I desired. Other than the opacity map, the grass is procedural texture wise. Here is the lookdev render for the grass I will be using in my scene. I kept it simple as it will be small and have intense motion blur.

For my current scene, I took my most recent cache and locally rendered 48 frames. I chose not to do layers just yet since this was a test render and wanted to same wrangling time. I tried putting my file on the render farm, however, I was getting many issues with frames being killed dude to the new limit on the GPU usage per frame. This will be a challenge I knew I was going to face coming into this project as my simulation cache is very large and requires a lot of GPU power. Regardless, here is the node setup I have built preliminarily adding some roughing adjustments including lens dirt, chromatic aberration and grain.

Here is the current test render for my scene. The biggest thing I notice is the lack of detail in the vortex as well as how dense it appears. Lighting will be adjusted as renders get done, but for a first test, I think it came out alright.

For my turbine destruction, I plan do use this set up I have currently with the constraint, debris and pyro all the same. The one big change will be the forces acting on my breakage, in which I plan to set up a Popadvectbyvolume node to have the pieces be drawn towards the vortex as it spins. I also plan to do this for misc debris surrounding the vortex and have some come from behind the camera as well. Here is my current reference and RBD simulation.

For my simulation, I have switched from using legacy pyro to sparse pyro, as when I initially set it up, I wasn’t familiar with the difference. However, this set up should help me keep the bounding region for my pyro to be local to the actual simulation and not set by a bounding box and having wasted space of information. Here is the setup, a lot of it similar to the legacy set up, but with added shaping detail of disturbance and sharpening.

Here is the current state of the vortex, caching is taking longer than wanted, but given the size of the simulation, it is relative.

April 27, 2025 - Layout and Turbine RBD

This week I focused on layout of Grass and Shrubs, as well as the RBD destruction I will be incorporating in my final Render.

I used scattered and jittered points on my ground plane which allowed for random placement of grass and shrub elements obtained from Megascans. I will likely create my own grass geometry and textures, but for time, I will be using these assets.

Randomly groups points, subtracting the previously grouped from the new group.

Culled points to camera to lower geometry load.

References for grass shape and patched layout on ground plane.

Load time per frame was slow in viewport, even with cache. Likely will use proxy geometry for further geo from camera for final render.

RBD Destruction of Turbine:

This destruction was made for this render, using specific wind forces in mind. Here is the render as well as the reference video.

For my use in my tornado scene, I will change not only the direction the wind blows, but also use a popadvect force so that the debris and destruction get sucked into the vortex. Furthermore, I plan on having the RBD bend on itself if time permits.

For the fracture, I first split the body and turbine of my geometry. Controlling the fracture at first was difficult, but one I understood the way the RBD Material fracture used the fed points, I gained better control. After packing the primitives, I was able to group the geometry based on the pieces.

Here is the current state of the fracture on the turbine

Here is the setup within the DOPnet, as well as a view of the delete bounding box in the SOP Solver.

Next, I built a Debris emitter to add small debris POP when my turbine broke. I set the the POPs to be active when the destruction started and the pieces broke off.

Here is the Debris from the turbine destruction. It is hard to see, since the particles and copied geometry is small, this will be worked and the pieces will be grown in size.

For the small bit of pyro I added onto my turbine, I used the internal connection unit within the turbine geometry itself as my emitter. I set the point using pyro source, added velocity attributes, and turned it into a volume, ready for the pyro solver.

I knew I also wanted the smoke to collide with not just the spinning blades, but the body of the turbine as well. To do this, I turned the build RBD as a VDB, first making a fog, then making it a SDF, which allows it to be used in collisions. Getting the size of my VDBs was tricky as too small meant insane cache times, but too big meant for bad collision data.

I also wanted the pyro to start being blown based on the height it was at, so that the moment it went above the hub, it wasn’t immediately sent backwards, this also helped with the pyro being blown through the hub in early collision tests.

This set up using a wrangle was taken direction from Deborah Fowler (https://deborahfowler.com/HoudiniResources/MiscSources/PyroTips.html.) However the technique was referenced by Scott Keating’s custom velocity within VOPs.

Here is the DOPnet I built with my pyro solver. The biggest challenge referencing the collision geometry correction. The setup for Legacy Pyro Collisions is straightforward, however the setup for Sparse was a little more technical and required much more R&D.

Here is the current playblast of the layout for my scene. Clipping Grass to be fixed.

Next steps include working the tornado simulation, reconfiguring the RBD Destruction, and adding some movement to my grass!

April 13, 2025 - Technical Pyro Setup and Test Cache/Render

For my project going forward, I plan on using Redshift instead of Karma. As much as I enjoy Karma, I find it to be slower when it comes to navigating not just the viewport render but materials and lighting changes. My machine runs smoother when using Redshift rather than Karma when I am not currently rendering to disk, so for ease of the process, I will be using Redshift.

To start this week, I took my POPnet, cached it out and transformed it slightly above the ground plane. I added a timewarp to set my cache frame range to 300 frames. I then clipped anything 10 units above the origin to exclude any particles getting lost under the plane. This motion becomes my “Track” of the tornado, which is the motion I will use later down the line in the simulation. I cleaned up the attributes and set value of pscale to fit within 0-0.645. Here is that setup in the node tree!

Next, I took a for-each node, retiming it to not interpolate the position so that my velocity isn’t “rebaked.” In the for-each, I am adding more retimed iterations of my particle POP. This creates a thicker particle sim that I can adjust further.

I then took an add node to trace the id attribute for the particle path, then resample them to get a “jittered” variation.

I then took a pyro source to get a density attribute in the particle path. This is another thing I am using from our last project we did in V428.

Next, I set up a volume rasterize from attribute node tree. Within the node, I am using both the density attribute and velocity attribute to build a voxel volume. I added some slight velocity blur and had larger voxel sizes to rid the banding. I am using the density attribute to adjust my coverage scale. This was a good to “paint” my points into voxels while controlling the resolution of the volume.

I then take this voxel volume and feed it into my DOPnet for my pyro simulation.

The next part of this process was building up my pyro solver and using what I have made previously as a “mask” for this simulation. Here are some of the adjustments I made.

I create my simulation with a division size of 0.5 to have a fair bit of detail in my smoke.
Using a Gas Resize Fluid Dynamic node, I resized the bounding of my dynamic simulation. I took my “Track_OUT” from the POPnet to add the motion and shape for my tornado. However I adjust my POPnet simulation, it will directly impact the shape of my simulation. I adjust the padding/threshold for this object so that it isn’t forced in the bound of the POP simulation.
I used the Gas Turbulence node to add some randomness and noise to my Pyro’s velocity. I also wanted to add some drag force to my simulation but was getting odd results with the Drag node so I settled for adjusting the velocity in a wrangle node.
For the post-solve part of my solver, I use a Volume Source node to set the density and velocity based on previously made attributes.

I also adjusted the buoyancy lift so that full control of the sim shape is in the control of the track. I also changed the dissipation so that the time/age of the smoke is controlled.

Here is the node setup within my DOP and the result cache simulation.

For the last thing I did this week, I wanted to add some spin to my turbines.

Before my for-each node, I took a wrangle node and used this code to create an attribute offset.

I@offset = int(fit01(rand(@ptnum + 1), -25, 50));

Within the for-each node, I attach a spare input from the Offset into the timeshift to allow a shift parameter in the node. Here is that node setup.

Here is a quick test render with my current camera in Redshift.

I will not be having my tornado start from the ground up, I just have yet to adjust this timing.

April 6, 2025 - Preliminary Particle POP and Further Research

For this week, my main focus was finding both references and resources that would help me chip away at this project, going from the big picture to eventually the fine details. Using some advice from Professor Fowler (https://deborahfowler.com/), I went searching for not only more references but guides for building this twister.

First I began looking at more detailed references for my tornado. Since iPhone cameras typically have a difficult time capturing clear images in huge twister storms, I looked at some movie and CG references to help me see the actual level of detail some twisters have

Here are some reference images and links I have found for this.

Twisters (2024) - There isn’t great detail in tornado itself, but I found the destruction/debris at 7:30 particularly interesting.

From Professor Fowler, she directed me to some professional breakdowns on movies like Superman (2013) from companies like Scanline VFX. Here is that reference.

Here are some other references from youtube of varying tornados, though some have different levels of rendering and quality, any references is helpful for this project.

This is a documentary/news package I found that dives into the history and journalistic science of how super tornados are formed.

This week, I dove into creating my tornado in Houdini. I know the “why” and the “what,” but the “how” was my biggest challenge for this project. Professor Fowler directed me to the OdForce forum (https://forums.odforce.net/), where many artists within Houdini troubleshoot and solve problems for each other. I spent a lot of time on this forum addressing many of the issues I encountered.

I began by breaking down the different levels of the tornado. From my research, it seems there are four main parts of a tornado: the debris cloud (bottom), the funnel cloud, the spiral updraft, and the condensation funnel (top). To create the body of the funnel, I decided to use a line as my “path,” and employed two POP kicks to generate points. Essentially, I created points on two separate scatters and had them twist around my path.

Initially, I thought I could get away with using a POPCurve in DOPs, but that didn’t give me enough control or the physicality I wanted for my vortex. So, I decided to use either VOPs or VEX within DOPs. Before diving into that, however, I first built my elements. Here is the graph of nodes, with my three inputs.

For my ground plane, I used the adjusted plane from my turbine SOP and extruded it upwards. I then applied an isooffset to create a shell or volume from the geometry, onto which I scattered points (alternatively, I could have used the "Points from Volume" node for this). Below is how it looks in the viewport.

I did something similar for a ring shape (circular base of the twister), but animated a mountain node to add some variation and movement in the scatter.

Next, I set up a POPnet at the SOP level to help visualize my scene more effectively.

For this setup, I was able to quickly build the VOP network. Here's a breakdown of what each part of the network is doing.

I start by creating a point cloud based on the line I made earlier, searching within a radius of 65 units (my scene is quite large compared to the “TommyGEO” size).
In the point cloud, I filter out the attributes “P,” “tangent,” and “curveu” into their respective spots.
- “P” is used to filter the points
- “tangent” filters the direction of the line
- “curveu” filters the curve path on the line
The filtered “P” attribute from input01 is then subtracted from the global “P” attribute.
After that, I take the subtraction and cross-produce it with the tangent (resulting in a perpendicular vector). I then normalize the vector and multiply it by a constant (currently set to 1, but this can be changed to affect the shape).
I also take the inverse of the constant multiplication of the tangent to control the height—lower values result in a higher vortex in relation to the line’s tangent.
For the shape of the vortex, I feed the “curveu” into a ramp. Based on the float value from the ramp, and within the fit range, this defines the shape of the twister.
To add some random thickness to the twister, I randomize the “id” attribute of my global points, setting it to the range of the float values.
I then multiply everything that affects the thickness/width and add it to the height, along with the previously subtracted points.
Finally, I bind out the random displacement of points to be used in higher parameters within the VOP.

Below is the VOP node tree and the result in the POPnet.

It took some head scratching and a little bit of time, but I wanted to build this network using VEX as well, mainly to expose myself to both sides of the coin and see if I could understand both. I will say I had more fun problem-solving the VEX code for this, but VOPs were significantly easier to follow when it came to understanding where attributes/filters were going.

The setup and process are identical to what was described above. Here is the VEX snippet in the POP Wrangle node.

I then added some forces like drag and counter forces to add some realistic jitter and movement. These values will likely evolve over time.

Here is a side by side playblast of both the VEX code and VOPs working in my POPnet.

VEX VOP

Input variables are slightly different; VEX is closer to the desired path, thickness, and twister motion.

This playblast shows the relative scale of the tornado I am looking to achieve. It is not yet the correct shape or velocity, but now that the VEX and/or VOP code is set up, depending on which one I use, I can adjust the values for velocity, thickness, shape, and size of the twister. Two of these are top-level constraints that can be handled in the wrangle, but the other two can easily be converted into artist-friendly controls.

In my later version, I will retime the particles so that they start from the ground at the beginning of the scene.

March 28, 2025 - References and Layout

This Blog is mainly going to be focused on the final project for the quarter in VSFX428 - Particles and Procedural FX. For my project I am planning on doing a tornado FX simulation. This project is FX based, so my main focus will be on that, but as I am a lighting/compositing artist, I am excited to take this project beyond the FX. I have been doing much research on this and want to do a scene in an open Wind Turbine field. Not a huge lot of destruction, but I plan on doing a hero one with a foreground turbine.

Here are some references I have been collecting for this project.

Here is some gif animations for some video references

I also took some of these references and some prompt into DeepAI to build a scene layout for what I was thinking as far as shot design and mood. Here is the best option I got, some were VERY unrealistic.

For this project, I want to render out layers of my simulation for compositing and render time purposes. Here are the layers I am expecting to need.

Core Surface Simulation - Tornado 03
Core Surface Detail Simulation - Tornado 02
Ground Simulation - Tornado 03
Large Scale Ground Simulation - Impact
Foreground Debris Simulation
Debris Simulation - Wind Turbine
Controlled RBD Simulation - Wind Turbine
Lightning Simulation - If Time Permits
Fence Beauty
Turbine Beauty
Greenery Beauty
Sky Comp

These are subject to change, and for the FX, a large part will be rendered together to help with less trips to the farm.

I am fully seeing this project as something I come back to from time to time and evolve over time.

I began some technical preliminary layout this week to get this project rolling.

I knew I wanted to build this scene procedurally, so beginning with the ground plane, I moved the points along the Normal using VEX, and subdividing for a smooth surface. I took the unsubdivided layout and randomly roomed some points to add variation, I used P.y for this since those are the points with the most variation. I also added some boundaries for P.x and P.z since I wont need turbines all over/behind the camera (Scene will be culled to the frustrum eventually). Here is that process of laying out the turbines.

Here is the current node tree for this setup, I have broken apart the wind turbine asset for better control and imports.

For the fences, they were built using cubes and simple mountain @N noise since they aren’t huge in the scene. For laying them out I am taking a for each node, using the bounding box and iteration # of the fences to build the row procedurally. I am also using the minpos() of the points on the grid so that wherever I lay the fences, they will conform to the flow of the ground. Here is that node setup as well as the viewport view.

One of the final preliminary things I wanted to begin was the camera movement. If I can lock the camera early, this will help me later down the line for lighting/rendering. I started with a simple camera animation, then added some MotionFX noise to both the rotation and the focal zoom. Here is that view in the animation and noise editor.

Here is the viewport playblast of the current movement I am working on! Where the camera zooms, the turbine will be bent and destroyed by the wind force of the tornado.

I have also started some initial lookdev on the turbine and fences. These details aren’t super visible, so the quality of the maps wont be super high or strong. I build these in adobe Substance Painter.

I plan on rendering in Karma CPU in this project as I want to do more work within it overall!

Turbine References: