The Fluid Flux is a powerful water system based on 2D shallow-water fluid simulations.
Features
- Realtime shallow water simulation – fluid data modifiers, wave generator, and extendable interface
- Fluid surface rendering – caustics, wetness, underwater, waterline, advected foam, advected waves, blending with the ocean, dynamic audio detection
- Fluid Interaction – simple cheap ripple solver moving with character, optimized to an absolute minimum
- Ocean wave blending – rendering tillable ocean heightmap texture in a single pass
- Niagara environment interaction – High-quality effects, bouncy, plants, character swimming, boats,
- Clean, efficient, GPU friendly implementation, interface designed with the KISS (Keep It Simple, Stupid) rule in mind
- Small, compact, and low memory footprint
- Tool for generating ultra-fast static meshes with flow maps baked into vertex color.
- Advanced fluid state management, loading state in gameplay.
- Niagara fluid async readback system for sampling height and flow of fluid in blueprints.
- Dynamic audio analyzer. The sound source is positioned based on fluid movement.
- Four example maps – beach, island, river, and baked static river
- Velocity based fluid flow advection method for foam caustics and waves
Limitations
With great power comes great responsibility. I’m trying to be a reliable marketplace creator so it is important for me to be clear about the limitations and disadvantages of using simulations. The Fluid Flux system is overhyped so please read the description below before you buy this product and make sure that everything meets your expectations and requirements:
- In general, I can’t solve every possible water problem in every possible type of project. The Fluid Flux is a huge step forward for the game industry but also makes everything harder. Simulations can be hard to control and tweak, sometimes a single parameter can change the flow of fluid on an entire map.
- The Fluid Flux simulation is based on the Shallow Water Equations (SWE) solver, the algorithm was published by Matthias Müller in “Real-time Simulation of Large Bodies of Water with Small Scale Details”. Simulation is calculated on heightfield mesh which means all obstacles are rendered to heightmap with top-down projection. Fluid can’t be simulated in caves and multilayered.
- Scalability is a real problem. The simulation requires allocating floating-point render targets so the maximum recommended resolution of texture is 1024×1024. That means if 1 pixel represents 100 cm in real-world (very low quality) then your simulation area can cover approximately 1km x 1km square with low detailed water. It’s not that much but still useful. The simulation frame can be baked to static mesh and used as mesh placed on the level.
- Multiplayer is not supported for dynamic simulation because synchronization of render targets is limited. However, the system can be used in a multiplayer game as long as your gameplay is not dependent on fluid simulation results.
- The geometry of fluid is rendered using a static mesh plane displaced by fluid height. The system uses a huge plane (1024×1024) for rendering the water surface without any dynamic tesselation. This method has a lot of quality flaws.
- Statically generated LOD mesh can be inconsistent with waterline post-process this issue will be addressed in the future.
- Water Plugin is not supported in the current version. It is possible to use my water material on the water plugin but it is not officially supported yet.
- Niagara fluid feedback system returns results with one frame delay. It’s good enough for most features like swimming water detection etc.
- My support time is very limited. It’s an early version of this product, be aware that there will be multiple updates that will improve the quality and efficiency. The project is enormously big and complicated, simulations can be unpredictable – sorry for all the problems and bugs. Im ready to help in case of problems contact me on Discord or by e-mail.
- The documentation is incomplete in some areas yet. I was pushed to release as soon as possible and could not have enough time to build simple examples. The Fluid Flux system is clean and elegant but blueprints reading skill, and example code analysis is required to use.
- Fluid Flux relaying on Single Layer Water rendering mode because it makes life easier in terms of reflections and time of day updates.
- The axis-aligned rectangular volume of simulation is only supported which means it can’t be rotated.
- The simulation area can’t be moved during gameplay. Movable volume is one of the most important features for future updates.
- Multiple simulations on a single map are not well tested yet and can make some problems with camera post-process detection.
- Trace hits with dynamic fluids are not supported now.
- The system also does not support the wave break effect because this approximation of fluid does not contain the needed data to render it.
- Underwater glass, holes, and the submarine view are not supported.
Good and bad practices
- Try to avoid using huge simulation resolution because you will run out of memory very fast, 1024×1024 seems like a good compromise for now.
- Don’t make your gameplay rely on fluid simulation in multiplayer because it will not be synchronized.
- Avoid using Fluid Flux on flat surfaces, subtle slopes are always better.
- Avoid hard-edged geometry (boxes) it can be approximated wrongly on heightmap and sometimes look terrible
- Don’t overestimate possibilities if I was not prepared ocean with ships and a huge island covered by rivers and simulated lakes then there is probably some reason for that.
- Try to not update the simulation ground in every frame it can cost you a lot of performance.
Questions & Answers
- Unreal Engine 5 support?
The Fluid Flux was created and well tested on Unreal Engine 4. The Unreal Engine 5 is in an early stage of development, and unstable, the pack can be used with this version of the engine but I can’t support engine-related bugs and all differences between UE4 and UE5. - Why the price is so high? Could you do some promotion?
- Creating Fluid Flux took 16+ months of work during nights, after a regular job. Normally this work would cost the company at least $150 000 so it is a huge shortcut for everyone.
- The subscription for all future updates and support is included in the price. This kind of system requires a lot of support. The engine updates make it even harder. It is not the only product on my marketplace profile so my time is very limited right now. I will have to hire someone for help.
- It’s more like a system for water-related effects. It’s a combination of multiple big features that work together and thanks to that your life will be easier. You don’t have to buy and work on merging ripple water, fluid simulation, water surface, ocean waves, buoyancy, waterline, post-process, and swimming from multiple separate systems. I did it for you.
- Take a look at my marketplace profile and make sure that I am a trustworthy creator with hundreds of positive reviews. The price is always calculated on the real work and time that I need to put into my products. Someday you will understand that time is a real currency that is worth something in this world.
- When everything will get stable and I will find more time to support new customers then I will start doing some promotional sales. If you are not in rush and can wait a few months then just add my pack to the wishlist and be patient.
- There are free alternatives like Niagara Fluids, and Water Plugin you can try them and compare results with my demo, maybe you don’t need the Fluid Flux.
- Can it be used in my open-world game?
The open-world setup was not tested yet. The demo examples are showing how the system can be used. I can’t promise anything more at this point of development. Just assume that you get what you see on my videos no more no less. - Does it support multiplayer/replication?
Unfortunately, fluid simulation is not replicated. A huge render target is generated in every frame and cant be synchronized so if there would be some differences between clients there is no way to correct them. The package can be used in multiplayer games for visual addition. - External packs integrations ALS/UDS/Fluid Ninja/Voxel Plugin
I am planning to work on some integrations in the future. If you have some specific pack in mind let me know. - What about VR and mobile?
Currently not supported. Dynamic fluid simulations with high precision can’t be calculated on mobile so only baked meshes/states can be used on this platform. I am planning to add VR and mobile support in future updates. The pack will receive a light surface material mode similar to the solution presented in Aquatic Surface. - How to add swimming to ALS? Can you show me?
This task is on your side. The Fluid Flux can give you all data that you need to implement swimming (BP_FluxDataComponent). I’ve also prepared an example swimming implementation (BP_FluxSwimmingComponent) for testing. - Should I change to Fluid Flux? Is it better than WaterPlugin/Oceanology or Aquatic Surface?
It depends on what requirements you have. The Fluid Flux is good at creating a dynamic river simulation on heightfields, and interactive scenes but does not scale very well so if you need just a background ocean then you should not bother using simulations. Play the demo of the Fluid Flux and decide if this is what you want. - Why blueprints? It is slow because of that?
This system is fully implemented in blueprints but relays mainly on GPU (shaders/render targets). The cost of c++ implementation would be similar in typical conditions. In the future versions, the cost of blueprints will be reduced by Niagara implementations so it will be even better. User interface and lack of tessellated fluid surface is a bigger problem with blueprints but I will also work on solving that. - Is fluid flux calculated deterministically?
If you run a simulation on the same machine it is deterministic (constant delta time is used) but there are probably differences between floating-point operations on different GPUs so it can’t be fully deterministic. In multiplayer the biggest problem is the synchronization of state when someone joins the game and when the player loses some frames because of spikes and the simulation can’t work it off – I’ve decided to limit the number of accumulated iterations per frame in this case. - What about the future of this project?
I’m planning a lot of updates, optimizations, and moving implementation to Niagara.
https://trello.com/b/NBN93cSo/fluidflux-roadmap
Reporting Bugs
Code that doesn’t exist is the code you don’t need to debug. I am trying to do my best and solve all possible bugs or find good workarounds but there is always something that can be broken it’s like a typical lifetime of applications nowadays.
Simulations can be unpredictable some edge cases are probably still not handled. In case of finding some specific bug, you can rep[ort it to me and I will take a look at it in a few days. Before sending the report:
- make sure that you use the newest version of my pack.
- prepare a detailed explanation of repro steps needed to recreate your bug, and make sure that the explanation is as clear as possible.
- information about the engine version you use, and your development platform.
- create a minimal example project that can show me the bug (it will increase the chance of fixing it)
- prepare a video or screenshots presenting the problem.
Now you can report this bug by sending an e-mail at: krystian.komisare@gmail.com.
Known issues
- Meshes with dithering enabled cant to be cached by ground capture. There is a workaround for this problem presented in the M_Photoscan_Master material.
- Currently, known issues that exist only on UE5:
- In some configurations of UE5 reflections can flicker on rivers. It’s somehow related to reflection capture actor but I was not able to find the reason why. Removing box capture helped once but some users still experience this bug. If you will find the answer then please let me know.
- The audio parameters are not working on UE5 (will be fixed in 5.0.2) so Fluid Flux uses a workaround that is switching between under fluid and over water fluid waves instead of soft blending.
- The palms are disappearing because there are some problems with vertex offset in UE5.
- Plants will not load properly on the map if you are not in “Real-Time” render mode in the editor. Its limitation of blueprints I don’t have any event that could execute afterload and adjust Niagara effects.
- “Real-Time” render mode is also required to simulate in the editor. Otherwise, the view will not refresh after each frame.
Planned improvements
- Surface mesh – better water surface. Currently, it uses dense planar mesh but in the final stage, the mesh will be dynamically tessellated.
- Scalability – Large-scale simulations locally updated with the moving areas are in my plans.
- Niagara fluids – the system will be rewritten to Niagara fluids when it will be stable and ready for this.
- Audio detection – the current system uses an ambient audio source and a simple dynamic source I am planning to improve to three dynamic sources of audio that works at a different distance.
- Simulation volume – movable simulation area and working with multiple simulations a the same time.
- Alternative material modes – path tracing and stylized water
Documentation
This section covers the fundamentals of Fluid Flux and its tools. If you are new to Unreal Engine, you should become familiar with the Unreal Editor interface, Blueprint visual scripting, and the types of content. Working according to the documentation can provide the best possible experience with this product.
Project config
The Fluid Flux pack requires enabling a few basic building plugins and TPP input config for testing the character. The package is an asset pack so it can be downloaded directly to the project only. The package can be added to any project using Epic Launcher but users also can use an empty project compatible with UE4.26 configurated can be downloaded from the link: FluidFlux_Template.
A list of plugins that needs to be enabled can be found below:
- Editor Scripting Utilities
- Niagara
- Procedural mesh Component
- Asset Tags (optional)
The first place to visit in the demo folder is Demo/Maps. This folder contains all example maps that are working perfectly with the TPP example character (BP_DemoCharacter). If the project uses another character template then probably input should be changed to make it work. Input config can be downloaded from the link: DefaultInput
Make sure that DBuffer is enabled in your project settings because it’s required for proper decal (wetness and caustics) rendering. If you don’t want to use those effects then you can disable decal material in the surface actor.
Project structure
- Demo – The demo is the most important folder for new users. The demo examples present how to use this pack, how effects can be achieved, and how to integrate systems with character. Everything that can’t be found in this documentation probably will be presented in a very clean way in the demo folder.
- Editor – editor related tools, icons, utilities, procedural mesh generator
- Simulation – Shallow water simulation actor and tools for controlling fluids and generating state.
- Interaction – Simple system of interactions that adds detailed lightweight ripple fluid simulations.
- Surface – Presenting the simulated fluid renders surface, underwater volume, post-process, caustics, and audio and combines everything together.
- Environment – Niagara particle systems that allow readback pieces of information from simulation implementing swimming, buoyancy, and drive particles using fluid state.
- Waves – a system designed for generating ocean waves that can be used in the background and mixed with fluid simulation. Before starting work with the pack it’s worth being familiar with the structure of the pack and the systems that it provides.
Updating pack
The current newest version is described on the marketplace page and on top of the documentation. Frequent updates of Fluid Flux are planned so always make sure that the Fluid Flux package version is up to date but be aware of potential problems when updating.
Changes that can be made during updates:
- fixing bugs
- adding features and examples
- removing/renaming files
- improving quality and exposing parameters
I am always trying to minimalize the damage after the update however it is not an easy task when an update system on the marketplace supports only adding or replacing files. There are a few basic rules worth noticing before updating:
- It’s better to have some backup. Copy your version of the pack before doing the update,
- Remove the pack from the project before updating it. This way you will get a clean, and fresh version of the pack without any ghost files.
- Do not modify the pack on your own. If you need modifications then you can inherit classes/materials and override functions. Store child classes and custom material instances outside the Fluid Flux folder.
- If you need some small trivial modification that could improve usability then you can let me know we will figure out some solution maybe put it into the next update.
Simulation system
The BP_FluxSimulation blueprint is the heart of the Fluid Flux system. Basically, this blueprint handles important tasks like:
- Rendering of the ground heightmap to texture.
- Updating simulation of shallow water fluid, foam, and wetness.
- Baking and exporting simulation state.
- Sending data to the fluid surface renderer.
The Shallow Water simulation is based on the idea of assuming linear vertical pressure profiles so it is simulated in two dimensions. In general, the algorithm can be described in a few steps:
- Simulation data is stored on 2D render targets.
Ground map – information about landscape and obstacles
Velocity (RG) Depth(B) Foam(A) map – stores information about fluid
Height(R) Wetness(G) map – stores surface height and wetness of the surface - The slope of the ground heightfield and slope of fluid is combined and used for calculating the pressure and velocity.
- Simulation is an interactive process of updating fluid height and velocity.
- The result of integration is used for foam and velocity advection.
- Fluid modifiers can be used as input for simulation to change the current state.
- The simulation frame is used for accumulating fluid wetness and generating the fluid surface mesh displacement.
The BP_FluxSimulation actor placed on the map is doing nothing because it’s empty and needs to be filled with fluid. It is the simplest way to fill containers with fluid is by adding a Modifier source actor.
If the simulation actor is not rendering some static mesh actor to the ground map then probably the material of this mesh uses the Pixel Depth Offset feature that is blocking it. The M_Photoscan_Master material implementation contains a workaround of this problem (multiplayer Pixel Depth offset by IsPerspactive node).
Real-time simulation
Before starting simulating the fluid on your level make sure that Real-time rendering is active in your viewport. This option is required for the proper working of the system because forces refreshing the screen when the simulation is rendered.
Modifiers
The modifier component affects the simulation state and changes the current simulation state. It’s the simplest way to control simulation. Modifiers can be used for:
- Adding fluid to simulation container.
- Removing fluid simulation container.
- The changing velocity of the fluid in some areas.
- Simulating interaction with fluid
- Generating waves
- Control fluid flow and volume
The Fluid Flux contains predefined modifiers:
- BP_FluxModifierComponent – Base parent class for all fluid modifiers.
- BP_FluxModifierSourceComponent – Simple modifier that allows adding/removing fluid and changing velocity in a specific area.
- BP_FluxModifierGerstnerComponent – Generates Gerstner waves.
- BP_FluxModifierInteractionComponent – Generates interaction with fluid. Can be added to the character.
Every modifier component extends the basic BP_FluxModifierComponent and implements specific behavior. Users can create new modifier classes with specific behaviors like whirpools/waves. The BP_FluxModifierSourceComponent component is a good simple example of a modifier that can be used as a starting point for learning the system.
The modifier container is a special type of actor that can store multiple modifiers and send them to simulation. If the actor implements BPI_FluxModifierContainer interface then it’s considered a modifier container
BPI_FluxModifierContainer interface can be implemented by any actor. A good example is BP_DemoCharacter that uses BP_FluxModifierInteractionComponent to interact with a fluid. AddModiffiers function only needs to be implemented to make it work.
BP_FluxModifierContainerActor is a basic container that can combine multiple modifier components in a single actor that works simultaneously.
BP_FluxModifierSourceActor is a specific type of Container actor that simplifies the process of adding simple source modifiers to the scene.
Every modifier is rendered in an additional render target pass, so it’s not cheap. It’s good practice to minimalize the number of fluid modifiers inside the simulation for achieving the best possible performance.
Highfield ground
The simulation actor needs to recognize the ground to understand the environment and find slopes for fluid movement calculation. The simulation actor contains settings that allow configuring which objects should be rendered to the ground heightfield.
The Debug preview option is the most important feature here, it can show debug of ground on the scene. If you will notice that some objects should not be rendered to heightmap you can exclude them and if something is not rendering you can start investigating what is going on without simulating the fluid.
Meshes with dithering enabled cant to be cached by ground capture. There is a workaround for this problem presented in the M_Photoscan_Master material. IsPerspective node is used for disabling dithering on objects that are rendered in top-down flat projection.
Sometimes picking “Hidden Actors” one by one to exclude them from heightfield can be a waste of time. There is an additional tag called “FluxHide” that can be used by actors to hide them automatically.
Dynamic ground
The Fluid Flux uses a static ground map for simulating fluids on it but updating is also allowed from time to time. It’s not a very cheap operation so it should not be done every frame.
The BP_BreakableDam presented in the video can be destroyed when the player hits the trigger. It is a good example of updating the ground after the dynamic object. Take a look at the Break function which is the heart of the dam system.
It evaluates UpdatGroundMap on a simulation actor, which takes the position and the size of the object that will disappear to recreate the ground in this area. You can do the same operation when adding something on your level.
Editor
The BP_FluxSimulation blueprint comes with a simple editor that allows simulating the state of the fluid on the map in the editor mode. Simulation can be prepared in the editor baked to state or dynamically updated by the simulation blueprint.
Fluid state
The PDA_FluxSimulationState is a special data asset created especially for storing the current frame of the simulation. The simulation state is the most important structure in the system because:
- It’s dynamically updated by the simulation actor
- Can be saved to a data asset file
- Can be loaded in runtime
- Can be used as starting point for simulation
- It delivers data that can be rendered by the surface actor
Example river state and baked textures.
Pay attention to simulation resolution! The “Power of Two” rule is a fundamental necessity due to the way game engines work. You will not be able to export simulation state if it is size is not power of two (128/256/512/1024 etc.)
A short tutorial about generating the fluid states:
The state use case is described below:
-
A dynamic simulation state is automatically created in BP_FluxSimulation.CurrentState actor constructor script. Data stored in it can be easily previewed.
-
If BP_FluxSimulation.SurfaceActorReference is set then actors are communicating together and the state is automatically passed to BP_FluxSurface.SimulationState
-
BP_FluxSimulation.CurrentState can be baked to an asset by clicking the right button on BP_FluxSimulation and choosing Scripted Actions -> Flux Export Simulation.
-
The Baked state can be used as BP_FluxSimulation.InitialState in simulation actor
-
Baked state can be also used BP_FluxSurface.SimulationState after removing/disconnecting the Simulation actor.
Fluid surface
The BP_FluxSurface is responsible for an audiovisual representation of the simulation state data. The Surface actor supports a list of advanced subsystems:
Actor component | Features |
DecalCausticsWet |
|
SurfaceOverMesh |
|
Post-Process |
|
SurfaceUnderMesh |
|
SurfaceProceduralMesh |
|
FluxAudioComponent |
|
Volume Absorption, Volume Scattering |
|
Mesh generator
In the tutorial below, we will go through a useful workflow for generating static meshes based on a baked state of the simulation. With this method you can achieve the highest performance, unfortunately, the waterline effect will not correlate very well with static mesh geometry.
- Setting up LOD and padding
- Converting a generated mesh to a static mesh asset
- Preparing material for static meshes
- Using static mesh in Surface actor
Mesh generation tools can be found in the BP_FluxSurface – Procedural Mesh tab.
Switch GenerateProceduralMeshView = true to see a preview of the generated mesh. After choosing this option surface automatically generates static mesh based on the Procedural Mesh tab configuration.
The last step is selecting SurfaceProceduralMesh Component and clicking “Create StaticMesh” which will export the mesh to the static mesh asset.

Saving static mesh assets with dynamic material is impossible that is why you will have to clean the material slot in the newly created mesh before saving it.
Fluid data like foam and velocity are encoded in vertex color which is why they can use simplified material that does need to sample render targets. MI_River_SurfaceOverStatic is an example configuration of material prepared for static meshes. MI_River_SurfaceOverStatic .UseFluxState = false forces system to read data from vertex color.
BP_FluxSurface can render static meshes using SurfaceMeshMode= StaticMesh which means the mesh will not be transformed by simulation scale and geometry will be taken from SurfaceOverMesh component configuration.
Async readback
The Fluid Fluix is using Niagara asynchronous readback events to read data from fluid render targets and pass them to blueprints. The BP_FluxDataComponent is a listener that can receive, update and store fluid data at a certain location.
The Fluid Flux uses this feature in multiple situations:
- buoyancy and floating objects
- automatic dam breaking
- interaction detection
- swimming system
- fluid sound source analyzer
- underwater camera detection
Add BP_FluxDataComponent to your actor and it will automatically detect the fluid surface under the actor. BP_FluxRotatorActor is a good simple example of an actor that can react to fluid.
Interaction system
The BP_FluxInteractionCapture is a system designed for adding detailed ripple simulation on the fluid surfaces as a result of the interaction.
- It’s a perfect addition for cheap prebaked static simulations that can improve quality almost for free.
- It is currently supporting the simplest fast ripple solver but pressure fluid solver it was designed to extend with other types of solvers
A great example of implementation is BP_DemoCharacter character The actor needs to contain three basic elements to support interactions:
- BPI_FluxInteraction implemented by an actor. It’s the way of communication. The interaction capture actor is detecting overlap with the interactive object and in every frame asks for interaction lists.
- BP_FluxInteractionComponent added to an actor. This component stores the basic config of interaction basic declaration of interaction sources need to be set.
- BP_FluxDataComponent added to an actor. This component allows getting information about fluid under the actor to decide if interaction should be spawned.
Niagara integration
The Niagara integration is based on three elements:
- BP_FluxNiagaraActor communicates with the simulation and data to the Niagara system.
- NE_FluxData emitter that should be inherited by the Niagara system to read the data.
- NMS_FluxData special module that extracts simulation data to Stage Transients variables that can be used to drive the particles.
All particle systems (trash, plants, splashes) in the pack are constructed the same way, fill free to check the examples and modify them.
Ocean waves

The BP_FluxWaveTexture is a dedicated actor for simulating ocean waves. Implementation is much simpler than the classical analytical approaches like Gertner or FFT. The system uses multiple tillable textures and combines them into a heightmap that can be used in the post-process/surface/Niagara system to represent wave displacement.
The beach example contains ocean waves blended with fluid simulation.