FumeFX 4.0
It’s been a little bit of a wait for the next iteration of the popular, near indispensable fluid-simulation engine known as FumeFX. But version 4.0 is now available, and is simply more of a good thing.
The principal update lies under the hood with a new solver with new maths. The original conjugate gradient solver was already pretty quick, but the Quasi-Newton Conjugate Gradient has replaced the older version to decrease sim times and increase detail, which, I can attest, is readily noticeable. To add to the speedup, some parameters for objects that react to the simulation have been added to reduce the amount of voxelation required to interact. Also, speed increases a bit by sharpening some channels, such as velocity and smoke, during the sim. Not only that, but it retains detail in the smoke for a longer period of time.
Speed isn’t everything, however. There has to be a balance of speed and accuracy.
On the physically accurate side of things, an oxygen component to the volume has been brought in, because as any chemistry student knows, you need both oxygen and fuel to burn. When oxygen and fuel hit a threshold in the FumeFX volume, ignition happens, and then both fuel and oxygen are consumed, making for potentially more accurate simulations. The accuracy continues into the rendering of the burn with a black-body shader using real math and driven by temperature, so the hotter you burn, the brighter the flame (more or less).
Next on the list is making sims controllable — because clients want cool, not real. FumeFX already had spacewarps that you could use to massage a simulation into a position that it wouldn’t normally want to fit. But now a spline follow force can be applied to guide the simulation along a specific path.
And lastly, in terms of compatibility and interactivity, FumeFX 4 has OpenVDB support and Field3D for moving data to programs such as Houdini, or pulling in fluid data from those programs. It also can bring in PRT caches from Krakatoa or PDC files from Maya. And it supports VRay’s deep data for compositing in software like Nuke, which, in my opinion, is critical for getting these kind of volumetric renders working in your comp shots.
If you haven’t used FumeFX, then give it a shot. You’ll have cool looking stuff within an hour of opening it. If you have been using it, then you already know its power, and version 4.0 isn’t going to disappoint.
Houdini 15
It looks like this is going to be the effects review issue! Side Effects gave a sneak peek of Houdini 15 at SIGGRAPH this year, and last month it finally became available to the masses. I’m just going to say right now that the feature set goes way beyond this review, so be sure to take the time to visit the SideEffects website for all the goodness that Houdini brings. I’ll focus on the VFX features here, and even then, I won’t be able to hit everything.
The most exciting advance, in my nerdy mind, is that for every kind of dynamic simulation — fluids, pyro, water, grains, etc. — the solve can be distributed across multiple machines without a dependency on previous frames. In essence, if you have a farm of machines and the licenses, you can create one, uberworkstation that works on multiple parts of the grid volume, communicating channel data across the grid seams to keep everyone on the same page. I cannot express how advantageous this is as our directors demand larger and larger objects falling into larger and larger bodies of water … filled with burning oil and lava.
That brings up viscous fluids, like chocolate and lava — and chocolate lava. This was the big thing last year, and in this new version, SideEffects has put in tools for even more complexity. Temperature and variable viscosity means that hotter fluids will be more runny, while colder ones will be more solid — and that can change as the objects cools (or heats up). This propagates into the shader for lava, where the temperature drives blackbody emissions, so the hotter the material, the brighter the material. It can also drive the formation of a delicious lava crust.
The FLIP solver for water and whitewater is highly optimized, compressing the volume and necessary data per frame so that it takes up less drive space. The compression is lossy, so, like a JPEG, it’s throwing out intermediate data (particles in this case), which can be rebuilt when the sim is reloaded. Additional optimization comes from culling the data to the FOV of the camera. The solver can handle up to 2 billion particles, which is also the case for the grain solver.
Speaking of the grain solver: For sand and dirt and fine particle stuff, the grain solver benefits from the same distributed simulations and high particle count. Sand has the unique quality of needing to be stable when not moving, despite a gagillion internal collisions taking place. Frequently this leads to jittering and exploding simulations. So, there is a node that puts particles to “sleep” until a fast-moving object or particles come in — and then the awaken node brings them back to life.
Despite this cursory overview of a substantial feature list from a feature subset, this gives you an idea of the critical advances SideEffects has been concentrating on. Current Houdini users should be at least a little giddy.
Thinking Particles 6.2
The latest build for Thinking Particles isn’t technically a full point up, but it sure seems like it should be, mainly because of the integration of fluid dynamics into the rest of the dynamics systems. This is no trivial feat, which has been in the works for years now, and only now is it revealing itself, in the face of established competitors like Realflow and its neighbors in this review, FumeFX and Houdini.
Drop 6.2 is filled with goodies, but the primary focus is on the fluid sims, which rely on a vorton approach rather than a typical voxel-based approach. In broad strokes, this means that its particle driven, leaning on vorticity vectors to calculate the movement. Because it doesn’t use voxels, there is no container for the fluids to live in and no “resolution” per se. This makes it incredibly fast to calculate, and you can do things like calculate very fine solutions, which would normally require incredibly high resolution grids. All this is well and good, but the strength lies in the ability for the smoke solver to work with the other dynamic solvers within Thinking Particles. So, basically, everything in your simulation is self-contained and interacting with and affecting each other. Not only do your fluids react to the rigid body simulation around it, but you can have the inverse — the pressure from the fluid can push back. And you can assign temperature to objects that have an additional thermodynamic effect.
And what would you do with the particles if you can’t render them? Cebas has included a volume particle renderer, for just such an emergency.
It’s a substantial jump in technology for an already-sophisticated software. If I were to quibble at all, it would be that I still get more robust fluids from FumeFX and Houdini (at the cost of speed). But that’s just a matter of evolution and to be expected in the first round of a new feature. The Cebas engineers are brilliant and they’ll iron that stuff out. In the meantime, you can still get very fast fluids from TP and use the particle velocity channel data in FumeFX or Thinkbox’s Stoke.
Great release. And it all just updates with your Thinking Particles subscription. Can’t wait for the next drop. Perhaps some native Alembic support?
