For those who don’t know the tool: tyFlow is a particle and simulation plugin for 3ds Max. It is commonly used for particle effects and procedural simulation within pipelines. The tool expands 3ds Max application simulation features with node-based operators and GPU-accelerated modules.

A CUDA fluid solver arrives

The 2.000 release of tyFlow introduces a new GPU fluid simulation solver named ZENITH. According to the official release notes, the solver runs on CUDA and integrates directly with the tyFlow simulation environment.

The update also introduces twenty new operators for the Inferno module. Inferno is tyFlow’s internal system for simulation tasks, including volumetric and fluid workflows. The release notes confirm that the operators are designed to support the new GPU fluid pipeline introduced with ZENITH.

CUDA modules distributed with tyFlow have also been updated. The package now includes machine learning models intended for fluid up-rez and compression. These models ship inside the CUDA module package together with a defined installation location described in the included documentation. The release raises the minimum supported CUDA version to 12.8. Users are instructed to ensure that GPU drivers are updated accordingly.

Updated CUDA modules

The updated CUDA modules are a central part of the release. The vendor states that the package now bundles machine learning models used for fluid up-rez and compression. Fluid upres workflows typically reconstruct higher resolution detail from a lower resolution simualtion. The release notes do not specify the training method, dataset, or inference process used by these models. No benchmarks or performance figures are provided.

The CUDA modules also now require installation in a specific location. Users are directed to the README documentation included with the CUDA module package for installation details. The vendor also updated the CUDA cub and thrust libraries used internally by tyFlow. According to the release notes, the update addresses rare CUDA crashes during Multifracture operations. (Multifracture is tyFlow’s system for procedural mesh fracturing used in destruction simulations.)

Twenty Inferno operators

The release introduces twenty new Inferno operators designed to work with the new GPU simulation capabilities. Inferno operators in tyFlow provide node based controls that modify simulation behaviour or generate simulation data. The addition of twenty operators suggests a significant expansion of the Inferno system.

New operators for general workflows

Outside the Inferno system, the release adds several new operators and modifiers for tyFlow workflows. A new Global operator has been added. The official documentation referenced in the release notes is required to understand its full functionality.

The update also introduces a MAXScript operator. MAXScript is the scripting language used inside 3ds Max. The operator presumably enables scripting access within tyFlow simulations, although the exact capabilities are not described in the release notes.

A new tyMeshBlend modifier has also been introduced. The modifier blends normals where meshes intersect. This behaviour is typically used to reduce shading artifacts where two meshes overlap or intersect.

Another addition is a new SDF shape mode for the PhysX Shape and PhysX Collision operators. SDF stands for signed distance field. According to the release notes, the new mode allows more accurate concave collisions.

Signed distance fields are commonly used to represent complex shapes in simulation because they encode the distance to the nearest surface point in volumetric form.

tyCache improvements

The release expands tyFlow’s caching capabilities. The tyCache modifier can now cache spline data. Previously, the system primarily cached particle and mesh data. The Export Particles operator now supports subframe export of tyCache data. Subframe data enables simulation playback at time steps smaller than a single frame. This is typically required for accurate motion blur in rendering workflows. The tyCache object also now displays PhysX bind connectivity.

Mesh and material improvements

Several modelling and mesh related updates are included in the release. The multifracture, tyBoolean and tyWeld modifiers now include UVW seam weld options. A new Merge mat IDs mode has been added to the tyMaterial modifier. The same option is also available for the tyMesher object. According to the release notes, the feature merges and concatenates material IDs across instanced objects and generates a compatible multi material with the new ID layout. This behaviour can simplify material management in procedural setups where multiple objects share or generate different ID sets.

UI and usability changes

The update includes multiple interface adjustments aimed at improving usability inside the tyFlow editor. Comboboxes, checkboxes and radio buttons now display non-default values in blue. Previously, this behaviour was limited to numeric spinner controls.

Large dropdown comboboxes now include a text entry field at the top of the list that allows users to search items using fuzzy matching. The release also introduces a Houdini-style value stepper dialog. Middle Mouse Clicking any spinner control opens a dialog that allows incremental changes across multiple orders of magnitude.

Export and procedural variation

The Export Particles operator now supports exporting ranges for tySwitcher indices and reseed values. According to the release notes, this allows permutations to be exported from the same operator during a single export operation. Exported object names and layers now also support symbol replacement variables such as $tySwitcherIndex and $tySeedIndex. These variables allow procedural naming during export operations.

OpenVDB update

The OpenVDB SDK used by tyFlow has been updated to version 13. OpenVDB is an open source library widely used in volumetric workflows. It provides sparse volumetric data structures for storing grids such as smoke, fire or fluid simulation volumes.

Practical implications

The most significant change in this release appears to be the introduction of the ZENITH CUDA fluid solver and the expansion of the Inferno operator set. However, the official release notes do not provide technical descriptions, performance data or architecture details for the solver. GPU fluid simulation inside particle frameworks can reduce iteration times when compared to CPU grid solvers. Whether this holds true for ZENITH cannot be determined yet – so it is time to have a good long playing session with Tyflow!

Users interested in adopting the new system will likely need to examine the updated CUDA modules and example scenes to evaluate real world behaviour. As always, new tools and innovations should be thoroughly tested before use in production.

// https://pro.tyflow.com/

The post tyFlow 2 adds CUDA fluid solver and 20 Infernos first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Sitni Sati is preparing the release of FumeFX 7.5 for 3ds Max, introducing NVIDIA CUDA acceleration for smoke and fire simulation. The developer reports a performance increase between two- and five-fold compared to CPU-based simulations.

The GPU acceleration targets volumetric fluid effects such as explosions, smoke and fire. It supports both simulation and real-time viewport preview. In official demonstrations, the feature ran on an NVIDIA RTX 4090 and produced detailed motion and shading.

No more memory crashes

A common limitation of GPU fluid solvers is restricted video memory. Sitni Sati claims that FumeFX 7.5’s GPU solver automatically falls back to CPU once GPU memory is exceeded. This prevents crashes and lets complex simulations complete without manual intervention. The hybrid approach allows artists to benefit from GPU speed while maintaining the stability of CPU computation. The developer also states that the GPU solver maintains visual detail and motion quality where other sparse fluid solvers may lose resolution. At press time, this claim has not been independently verified.

What remains to be clarified

As of the current beta, Sitni Sati has not published detailed release notes specifying which FumeFX features are fully CUDA-enabled. It is unclear whether all node types, caches, and modifiers run on GPU or whether some processes remain CPU-bound. Likewise, parity between GPU and CPU results, regarding noise behaviour, reproducibility, and memory consumption has not yet been confirmed by third-party testing.

Implications for production

GPU acceleration promises faster iteration for artists working with smoke, fire, and explosion setups, particularly on modern CUDA-based hardware. The automatic CPU fallback adds safety for heavy scenes that exceed GPU resources. Studios should nonetheless test the new GPU mode thoroughly within their pipelines before relying on it for client work, as simulation consistency and cache behaviour can vary across hardware configurations. FumeFX 7.5 remains in beta. Sitni Sati has not yet announced a release date or updated pricing.

The post FumeFX 7.5: Fire Meets GPU soon first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

JangaFX has released LiquiGen 1.0, its real‑time liquid simulation tool now deemed production‑ready. The software introduces substantial stability improvements along with new simulation features, export formats and rendering controls.

New physics and viscosity controls

LiquiGen 1.0 now simulates highly viscous liquids such as honey, oil or melted chocolate with physical behaviors like coiling and buckling handled via a PIC/FLIP solver supporting whitewater, spray, foam and bubbles. Viscosity and stickiness can now be adjusted per emitter.

Camera, materials and meshing upgrades

The update adds a more industry-standard camera control system—zoom‑to‑cursor, pan‑around, and animated camera import via Alt key and other shortcuts. A new material system offers realistic presets for water, plastics, metals and more. A choice of higher‑quality meshing supports morphological dilate/erode/open/close operations, along with SDF (signed distance field) and normals smoothing.

Expanded export and pipeline integration

LiquiGen now exports mesh flipbooks (single FBX sequences colour‑coded per frame), Vertex Animation Textures (VAT), Alembic caches, VDB velocity fields and rich rasterised passes including thickness, reflection and refraction. These formats target VFX pipelines, game engines and motion graphics workflows.

Workflow diagnostics and interface polish

The release introduces a Diagnostics Panel to visualise simulation domains, force and velocity fields, mesh vs particles, and imported SDFs for collider/emitters. A “Show SDF” toggle helps troubleshooting and voxel resolution choice. UI improvements include searchable dropdowns, copyable dialog messages, tooltips, timeline step‑back and a startup splash screen.

Stability and performance enhancements

Most critically, JangaFX now classifies LiquiGen as production‑ready, citing substantial gains in stability and performance—especially on smaller‑scale simulations. GPU requirements include NVIDIA GTX 1060 or AMD RX 580 and above. Windows 10+ and Linux are supported; macOS support is planned for version 1.1

Licensing and pricing tiers

Indie users (revenues under $1 million) can subscribe at $19.99/month and obtain a perpetual licence after 18 months, or buy a perpetual standalone licence for $299.99. Studio licences (up to $100 million revenue) cost $1,400 for node‑locked and $2,300 for floating licences. As always with new tools—even one now marked production‑ready—actual use in production should be tested and qualified before integration.

The post JangaFX unleashes LiquiGen 1.0: liquids meet production‑ready polish first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

NVIDIA has made a splash by releasing its renowned PhysX Flow engine as fully open source. This move marks a watershed moment for simulation in film production and postproduction workflows. The transition to an open source model is not merely a licensing change; it gives artists, technical directors, VFX supervisors, riggers, shadower enthusiasts, modellers, and even game developers an unprecedented opportunity to dive into the very code that powers next-generation fluid simulations.

The Technical Anatomy of PhysX Flow

The core of PhysX Flow is asystem tailored for high-performance fluid simulations, optimized to run on modern NVIDIA GPUs. Built to support real-time graphics and powered by advanced algorithms specifically designed for grid- or particle-based fluid dynamics (numerical methods enabling accurate simulation of complex fluid behavior), the engine lends itself well to heavy-duty tasks in both feature films and video games. NVIDIA’s choice to open source this robust engine was driven by the need to foster innovation and collaboration in the digital production arena. With its modular architecture, PhysX Flow allows VFX artists and simulation engineers to integrate or adapt the software into bespoke pipelines, ensuring that the engine can be finely tuned for tasks ranging from intricate water simulations for blockbuster visual effects to large-scale interactive simulations in the gaming world.

The open source release means that professionals now have full access to the underlying algorithms that manage the simulation of thousands of fluid particles in real time. The engine’s capacity to handle high-resolution scenarios with minimal performance overhead is achieved through rigorous optimization on NVIDIA GPU hardware, making it an attractive tool for those who demand both speed and precision. For those who were previously confined to proprietary black boxes, this release opens a window into how simulation stability and performance meet cutting-edge technological sophistication. While many may joke that “if you can’t solve it, at least make it open source,” NVIDIA’s decision ensures that even the quirkiest error can be debugged by a global community of experts, not just an in-house team.

The code is now available for scrutiny on NVIDIA’s GitHub repository, and while the engine itself comes free of charge (thus making price discussions moot), the true cost is measured in the time and effort required to master it. For many studios and freelancers alike, the potential return on investment is high—provided that all new modifications are rigorously validated in the context of actual project requirements. In other words, while it’s tempting to get swept away in the waves of open source enthusiasm, as always, Fact Check: any innovation should be checked before being used in current projects.

The post PhysX Goes Open: Fluid Dynamics Unleashed first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The fire is lit—again. Version 6.7 of FumeFX for 3ds Max brings practical updates for visual effects artists working with fluid dynamics in postproduction, real-time graphics, or game cinematics. Known for its specialization in fire, smoke, and explosion simulation, this version emphasizes workflow efficiency, compatibility, and—yes—flames. As always: test before committing it to production, because new features can spark both joy and bugs.

New Fire & Explosion Presets

Version 6.7 introduces fire and explosion simulation presets designed to streamline setup time and reduce parameter guesswork. These presets allow artists to quickly initiate realistic simulations, focusing effort on creative choices instead of numeric tweaking.

Arnold Shader Updated for 3ds Max 2024

Arnold users can breathe easy—FumeFX’s Arnold shader is now compatible with 3ds Max 2024. No manual workaround needed to maintain your rendering pipeline if you’ve updated your environment.

Thinkbox Stoke MX Support Returns

Back by demand: support for Thinkbox Stoke MX, a tool enabling the manipulation of simulation data via particle reflow techniques. Stoke’s utility in retiming, blending, and customizing fluid sims is once again accessible within the FumeFX pipeline, offering TDs and simulation artists greater control over cache data.

Technical Snapshot

FumeFX uses a highly optimized simulation core with GPU-accelerated rendering for viewport previews and final output. It supports simulations involving fire, smoke, explosions, and other gaseous phenomena. The plugin integrates seamlessly into 3ds Max, supporting Arnold, V-Ray, and mental ray for final rendering workflows.

Licensing & Pricing

A perpetual license for FumeFX 6.7 is available for $695, with volume licensing options for studios. Pricing and purchase details can be found via Toolfarm or directly through Afterworks.

The post FumeFX 6.7 for 3ds Max: Stoke Up Your Sims first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Autodesk has released version 2.11 of its procedural toolset Bifrost for Maya, introducing a series of new features aimed at improving the workflow of Artists in visual effects (VFX), animation, and game development. The updated version builds on the foundation of Bifrost’s node-based system, focusing on stability and integration with Maya’s core functionalities.

Key highlights of Bifrost for Maya 2.11 include enhanced support for USD (Universal Scene Description), which is becoming a standard across multiple industries. The update ensures smoother interaction between Maya’s native scene format and USD, making it easier for Artists to integrate Bifrost simulations into larger, multi-software pipelines.

A notable addition in 2.11 is the fluid simulation framework update, which optimizes existing setups. Users can expect more reliable results with large-scale simulations, such as water, smoke, or fire. Additionally, the revamped material point method (MPM) solver improves the simulation of granular materials like sand or snow. According to Autodesk’s documentation, this method is designed to achieve better physical accuracy in scenes where detail is crucial.

Bifrost’s graph-based workflow sees further enhancements as well, including new nodes and a streamlined interface. The update reduces the number of repetitive tasks by allowing for faster iteration cycles, saving time when working on complex procedural effects. Autodesk emphasizes that these updates prioritize stability, an important consideration for Artists working under tight deadlines.

The release also introduces a new scattering framework. This tool enables Artists to distribute objects procedurally across a scene while maintaining control over placement and variation. The framework works seamlessly with other Maya features, allowing for the generation of natural-looking environments.

Bifrost 2.11 is available as part of Maya’s subscription model, with pricing starting at $1,700 per year. Autodesk offers a 30-day free trial, and updates are included at no extra cost for existing subscribers.

Before integrating any new feature into a production pipeline, Users should thoroughly test its compatibility with existing workflows. Autodesk’s official documentation provides detailed guidelines and best practices for setting up Bifrost in Maya 2.11. For more information and a full breakdown of features, visit the Autodesk product page.

The post Autodesk Launches Bifrost for Maya 2.11 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

In the course of the “Elemental Week” JangaFX has presented updates – and they look interesting. Here is the keynote:

EmberGen 1.2: Movable simulation domains and mouse recording

Version 1.2 of EmberGen introduces movable simulation domains that allow the simulation volume to be keyframed or bound to objects and characters. An example shows a fire simulation on a character rig, which is supported by the ability to parent emitters to bones. Another new feature is mouse recording. This allows quick test animations by moving an emitter in the viewport, with the results being recorded in the timeline. This function significantly improves the workflow.

EmberGen 1.2 also brings several workflow improvements and bug fixes. The Curve Editor has been reworked and the ability to snap to individual frames in the timeline has been added. The software continues to support the export of data in OpenVDB and Alembic formats and can output rendered flipbook image sequences for game engines such as Unity and Unreal Engine 5.

The minimum requirements are low: an NVIDIA GeForce GTX 1060 or an AMD equivalent is sufficient. EmberGen 1.2 is compatible with Windows 10 and Linux. Prices start at 19.99 USD per month for indie subscriptions, with a perpetual licence after 18 months. More information can be found on the JangaFX website and in the product documentation.

LiquiGen 0.3: New functions for fluid simulations

LiquiGen, the real-time fluid simulation software from JangaFX, is now available in version 0.3 as a public alpha. This version brings a new PIC/FLIP solver that enables more realistic and detailed simulations.

A significant new feature is the Whitewater system, which supports the simulation of spray, foam and bubbles. These particles can be exported separately from the main body of the fluid, allowing targeted control and application of forces. New view options show wave crests or bubbles where whitewater particles are created. Support for surface tension is another important new feature that improves the simulation of liquid splashes. A revised rasterisation renderer provides a practical alternative to the path tracer for production work and now supports refraction and transmission colour.

The overall performance and quality of the simulations have been improved, resulting in an increased maximum particle count and improved meshing and volume preservation. New force nodes such as line force and toroidal force as well as a revised turbulence node are also included. LiquiGen 0.3 is compatible with Windows 10 and Linux and supports NVIDIA and AMD GPUs. Prices start at 19.99 USD per month for indie subscriptions. Further information can be found on the manufacturer’s website and in the product documentation.

GeoGen 0.3: New beta version for terrain artists

GeoGen 0.3, the real-time terrain generation tool from JangaFX, is now available as a public beta. This version offers spline-based terrain control, which makes it possible to define specific features such as mountain ranges, rivers or roads. These splines can branch out and form complex networks that update the terrain in real time. A new directional colour blur system generates surface colour gradients and provides options for terrain detailing, such as layering and blending procedural noise types. Subgraphs support merging an entire node graph into a single node, which helps keep large projects organised.

GeoGen’s key nodes have received updates, especially the Rock and Splatter nodes. Gizmo controls for key nodes make it easier to edit terrain in the viewport. The render engine update increases the level of detail in the preview renderings. GeoGen 0.3 runs on Windows 10 and Linux and supports NVIDIA and AMD GPUs. Pricing starts at 9.99 USD per month for indie subscriptions. For more information, visit the JangaFX website.

Links

GeoGen on JangaFX

Manufacturer page of EmberGen

Documentation of EmberGen

Manufacturer page of LiquiGen

Documentation of LiquiGen

GeoGen Beta Announcement

The post Ember-, Liquid- and Geo-Gen now available! first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Chris Wojtan and his group are researchers at ISTA – the Institute of Science and Technology Austria
(ista.ac.at), and they deploy and develop techniques from physics, geometry, and computer science to create efficient simulations and detailed computer animations. Chris has been at ISTA since 2011, after getting a Ph.D. from the Georgia Institute of Technology in Atlanta. And you can see the publications and the rest of the group – as well as current and upcoming projects at bit.ly/ista_wojtan

DP: After all we have seen in cinemas over the years, you would think that water simulation would have been perfected by now?

Chris Wojtan: Humans have known about water for tens of thousands of years, and they only started really understanding how it worked in the 1800s, when physicists Navier and Stokes wrote down their famous equations explaining how fluids flow. Although these equations are easy to write down, we haven’t been able to solve them in the past two hundred years. Engineers and physicists have been trying very hard! In the year 2000, the Clay Mathematics Institute made it one of the “Millennium Prize Problems” just to find out whether a solution to these equations is even proven to “exist”… that’s how far we are away from really understanding how fluid flows. Since “perfecting” water animation really boils down to perfectly recreating its motion in any scenario, a “perfect” animation means solving one of the most infamously difficult problems in the history of mathematics.

We are constantly working on this problem, and trying to improve upon the state of the art every day. This year’s work makes things better by combining two things that used to work great before but never worked well together: Specifically, we already know how to simulate shallow water, like flooding onto a beach and sloshing around; we also know how to simulate tiny waves rippling in deep water, creating beautiful interference patterns like the ones you see behind a boat or a duck swimming in a pond.

Up until now, it was surprisingly difficult to put both of these together in the same animation, like having a boat create a wake that splashes up onto the beach. We did this by unifying different solutions of the Navier-Stokes equations, to make sure they work well together in a way that physically makes sense.

DP: What are the relevant influences on wave formations?

Chris Wojtan: Water waves are extremely complicated, so we have to simplify the physics just to get a handle on the problem. The main forces that influence water waves are:

– Gravity – the entire column of water is constantly being shoved downward

– Surface Tension – the surface of the water wants to stay smooth, so any ripples get pulled hard upward or downward towards a flatter surface

– Fluid Pressure – fluid is extremely good at resisting compression. Any amount of pushing on it will cause water to spill out into other directions. A wave pushing downward causes fluid to flow around sideways.

– Viscosity – internal friction causes the wave to resist sloshing about too much.

One of the reasons that water waves are not so simple to explain is because they are “dispersive”. The speed that a wave travels depends on its wavelength. Huge kilometre-scale waves like tsunamis are driven strongly by gravity and travel really fast; millimetre-scale waves are driven strongly by surface tension forces and also travel extremely fast (blink and you will miss them); the centimetre-scale waves in between aren’t really pushed that hard and actually travel slowest. The result is that you have all sorts of waves of different scales all travelling at different speeds. It is a mess to understand, let alone writing code in a computer to perfectly recreate their behaviour. However, this behaviour is responsible for extraordinary beauty. Pay attention to the ripples you see in a pond, and you will see that all the ripples rip apart into different wavelengths, automatically sorting themselves out into longer or shorter waves in front or back.

DP: And jumping from 2D to 3D and back makes it easier?

Chris Wojtan: Yes! It is a pretty useful technique in maths and computing to try to take a complicated problem and make it as simple as possible before solving it. Some people call it a “change of variables” or use fancy words like “reduced degrees of freedom”. The basic idea is, if I somehow knew that a super complicated problem could be easily transformed into a simple one that I already know how to solve, then I definitely want to solve that simple one instead of the hard one. Transforming a 3D fluid problem into a 2D surface prob-
lem makes it simpler to solve in a computer, in the same way that solving 10×10=100 math problems is easier than solving 10×10×10=1000 math problems. The computer loves it when we do this, because then it can take a break and doesn’t have to work so hard.

DP: Why hasn’t this been done before?

Chris Wojtan: You are right that so many people have looked at this problem before. Fluid flow is so ubiquitous and important to so many people in different ways, but water surface ripples are somewhat of a niche problem in the big picture.

Recent breakthroughs in computer hardware make it so that some algorithms suddenly become more useful than others. Although people knew about fluid equations for hundreds of years, we only had the computer power to simulate waves efficiently for the past few decades or so. The state-of-the-art computer methods for shallow water equations came even later, and super fancy exponential integrators for surface ripples came even later after that. Each of these ideas are somewhat different from each other and are honestly somewhat intimidating to people trying to understand them. I believe the main reason we haven’t seen this idea before is because it combines so many different ideas that are hard to keep straight in your head all at once, and each of the ideas are relatively new in the grand scheme of things.

On the other hand, it is somewhat surprising that we haven’t seen progress here earlier. Stefan Jeschke (first author)’s “Eureka” moment came from just playing around with the state-of-the-art tools and realising that they failed so obviously when combining them together. The shallow water simulators simply do not speak the same language as the ripple simulators, and they don’t work well if you try to combine them. Our idea was to force them to speak a common language, which required some trickery and lots of trial and error.

DP: So your new way of simulating waves by “splitting” the equations and recombining them works in all types of water?

Chris Wojtan: Definitely not! We had to put a lot of constraints on the problem in order to get an answer that is fast to compute. For example, we have to assume that water resists compression so much that it is essentially “impossible” to compress it. We also had to assume that waves could only go up and down, and not tumble over themselves or rip apart into droplets and bubbles. These are common ways for physicists and mathematicians to cheat around hard problems, and we did the best we could to use these ideas to make the problem as simple as possible to solve. So, the only reason that we can compute it so quickly is because we were able to simplify the maths, which prevents it from working in all possible water scenarios.

DP: With simulations in CGI, different materials and situations can be used with identical “simulation approaches” – how flexible is your new model and what are its limitations?

Chris Wojtan: Our research covers all sorts of interesting situations, with some methods more general and some more specific. This one is very specific and uses as many constraints as we could to make it fast to compute. This one only works for water waves and is not a general simulation approach. It can definitely be combined with other methods, though.

DP: Walk us through the steps, what happens to the “fluid particles”?

Chris Wojtan: In the real world, the fluid particles behave differently depending on the water depth. Far away from the beach in very deep water, the fluid particles simply bob around in gentle circles. Waves pass through them, but the water particles themselves just move lazily around in a circle – as their neighbour goes up, they get pulled up along with it; as the neighbour falls back down again, they get pulled down with it.

In shallow water, there isn’t as much room for the fluid particles to plunge up and down again. If they try to go downward, they either smack into the floor, or they smack into one of their neighbours who can’t move out of the way because the sea floor is in the way. These fluid particles can’t go in simple circles anymore, and instead they generally tend to move away from each other by sliding left and right.

It turns out that both of these ideas are going on everywhere in the water, but at very different scales. If you see a very short wave compared to the water depth (like a gentle ripple in a pond, or a ship wake in the deep ocean) then the fluid particles move in lazy circles. On the other hand, if you see a very long wave compared to the water depth (like a tsunami in the ocean, or a raindrop in a puddle) then they will slosh side-to-side. Both of these can work together at the same time. Long waves move side to side, while short ones bob up and down. We combine both of these ideas together to get a simple wave solver that combines some of the best-known ideas for simulating each wave type on its own.

DP: And with something so abstract, how do you test it?

Chris Wojtan: This is a really important question that we have to critically ask ourselves on every research project. The simplest thing to do is just try it out and see if it makes any sense. Beyond that, we try to see if the simulation acts the way we would expect it to in as many different scenarios that we can dream up. This is usually some mathematical concept that also makes sense in the real world. Some examples:

– Conservation of mass: Does the water disappear for no reason or is water created out of nowhere like some leaky faucet?

– Conservation of energy: Do the waves settle down naturally? Do the waves keep feeding back on themselves, getting stronger and scarier?

– Dispersion: Do waves travel at the right speed? Can we recreate the nice patterns we see behind a moving boat?

We also apply these ideas to the computation: Is it running as fast and using as much memory as we expect? Or is something surprising happening?

DP: Simulation testing is not just insoftware…

Chris Wojtan: We do not have a fancy laboratory where we can run controlled experiments, so we only compared visually to footage that we took from nature, or from other researchers around the world who did the experiments already. In this case, the rules for wave energy and wave speeds are well known, so we were lucky that we didn’t have to do our own real-world experiments.

DP: How long do you think it will take for these new features to be implemented in mainstream software packages such as Blender, Maya Bifrost or Houdini?

Chris Wojtan: This is always a tricky question, because the answer depends on a number of factors that are difficult to control. Sometimes the code that makes it into these software packages is related to social connections (e.g., if we personally know one of the developers, or if a paper author did an internship at that software company), or risk factors (e.g., the code is easy to implement, so it was faster for the stressed-out software engineer to use that one instead of a fancier algorithm that might be harder to code), or communication (how well we explained and promoted our ideas strongly influences the perceived risk), or legal concerns. Our algorithm builds upon state-of-the-art algorithms for two other problems (shallow water equations and deep water waves), so adding our method to a software package will be a no-brainer if those other two methods are already in there. However, if not, it will be a lot more commitment for a software engineer. We also note that our work is still “research” – the biggest breakthrough is a mathematical insight instead of a technical one. Consequently, the code is not optimised, and the new part that
combines things together so nicely is a lot slower and sloppier than it could be if a software engineer really sat down and though about it for a while. That could also make an engineer wait to integrate it into their code until somebody else works out that last bit.

DP: Could you talk about the file types and parameters you used for testing?

Chris Wojtan: The first author responsible for the work Stefan Jeschke (formerly at NVIDIA, currently at ISTA) made everything GPU friendly. The input files are all image files; the images model the water depth
and height of the terrain, as well as the height and velocity of the water at each point on a grid. The parameters were mostly different image resolutions (how complex is the scene) and time step sizes (how fast should it run), as well as the new parameter that we introduced, which is responsible for categorising water waves into deep or shallow water. We targeted real-time simulation (i.e. video games) in our paper, so the image resolution is only 512×512, with simulations running at 60fps. Bigger and badder simulations also work if you want to crank up the image resolution a whole lot, but you might have to wait a bit longer to get
your animation. We rendered everything in real-time on the GPU, using real-time reflection and environment maps and evaluating surface shaders at every pixel of the scene.

DP: What would be the impact of shaders and lights and so on for this type of simulation?

Chris Wojtan: Surface shaders have a strong effect on the appearance of water; you can see this by looking at a body of water at noon compared to sunset. The grazing angle of the light really brings out lots of tiny variations in surface normals, and make the surface look more detailed. Our simulation method is entirely focused on simulating those tiny, tiny details on the water surface, so we like to use grazing lights to make the small details more apparent. A surface with matte shading and no specular highlights will make it difficult to see small surface ripples, essentially wasting the power of our method.

We make great use of per-pixel shaders to quickly simulate the waves on the GPU, move the wave heights into the correct position, and compute their surface normals.

DP: You already worked with Stefan Jeschke from Nividia to get an implementation for the demo – couldn’t that be translated?

Chris Wojtan: Stefan is always working hard on wave simulation tools and he is probably the world expert on wave animation at this point. He is no longer working at NVIDIA and I’m not sure how much of the ideas and code from previous projects he can publish. But I’ll tell him your suggestion and maybe he will start putting together a dedicated toolkit!

DP: You and your group are based near Vienna, Austria – a famously landlocked country. Why is that?

Chris Wojtan: The reason Austria is landlocked is due to a number of geological factors outside of my control. I blame the dinosaurs, various asteroids, and those finicky tectonic plates. Austria actually has “way” more water than where I grew up in the midwest United States. There are so many beautiful rivers and streams here that regularly hypnotise me when I should be doing something else.

The Institute of Science and Technology Austria, ISTA, is an amazing place to work, because it is so supportive of basic research. We are strongly encouraged to get deep into problems, ask fundamental questions, and try to make big picture insights that might not have an immediate effect but
impact longer term future trends in the field. I contrast this with more applied research towards developing projects or setting short-term goals, because we are free to take big risks without fear of losing our jobs or status. Thankfully, the SIGGRAPH community also appreciates weird new approaches to old problems, so there is a happy synergy between my place of work (ISTA) and the top place to publish our work (SIGGRAPH).

Incidentally, my research group is always looking to recruit new researchers with VFX experience and/or a drive to solve hard problems, so I invite your readers to please get in touch if they are interested in joining us.

DP: What are you working on next?

Chris Wojtan: So many things! Mostly in computer graphics, but we are starting to branch out into fields of biology and mathematics. Here is a short list of projects in progress:
– really big-scale rigid body simulations and fast simulations of granular materials
– fast and robust triangle mesh tools for simulating really big foams and fluids
– a super efficient mathematical theory to optimize shapes for 3D printing
– general tools for converting small-scale simulations into large-scale approximations, like learning from yarn-level cloth simulations to simulate entire large-scale garments quickly
– simulations of biological cells to try to understand how they evolved into their current shapes
– better understanding the mathematical foundations of some numerical algorithms (like “symplectic integrators”)

And, of course, new methods for efficient and super-detailed waves on water and
other deforming surfaces. We have an evergrowing list of all of our projects at bit.ly/ista_vc
and an overview in German at bit.ly/ista_wojtan_current

The post The next generation of water simulation first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The protagonist, Ember, is a tough, quick-witted and fiery young woman, whose friendship with a
fun, sappy, go-with-the-flow guy named Wade sets up shenanigans with the world they live in – the movie was directed by Peter Sohn (“The Good Dinosaur”), and he had help – among others – by Sanjay Bakshi as Visual Effects Supervisor and TD Markus Kranzler. And with the latter two, we had a sit down!

DP: Elemental looks like there is loads of CG-work in every scene – to get a reference, how big was your team?
Sanjay Bakshi: That changes throughout the production – and how many there were at the peak of production I can‘t say – hundreds across all kinds of department, and (this is just my impression) more then at the usual Pixar movies, because of the scope of the work.

DP: When you first saw the characters and script: What were your preparations, since simulation would be characters (With fire and water as protagonists), the environment would be either drowning or be on fire a lot of the time, and let‘s not even talk about water vapour for people …?
Sanjay Bakshi: Yeah, there is definitely “that” moment at the start – but we knew practically from the start how to change our “regular” pipeline – and that we would have to invest, so that not every shot would be “linear” though the classic pipeline. For example: Not every shot does have to go to an FX artist to work on – because that would be every shot of the movie.
We created technology, that animation artists could do some FX as well – where Ember isn‘t doing a lot besides subtle motion, an animator could do the work, and the fire simulation would happen automatically and behave in a predictable way, so that we would render it out and evaluate, “Oh, this one actually is fine, it can go through to the next department” or, “She does some non-standard stuff there, let‘s give it to an FX artist”. So, we built an automation for the fire simulation and the water simulation that allowed some percentage of the shots to go through without having a lot of FX, while still being made up of FX.

DP: I assume the simulation was done in Houdini?
Sanjay Bakshi: Yeah, Houdini was the backbone for our VFX pipeline. For fluid sims we use a lot of custom work – that‘s the nice thing about Houdini, you can customize so much and built your own tools inside of it.
For the flames, we used “Neural style transfer” – basically machine learning to stylize the flames. Stylized flames because when simulation runs, it‘s a realistic fire. And the Style transfer “organized” the flames, so to speak, into more stylistic patterns, that are simpler and more pleasing for characters – so that was all custom work. And then we developed the “HEXport” – the Houdini Export – when an animator checks in the shot, the simulation automatically runs.

DP: How do you do automatic simulation?
Sanjay Bakshi: Once we got the visual look for Ember, we asked animation to do a bunch of motion tests for us – like walking slowly, walking fast, jumping, sitting down, the generic stuff. Then we ran the simulations for those tests and saw where it behaved, where it didn‘t, and then tuned the parameters of the simulation – and in many instanced, we declared motions a “special case”. For example, when she is moving fast, we dialled down how many tear-offs occur. It was a bunch of hand tuning and a bunch of iteration, to get the parameter space in a place where standard motion would behave nicely.

DP: And with that development for Elemental, do you think of using those style transfers for upcoming movies to save time?
Sanjay Bakshi: In this case, it didn‘t save any time – we‘re still running the simulation and we‘re organizing it, just using these ML algorithms. It actually costs a lot if we use GPUs for it and it increased the amount
of time it takes for us to get our renders back. We didn‘t look at it as an optimization technique, but as a tool to get the look we needed.
But, speaking more broadly, we have other machine learning tools of in our pipeline for denoising and path tracing. So, we‘re always looking for ways that new algorithms and new developments can help us. I‘m sure considering the amount of activity in that space, that there will be other places we‘ll find tedious work to “offload”. There‘s no doubt that generative AI will be used to make something.

DP: Let‘s get to the Elementals itself: How did that work? Are there personal favourites?
Sanjay Bakshi: The fire was really hard to figure out and took a lot of time. And water as well – we spent as much time on Wade (The “Water” protagonist) as on Ember.
We spent a lot of time to on Wade when he was speaking – to create ripples on his face for every kind of mouth shape he made. But those ripples would capture reflections from the environment. And adding to that, we have a lot of bubbles going on. And then on his top of his head, we had a waterfall wave. Yeah, Wade wasn‘t easy.

Initially we were kind of seduced by all of those techniques. And Peter (Sohn) was really loving it because he really wanted Wade to feel water-y. We had all of those things in it, and then we thought we were done and we went to animation and they animated the first scene and they were really concerned.
We couldn‘t see those subtle acting performances we‘re doing, because there‘s so much going on inside of Wade that was detracting from the performance (in terms of the reflections and the bubbles). So even though we had spent as much time on Amber and Wade, we actually had to stop production for a minute and dial back some of those things.
They‘re all still there, but for balance, we had to dial them back. An example: You might notice that the bubbles aren‘t really in the centre Wade‘s face. They‘re more on the sides and in his body. The number of ripples that get produced is really subtle now. And the reflections are really curated to be in specific parts of his body. So, in the end, I think water was more complicated. The other thing is that water is hard to light and looks so different in different lighting en­vironments – it‘s inherently invisible. Fire always looks the same – it‘s emissive, so that was another for our lighting team: Amber always looked great and Wade was very challenging to make look appealing.
On the other end, we really needed it to be “correct” in a way – there is good story reasons for the effects, like when fire characters get close to water characters, the water characters react, they start to boil, they start to steam up. And it‘s trying to show that these elements don‘t get along for physical reasons. Ember doesn‘t fit into this world and she has an effect on them that makes them feel uncomfortable. And that‘s why she wants to stay in fire town and not explore as much. So it was integral to the story that this was done in a simulated way.

DP: Did you use procedural modelling – like with Zootopia and the CityEngine in Elemental?
Sanjay Bakshi: Yeah, we used procedural building for the artwork of the city, when
we were dialling in the look and feel of the districts, not so much in the final frames.

DP: Like all the previous Pixar Movies, there is stuff happening in the background – I always imagined that gets added by some artists on a Friday afternoon, because it is funny. How do you put in those jokes?
Sanjay Bakshi: Well, that depends – usually those ideas come from all over the team – everyone who thinks they have an idea approaches and asks “Should I put that in?” and that gets curated. But our crowds team has a little bit more liberty. They‘re doing a lot of stuff in the background and sometimes they don‘t ask. Sometimes they‘ll do something just to make their jobs more interesting and will get away with it, and so it‘ll go through and then they‘ll tell us “Oh, we added that thing back there”.

DP: Hallo Markus! Woran hast du bei Elemental gearbeitet?
Markus Kranzler: Dieses Mal war ich hauptsächlich an den Wasser- und Luftcharakteren beteiligt. Und diesmal war es auch eine sehr enge Zusammenarbeit mit der FX-­Abteilung, denn letztendlich sind die Charaktere ja Effekte. Das heißt, ein Teil ihres Wissens, wie sich Volumes und Fluids verhalten, wurde direkt bei uns angewendet. Das war diesmal ein Prozess, wo sehr viele Leute und sehr viele Parteien involviert waren und zusammengearbeitet haben. Das macht es natürlich interessant – wer will schon immer das Gleiche machen?

DP: Die Pipeline wurde also einfach komplett durcheinandergewirbelt?
Markus Kranzler: Im Prinzip ja – natürlich haben wir nun sehr belastbare Pipes, vor allem weil wir auf USD gesetzt haben – aber Optimierungsbedarf gibt es immer, vor allem wenn man mit solchen Datenmengen arbeitet. Die Zeitverzögerung zwischen „Ich habe die Charaktergeometrie“ und „Ich kann es zum Rendern schicken“ war doch recht … groß. ziemlich groß. Und es gab einige Reifen, durch die man springen musste – einige der Tools sind erst entstanden, als wir sie brauchten. Dementsprechend gab es am
Ende der Produktion einige Stellen, an denen man es auch anders hätte machen können. Aber jetzt wissen wir, was wir bei den nächsten Filmen streamlinen können!

DP: Die Charaktere – vor allem Ember, die Feuer-Protagonistin – tragen eine Art Kettenhemd. Da darunter aber alles „Simulation“ ist, wie bekommt man das im Shading sauber hin?
Markus Kranzler: Normalerweise wäre das einfach eine Surface Map gewesen – mit Transparenz und so weiter hätte man das über die Shader „nachgebaut“. Da aber darunter etwas passiert, mussten wir die einzelnen Kettenhemdringe tatsächlich als Geometrie aufbauen und shaden. Also Instanzen in Houdini, in unserem Fall.

DP: Die Szenen sind also extrem klein, übersichtlich und einfach zu handhaben?
Markus Kranzler: (lacht) Ja, natürlich. Bei Elemental waren die generierten Daten sogar ein neuer Größenrekord für Pixar-Produktionen.

DP: Wenn es also um Geometrie und nicht um „Solid Surface“ geht, muss man dann auch für das Shading animieren? Wenn die Figuren atmen, ändert sich ja die Lichtemission?
Markus Kranzler: Da haben wir tatsächlich die Kollegen aus dem Rigging unterstützt und für bestimmte Signale Parameter in das Rigging eingebaut. Diese Signale konnten die Animatoren dann steuern und wir haben im Shading dieses Signal ausgelesen. Bei Ember ist das sehr offensichtlich – sie ändert ihre Farbe, wenn sie wütend wird. Und das ist ein Parameter, der im Rig gesteuert wird, und so bekommen die Animatoren ein visuelles Feedback, und wir haben ein Signal, das wir auslesen, in diesem Fall die Fuel Source der Feuersimulation.

DP: Aber wenn die Feuermenge variabel ist, wie kontrolliert ihr das über die Zeit?
Markus Kranzler: Das kann man sich vorstellen wie Compositing in 3D – also wir haben die Geometrie modelliert und animiert, darauf aufbauend die Simulation in Houdini, aus der wir verschiedene Elemente extrahieren und diese separat behandeln. Also, wie viel Einfluss hat dieser Arm auf die Gesamtmenge der Elemente zum Beispiel. Wobei wir da – dank der Signale im Rig – an manchen Stellen auch schon vorher eingegriffen haben, bevor es ein richtiges Volumen war. Das war notwendig, um zum Beispiel bei Feuer die Outlines, also den roten Rand um die Grenzen des Characters, herauszuarbeiten. Also wirklich so, wie man es aus dem 2D-Compositing kennt: Bestimmte Signale werden in ihren Ebenen verändert.

DP: Und wie habt ihr das gemacht?
Markus Kranzler: Das war ein riesiges Knotennetz in Houdini und hat pro Bild Stunden gedauert. Ach ja, wir haben die Daten für die Charaktere pro Bild generiert, nicht in Sequenzen.

DP: Man sollte meinen, dass das Gebiet ideal für maschinelles Lernen ist …
Markus Kranzler: Ja, punktuell setzen wir das schon ein – den Denoiser in Renderman zum Beispiel. Aber auf der Filmseite wird es immer auf das einzelne Projekt ankommen – die Neural Style Transfers zum Beispiel hängen davon ab, wie stilisiert der einzelne Film ist. Aber bei Pixar ist das nur ein weiteres Tool in der Kiste, das wir benutzen, wenn wir es brauchen – aber im Moment sehe ich keinen Druck, Projekte zu starten, die mehr R&D darauf verwenden.

DP: Und wie viel Zeit hat euch das bei Elemental gespart?
Markus Kranzler: Wir hatten schon einige Iterationen. Der Vorteil war, dass wir eine gewisse Technologie von Disney Research bekommen haben und dementsprechend eine solide Basis hatten, auf der wir experimentieren konnten und mit der wir die Styles entwickelt haben. Bei Elemtal hatten wir natürlich eine große Auswahl, was wir dem Algorithmus als Input geben, aber es hat eine Weile gedauert, bis wir die richtige Balance zwischen stilisiert und realistisch gefunden haben, und wir haben oft mit Pete Sohn zusammengesessen, bis es „richtig“ aussah.

The post Elementary! first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

In nuce: The software developer Chaos has released the latest version of its fluid simulation plug-in Phoenix. This is according to an announcement published yesterday, 19 January 2023, on cgpress.org. Version 5 of Phoenix adds new features such as support for V-Ray’s CPU Interactive Production Rendering and new controls in the particle shader’s fog mode.

In toto: Below are some of the most important new features of Phoenix 5.

• Support for the CPU IPR (Interactive Production Rendering) of the V-Ray renderer
• Deform volumes with modifiers: This allows selected simulators to be bent, distorted, tapered, twisted, merged or rotated (in the video at the end of this news item, 3D artist Yane Markulev demonstrates how to tweak modifiers to get different looks).
• Fog mode of the particle shader: This contains control elements that can be used to control absorption colour and phase function.
• New support in the standalone simulator: Time bend simulation and animations are now also supported.
• Detailed streamline preview: This predicts how forces will affect a simulation – even before it is run (again, it is Yane Markulev in a video at the end of this news item who expounds on the expert handling of the streamline preview).
• Other new features: Simulators now load faster, the rollout layout is customisable and the user interface has been optimised.

Click further: To Phoenix 5 on chaos.com. On 22 November 2022 , Digital Production reported on a two-part guide in which the Chaos team lead explained how to create fire, smoke and liquid simulations in Phoenix.

Source: cgpress.org ( message from CGPress Staff)

Chaos Phoenix – Deforming fire and liquid simulators

Chaos Phoenix – Using Streamlines to visualise forces and create effects

The post Latest version of the liquid simulation plug-in Phoenix! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: The Chaos Group has published a two-part guide aimed at beginners working with the Phoenix fluid simulation software. Both parts were published on 25 October this year. The author is Cory Holm, 3D Artist & Video Production Team Lead at Chaos Group. The Phoenix software is available for 3ds Max and Maya.

In toto: Below are links and summaries of the two guides.

• The complete guide to Chaos Phoenix, Part 1 – Getting to know dynamics simulation: The first part is dedicated to simulation; fire, smoke and fluid simulations; emitters & sources; viewport preview; and rendering.
• The complete guide to Chaos Phoenix, Part 2 – Under the hood: The second part offers insights into how to provide simulations with suitable shading and shaping. Part two is divided into: Grid Channels & Ranges; Particles, Particle Channels & Ranges; Particle Shaders; and Forces & Textures.

Clicked further: On 8 June this year , Digital Production reported on the release of Phoenix 5.0 – this was accompanied by a uniform licence, more control when moving objects and a stand-alone Node Viewer.

The post Get started with Phoenix thanks to this two-part guide! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: Cebas Visual Technology has released finalFluid – a new simulation software for 3ds Max that can be used to visualise fire, smoke, dust or clouds (see the demonstration in the video below). This means that finalFluid has now outgrown the beta phase and is being made available as a commercial version for the first time. Cebas Visual Technology is a privately owned software company based in Canada, dedicated to developing software that enables visual effects artists to achieve physical accuracy.

In toto: A prerequisite for using finalFluid is a renderer that supports the OpenVDB format; for example, Cebas Visual Technology’s in-house finalRender supports OpenVDB (last reported on by Digital Production on 1 November 2017 ).According to developer.nvidia.com , OpenVDB is a data structure standard and toolset that can be used to edit volumetric effects. Everything else you need to know about OpenVDB can be foundat openvdb.org. FinalFluid is compatible with 3ds Max 2021 and upwards. According to cgchannel.com, an Nvidia graphics card is required to use finalFluid. The minimum requirement is a DirectX12-compatible GeForce GTX card with 4 Gb Vram. FinalFluid is offered for 395 US dollars per month.

Click further: All further information on FinalFluid is available at cebas.com . The prices for FinalFluid are also listed on cebas.com.

finalFluid Realtime Fire & Smoke for 3ds Max

The post Simulationssoftware finalFluid als Full Release! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: VFX software developer Sitni Sati has announced that FumeFX 6 for 3ds Max has entered the beta phase. The highlight: FumeFX 6 Beta is now available to users free of charge – or as a fully functional, commercial licence. The description of the presentation video on YouTube states that FumFX 6 Beta is offered equally for learning purposes, non-commercial projects and blockbuster film projects of large studios – without any costs incurred during the current beta phase. The free beta offer is valid up to and including 21 December 2022 and includes a node-based system that affects, among other things – but not exclusively: Particles, Ropes, Rigid Body Dynamics, Soft Body Dynamics, Cloths and Voxel Grids.

Click further: The presentation video for FumeFX 6.0 is linked right here below. Digital Production last reported on the simulation software FumeFX on 13 April 2018 – at that time on the release of version 5.0. All further information can be found on the website of the VFX software developer Sitni Sati.

The post FumeFX simulation software available as a free beta! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: Version 1.4.0 of Flip Fluids has been released – an add-on for Blender that allows you to simulate fluids. Flip Fluids 1.4.0 already supports the recently released Blender 3.2.

Feature delights: What improvements, new functions and bug fixes can you expect? Find out below.

• New colour mixer (Color Mixer): This works via additive RGB mixing. Once activated, the particles absorb the colour attributes of neighbouring particles. Deactivated again, the particles retain a specific colour value. The developers comment on the new colour mixer: Additive RGB mixing is physically incorrect. Therefore, errors can occur when mixing colours – compared to what we would see in real life. For example, if you mix green with blue, the result is a grey tone. In reality, the green-blue mixture would result in a shade of green. The developers also note: If the colours concerned are close to each other within the colour wheel (e.g. red, yellow and orange), the colour mixing is close to reality. The combination of opposite colours on the colour wheel, on the other hand, results in a grey tone (e.g. yellow and blue). See the case studies from the Twitter posts linked here.

• New smoothing options (Smoothing): Once you apply the Age and Colour properties to the surface mesh, the new option controls how much (or little) smoothing should be applied. As soon as you select a higher value, the smoothing becomes stronger – but at the expense of performance.

Click further: The release note for Flip Fluids 1.4.0 can be found on github.com – along with all further information. The video below liquefies under your eyes, thanks to Flip Fluids! The delicious black bean in liquid form, shown in the title image, can be found from minute 02:58.

Customer Reel 2021 | FLIP Fluids Addon

The post Flip Fluids 1.4.0 is released! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: Chaos releases version 5.0 of Phoenix – the fluid simulation software for 3ds Max and Maya. To put a damper on the joy: Phoenix 5.0 is currently a work in progress, which is why some of the more elaborate features may not yet be supported.

New features: We have summarised the most spectacular new features for you below. Please also note the release video, which we have linked below.

• Phoenix with a single licence: This is only logical, as Chaos merged the individual licences for 3ds Max and Maya at the end of 2021. The subscription, which includes both 3ds Max and Maya, costs 70 US dollars per month, or 390 US dollars per year.
• More control over object movement: This includes Thruster Force, Axis Lock – but also Size Variation & Stringy Parameters to control the pattern of foam created with a flip solver. Also: A new voxel shader for gaseous liquids makes it possible to shade uploaded meshes and fire & smoke at the same time. In addition, you can expect new presets for: stormy sea surfaces, ship waves, ice cubes (floating in liquid) and (the cone of an) engine exhaust. You can read all about it at docs.chaos.com (Active Body Thruster) and again at docs.chaos.com (Active Body Axis Lock) – and for the third time – at doc.chaos.com (Voxel Shader).
• Standalone Simulator: A new command line tool with which you can further process scenes that have been calculated out of 3ds Max or Maya. According to Chaos, the simulation should be up to 40 per cent faster compared to the same simulation within 3ds Max and Maya. You can find detailed information on the standalone simulator at docs.chaos.com .
• Standalone Node Viewer: For debugging .simscene files. Further information is available at docs.chaos.com.

Click further: If you would like to click through to the source of information, please refer to the corresponding release note from 26 May of this year, published on Chaos Docs.

Chaos Phoenix 5 – now availableChaos Phoenix 5 – now available

The post Chaos releases Phoenix 5.0! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

Storm in a glass of water: In this Twitter post, 2D effects animator Quentin Cordonnier demonstrates how gravity affects a glass of water – and where the centre of gravity is located at any given time (inside a standard Ikea drinking glass filled with moist, cheerful H20).

Who is it for? Animation artists who are interested in the flow behaviour of water should find Quentin’s clear explanatory video particularly inspiring. But Quentin’s Twitter post can also provide an excellent template for other animation projects beyond water.

Who is Quentin Cordonnier? Quentin is a 2D effects animator with many years of professional experience at studios such as TeamTO, The Magnificent Itch, Studio 100 Animation, The SPA Studios (Sergio Pablos Animation) and Method Studios. On Twitter, Instagram and Gumroad , Quentin is always posting fascinating effects that are worth more than one click. Take a look!

The post Water still wet (and refreshing)! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: 3D artist Lark (stylised spelling: LARK) has created some beautiful looking water simulations.

What tools does Lark use? The tools in Lark’s toolbox were Blender and Flip Fluids – the latter is a Blender add-on that lets you create fluid simulations. Incidentally, the artist created the palm trees that line Lark’s water simulation using the Botaniq add-on. Both Flip Fluids and Botaniq are available from blendermarket.com. Flip Fluids costs 76 US dollars, Botaniq 129 US dollars. However, the trial version of Botaniq is available for just one US dollar, or the slimmed-down version costs just 49 US dollars.

Click further: If you want to continue taking virtual walks on the beach with Lark, follow the artist on Instagram or Artstation.

Check out this post on Instagram

A post shared by LARK (@lark__production)

Check out this post on Instagram

A post shared by LARK (@lark__production)

The post 3D artist creates water simulation in Blender first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: Matt Puchala, former Technical Director at ILM, releases Axiom 2, the latest version of his fluid solver that allows you to simulate smoke or fire within Houdini. Axiom was designed as a faster alternative to Houdini’s Sparse Pyro solver. In contrast to Sparse Pyro, Axiom operates with GPU acceleration – whereby the CPU is used if necessary, should you exhaust the GPU memory.

You can look forward to new features, as simulation types, support for colour trailing and spreading, a new volume visualise node, a new cone source shape for simulations and a new spin force type are among the new features – in addition to improvements in terms of workflow and performance.

Cost issue: With the step to the full version number 2, Axiom is taking a further step towards becoming a commercial plugin. However, you can still use the Fluid Solver free of charge in test mode or via Houdini Apprentice. The node-locked licence costs 399 US dollars, the floating licence 499 US dollars.

Availability: To enter the creative freedom of Axiom 2, point your mouse at this hyperlink.

Axiom 2 – What’s New

The post Axiom 2 | Release first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: Philippe Groarke publishes SimpleOcean, an OSL map that simulates vector displacement on water.

What can SimpleOcean simulate? Waves, foam and shading are just some of the wet characteristics that SimpleOcean has in its repertoire.

Availability: Just have a look at GitHub – there you can paddle your way through further information! Or click on the video below.

Explaining the water to fish: You can with this water simulation plugin, unless you slide downthis waterfall tutorial first, or check out Standorfd University’s academic paper on the latest research in water simulation.

SimpleOcean Shader Demo

The post SimpleOcean OSL | Release first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

Barrett Meeker, Creative Director at Lucky Pause, releases his Dune Solver for Houdini. Can you already hear the sandworm meandering through your workflow?

What can the Dune Solve do? The Dune Solver simulates realistic sand dunes that react to environmental influences such as wind or soil depth. Barrett wrote his solver with OpenCL.

Availability: If you’ve licked sand and can’t wait for the latest film adaptation of the sci-fi classic Dune, you can now dive into the virtual sandbox with Barrett’s Dune Solver for Houdini. The two videos below will – ouch! – sand in your swimming trunks!

Sand Dune Simulation

Sand Dune Simulation B

The post Dune Solver | Release first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.