More Than 5 Ways To Accelerate Your RealFlow Simulation
Computers and graphic cards have become blazingly fast over the years, but the complexity of simulations has also increased drastically. Although RealFlow is highly optimized for modern hardware, there are still many ways to get more out of your machine. Simulation speed is not just a matter of how many CPUs or cores a computer has, but also related to scene setups, export resources, and an adequate choice of substeps.
In this post we will go through a few comparisons with different substeps settings. To get comparable results, all simulations have been performed under identical conditions:
- The easiest way to do this is to send a project to RealFlow’s command line version to bypass RealFlow’s GUI. This simple action accelerates a simulation by 30% already.
- Simulation range is 100 frames @ 25 fps.
- By default, all export resources are disabled. Storing RealFlow’s data has a strong influence on simulation speed: it takes some time to write sparse OpenVDB files, compression, huge meshes, high-resolution displacement maps, and RPC files with 40 or 50 millions of particles.
For individual scenes, all relevant settings are located under RealFlow’s “Simulation Options” (see image below). If you want to change these parameters globally, do this in RealFlow’s preferences.
Substeps are some of the most influencing parameters. Of course it is very tempting to decrease them to an absolute minimum, but you always have to consider the entire scene: is there particle-object interaction, is a RealWave surface involved, do you want to simulate granular materials, etc. In all these cases substeps should be adjusted carefully and the previous blog post about substeps helps you to find settings that work for you. But did you know that some of RealFlow’s solvers are directly connected to the “MIN substeps” and “MAX substeps” parameters of the “General” tab?
Caronte Rigid and Soft Body Engine
Caronte substeps parameter is named “Quality” and it is an easy-to-use slider, and it is our first time-saver. In most cases it is enough to simulate with a value 25 or 30. Values of 50 or more are only necessary if you encounter problems. The project, used here, is nothing fancy and contains just a few fractured objects falling down.
As previously mentioned, some solvers are connected to the substeps under “General”, so let’s see what we get with “MIN/MAX substeps” set to 1:
So, by making two changes (“Quality” and “MAX substeps”) we have been able to accelerate the simulation almost by a factor of 5! Imagine how much time you can save in projects with hundreds of rigid bodies and lots of test simulations.
RealWave simulations are not coupled to the substeps settings under “General”. But, when you combine RealWave and Caronte simulations you will see an effect, because of the already discussed relation between “MIN/MAX substeps” and “Quality”.
The speed gain we get with a clever choice of substeps is really impressive:
Dynamic bodies have the ability to float on RealWave surfaces and create secondary waves. In order to avoid spikes or high-frequency ripples it is often necessary to simulate with “MAX substeps” values around 10. With particles, hitting the surface, it is more or less the same.
RealFlow’s Hybrido solver has its own settings for substeps, but they are also coupled to the parameters of the “General” section. As long as you work with 1/300 substeps you will not see any effect, but the following example combinations influence the look and quality of your simulations:
1. General 1/300 and Hybrido 1/2 → actual substeps = 1/2
2. General 1/1 and Hybrido 1/2 → actual substeps = 1/1
3. General 2/2 and Hybrido 1/2 → actual substeps = 2/2
The real difference in simulation speed with Hybrido becomes obvious when the number of particles is low. Hybrido has been developed and optimized for large-scale simulations with millions of particles and secondary elements like splashes and foam. This means that you will see rather high simulation times with just a few thousands or ten thousands of particles. With several millions of particles, on the other hand, the Hybrido solver shows its real power and CPU usage will also increase to some 85% or even more.
My test scene is a Hybrido breaking dam scene with 2.5 millions of particles and strong splashes. The splashes create a very complex distance field and this is the computationally most expensive part in this scene:
Hybrido and GPU Simulations
The effect you can get from GPUs in conjunction with Hybrido simulations is rather small and comparable to one additional CPU core. In many cases you will not see any difference at all, for example when the project contains complex daemons, lots of high-resolution collision objects, or complex distance field, as in the test scene. It also makes hardly any difference which GPU board you will be using with Hybrido and there are more effective ways to accelerate your Hybrido simulations: a processor with high clock frequency, a fast storage device, and a sufficient amount of RAM have much more influence on simulations times.
Here are the results:
We don’t think it makes too much sense to pass Hybrido simulations to the GPU, because only the particle advection part is done by the GPU.
Dyverso is very fast by default, but it provides a real super booster:
- With OpenCL or CUDA it is possible to speed up your simulations by a factor of 3-8 compared to the CPU.
- In contrast to Hybrido, the GPU board really makes a difference. High-end boards or modern gaming cards will accelerate your simulations drastically. Older graphic cards are often not able to outperform a fast multi-core CPU. In such a situation you might even see a slight increase in simulation speed.
Here, let’s focus on the PBD particle type. The simulation is based on a breaking dam with 400,000 particles, a simple cube object acts as a container/collision object.
The results speak for themselves – for the GPU test a GTX 1080 GPU (CUDA) has been used:
RealFlow’s Dyverso solver is connected to the “General” substeps in the same way as Hybrido. So I recommend checking your settings before you start to simulate or when you encounter unexpected problems.
We have a lot of possibilities of accelerating RealFlow simulations, but there is even more. A very simple, yet efficient method is to activate RealFlow’s command line or disable the viewport during simulation:
As written in the introduction, the command line bypasses RealFlow’s GUI and this make simulations much faster – typically by 30%. The good thing is that you can leave RealFlow’s GUI open while crunching simulations via the command line version. All you have to do is to press Alt + U from time to time. This shortcut updates the project’s already simulated frames and you can monitor the progress.
Disabling the viewport has a speed gain comparable to the command line. When you press Alt + D, the viewport turns black and the particles will no longer be drawn. This action will take load off the CPU and accelerates the simulation. To see the current progress, press Alt + D again.
Proxy geometry can also help to cut simulation times. Huge setups and high-resolution objects might bring your computer to its knees, especially with Dyverso and GPU simulations.
Closing as many applications as possible during simulation is another thing you can do to get more out of RealFlow.
When we talk about hardware there is a simple rule of thumb: the more, the better:
- High clock speed is always good and many i7 CPUs have very similar or even better performance specs as their Xeon-based counterparts, but i7 processors are often cheaper.
- 16 GB are good, 32 GB are better, and 64 GB won’t hurt either.
- Fast hard disks are a must. Old 5200 rpm drives might be good for office applications, but they are definitely not suited for simulations. Saving particles, meshes, fields, displacement maps, and other things can take up to 30% of the entire simulation time. So, do yourself a favour and spend some money on fast hard disks.
- A modern GPU is like a rejuvenating cure for your computer at an affordable price. The amount of VRAM determines the number of particles and objects in your simulations.