Physics Forests - A New Real-time Fluid Solver - Download demo NOW!

We are developing a new fluid solver using machine learning, capable of simulation large simulations (for foam-less fluid ~10 million, with foam a bit less) with surface generation, rigid body coupling, multi-phase and rendering in real-time. The quality-running time trade-off is controllable.

Recent simulations:

SIGGRAPH 2017 Real-time Live submission video :

The method is perfectly stable in any circumstances, including when the incompressibility constraint can not be fully satisfied (non-simulated objects squash the water etc).

We developed the alpha version of a plugin for UE4, mainly for designing purposes, but if there is any interest in the game development community, we can work on it a bit more to make it releasable. Based on my knowledge, a typical games give only several milliseconds per frame to a physics engine, and mostly only on CPU. We haven’t optimized our method much (it’s simply a basic vanilla implementation), so there is a large space for improvement (my guess is that 5x should be achievable). Also several approximations (height map and low precision/skip calculations outside of the region of interest) are possible, however 3ms on CPU with current hardware seems out of reach.

If anyone’s interested in our project, or is able to provide us some example scenario from UE4 with a lot of water, so that we can optimize an algorithm for a particular scenario, please send me a message or write a comment below.

It looks great but I want some actual performance numbers. Because everything beautiful costs a lot.

All videos are actual real-time recordings with NVIDIA ShadowPlay. The number of fluid particles, foam particles and per frame running time in shown in each video at the bottom.

In the fastest setting:

  1. 10M particles run in real-time
  2. foam decreases the performance by maybe 20-30%
  3. multiple fluids are a bit slower (we improved by maybe 30% since we recorded that video)
  4. particle rendering (sand) is slower than surface (water), dust(rendered as smoke) rendering is much slower
  5. rigid bodies are not optimized yet and for example in the last duck video they take ~10ms per frame

All videos were recorded on TitanX, some of them run faster than the other, because we used different setting.

Cool I’ll keep an eye on this.

This is incredible. One step closer to real-time fluid simulations in games. I could think of a hundreds of possible game ideas with this. But the problem I would see is unpredictability. Which is nice of course, but it could be hard to make “fair” games with this as there are so many variables to factor in. But some basic physic based games could be very fun. Maybe even like a waterslide game or wild river game where you have to avoid obstacles and such. But then you’d have to add something that only fluid simulations can give, because otherwise it’s a bit overkill. xD

It looks really awesome, could you show how it looks like with a quite low res so that the performance impact is only something like 3 ms? Does it scale linearly with the particle amount, so will 100 times less particles run 100 times faster? In games you often don’t need super high accuracy.

Why do you mention the CPU here? Isn’t the fluid sim only heavy on the GPU?

Also, you mention CUDA, if you want this to be usable in games you should make it use OpenCL, direct compute or vulkan compute so that it runs on AMD and Intel GPUs too, for now direct compute is probably the best.

In practice the behavior is close to linear in a range 10k-100M. (at ~120M we run out of 8GB GPU memory). It is slightly sublinear up to 1M particles, and slightly superlinear from 5M. So if particles were twice the size in every dimension, it would be approx 8x faster and might fit into those 3ms.

Typically physics library (Havok for example) runs only on CPU. Getting GPU computing power in AAA games except for rendering might be impossible. I hope this will change in the future:)

We have an OpenCL version too (which was our original implementation), we switched due to better debugging tools for CUDA. We will consider other platform after we progress a bit further with the development.

That sounds nice.

I don’t quite follow your here. As you said below the fluid sim can run either on CUDA or on OpenCL, which is both GPU. So if you run this, then it will take GPU time, not CPU time. You are saying “Getting GPU computing power …] might be impossible”, but its exactly what you are doing as far as I can tell, so it doesn’t make any sense to me what you say here?


Yes, you are right. I should have skipped all that nonsense:). I just wanted to say there is no way we get it working in 3ms on this scale on CPU (we had such offers).

Saw the papers on this last year(ish?) very cool to see it just brought to a plugin and etc.! I’m curious, what’s the deployment of the neural network like in terms of inference bit depth? Can you go through the built trees in 8bit like I’ve seen others?

I would think that everyone knows that doing this in 3 ms on a CPU is absolutely not possible :rolleyes:

You say you might be able to make it 5 times faster, if you then double the particle size and that makes it 8 times faster, then that means its 40 times faster. That means all of your demos would run at way less or slightly above 1 ms, which would be super fine in a game. Now these numbers are Titan X, so something like 2 or 3 ms on a 970 is still great.

If it really works out like that, I definitely see this being used a lot. Sounds a bit too good to be true though actually :slight_smile:

we don’t use NN, we use our own variant of regression forests with max depth 20

the factor you did not include in your calculation is the size of the simulation, which would typically be a bit bigger than in our videos

That simulation looks amazing!
As for interest in the game development community, here are a bunch of things that would be cool to have:

  1. Blueprints integration. Would be kinda cool to be able to attach fluid emitter to movable BP actor, be it a weapon or just a fluid container.
  2. Flooding simulation and water resistance. I work on game with underwater vehicles in it, and I had to simulate underwater movement by making a 6-axis zero gravity vehicle. One hell of workaround that requires a lot of additional parameters to look right. The very fact that you have a working buoyancy already makes me happy, but it would be even more cool if it would be possible to tweak buoyant actor sinking, ideally with visual flooding inside the mesh or without it by just tweaking parameters.
  3. Wave generator.
  4. Ability to make unlimited distance water pool with blueprint actor.
  5. Cut out zones in fluid surface for objects/landscape placement
    Will keep an eye on this thread, in current state imo this simulation looks better than the vast majority of currently existing solutions. I know it is probably a bit too early to ask, but I assume you targeting unreal marketplace with this thing, so I would like to know about theoretical pricing for final version.
    Anyway, keep up the good work, this is just incredible.

Looks like some Houdini type sims… Very nice!


We started implementing unreal plugin only ~2 weeks ago, so far we are able to visualize the result, but the simulation is defined outside of unreal. We plan to do a full integration within a few weeks. Attaching the source to a movable BP actor should not be a problem; from the simulation point of view it is the same as in that teddy bear video, where we controlled the emitter by the mouse.

It should be already possible, all these tweaking parameters are already there.

that should be possible with a small additional external force (slight modification to what was used in the last dust video in “various materials”)

I don’t fully understand this request. Unlimited simulation would be possible only if we simulate the water only in some region of interest and elsewhere it would be governed by a wave equations. We plan to work on various approximation methods like this in the near future.

That can be already done and it was used for example in the sandcastle scene.

It is a bit too early, it will depend on the interest and on what will our plugin eventually include. We also work on a few other applications of our method (so far in the released videos both acceleration prediction and surface generation are done using machine learning), we will release videos when we are happy with the quality.

If they get this to a state where its usable in many games, I would definitely advise against putting it on the marketplace. They should go the more common middleware way of doing custom licensing, with options for indies and for AAA. There would definitely be big companies interested in this, and those are willing to pay a lot more than indies.

I would suggest doing it like InstaLOD does:

An indie version for something like $79 and custom licensing for bigger companies :slight_smile:

I can see this being very useful for making offline simulated assets, like realistic looking riverbeds with pre-simulated water flow.

Although Real-time fluid simulation in AAA titles might be a few years out in terms of hardware, having a user-friendly way to create water flows & structures that have been baked for placement in static worlds would have a variety of applications and presumably be vastly more performant than a real time simulation.

The technology development is in a very early stage and so far we just tried to figure out the right setting, such that the simulation looks reasonable, can handle interactions (so far rigid bodies, but in principle the method can be similarly combined with other kinds of objects) and can generate surface. I’m aware that the technology is not practically useful yet as it is, but there is a large space for improvement not only by raw optimization of the GPU code, but also by simulating a different level of details depending on the distance from the camera (either using height map, wave equations for ocean, varying sized particles, …) . All these tricks would cause stability problems in our methods, but our regressor would be just fine with that. Basically, it should be possible to run arbitrary large scene with only 1M predictions per frame. But all the tweaking and optimization will take some time.

The main reason we advertised our method was to get some feed-back from the people from the field, and potentially get some assets/designed scenes to tune all these LOD hacks (so far that doesn’t seem that easy). It might be too early for our method even after we do all the things we plan, but I just case how this would be the case in 5 years.

an ocean.

a mountain river coming down to plains where it starts meandering.

water and sand interaction

just to mention 3 things i would use this for. If i could.