Hi guys! Welcome to week 2!
I had some time over the weekend to get a couple more firepit layout iterations in and get it to a place where I feel comfortable working on the pyro more. I wanted to get that out before seriously messing with the pyro source since that is dependent on the placement of the assets.
I approached the layout more methodically: thinking "how would I build this firepit?" Big, organic tree branches first, then log pieces to fill in the holes? The log pieces more towards the bulk of the pit where I would want them to burn? Maybe have some dead branch fill to add interest to the composition.
I also fixed the kettle model a bit more and then placed it less precariously then I had before by creating a sort of "bowl" with the wood pieces.
There are about 70 Quixel assets in the scene. I plan to refine the exact position further later by using the Stage context in Houdini for the quick bullet physics. This is however more or less the final composition of the pit.
Layout - Iteration 8 - Approved! (in video below)
Now to the FX! I've been first working on the main pyro: the fire (no smoke yet).
I started with a simple set up to get the sim running and then I focused on evolving the sourcing of points for the pyro source. So we know what that means... GROWTH SOLVER!
At first I used a simple sop solver with an attribute transfer to decide how many "sparks" I wanted to start the growth from. The issue is though with a transfer is that transfers very uniformly in a circular fashion.
I needed to dive into VOPs for a custom attribute transfer using point clouds and noises. Out of the box using a search radius from pcopen still produces a rounded transfer. The trick is to multiply against noises and a selection compare.
Layers of noise take in P of the previous frame and the Time to generate the noise. Those results are then converted to floats and clamped to a 0-1 range to be multipled against the Cd vector of the "active" points.
The pcopen is taking the "active" points (represented in white) and finding neighboring points within the search radius I define (which can be very small to produce a more detailed radius when mixed with noise) and produces a handle, either 0 or 1 that I can use to grab the Cd attribute of the found points.
To even further refine the search, I can multiply the Cd attribute by a random number that is under a percentage selection threshold. I have it cranked down to five percent.
Then after these operations, I use max nodes to make sure that if the point was "active" before it will still be active.
Inside my growth solver, I also snagged the setup_life VOP network from a pop source node to use age and life down the road.
I haven't had too much experience with pyro and the main thing I'm finding to be a challenge is getting the flame shape that I want. Right now the flames are very strong compared to the reference that I have. I want controlled, licking flames.
Things I need to focus on tweaking would be the temperature control. Increase cooling rate, lower the acceleration strength in the volume source, and start layering microsolvers. Right now it has disturbance, shredding and turbulence applied at only one level each.
I also have a feeling I will have two separate pyro fire sims. Some of the branches are very thin compared to others and those should have a different level of detail applied than the main flames. It would be easiest to break that out separately to have more artistic control.
Something that I stumbled across this weekend that I definitely think I want to implement for one or a few of the particulate layers is a wonderful hidden gem in Houdini called the filament solver. _/(0 o 0)\_
Sounds pretty interesting right? Apparently, its been around for several years in Houdini. I saw demos as far back as version 13! I've only been using Houdini since 16.5). Here's what it does, if you don't know already:
(courtesy of Erik Ferguson and K240 on vimeo)
Filaments are closed polylines that represent vortex forces. It's a simple set up to implement with a pop sim. The filament geometry is sourced into a pop source which is then fed into a source filaments node which then appends new filaments that are created (when you define it to) to the geometry subdata on the pop object.
A pop advect by filaments node is used to advect to particles using the velocity field from the filament geometry. A filament solver runs after the pop source and force nodes (and the like) which is all piped into the post-solve of the pop solver.
Its a really powerful thing to add to an already powerful pop sim for a neat effect. Any pop forces or operations you add to evolve you sim are very flexible in placement so they can be calculated in a different order to achieve a result you want, even with the added filament solver.
Definitely will be implementing!
Til next week for the first checkpoint, happy renders!