The sparse volume data structure is the core of the solver. In this section we will talk about the difference between dense and sparse volumes. Then, lower down on the page we will go over the setting for the sparse volumes.
In a traditional solver everything you see in the domain space is considered and the grid’s voxels are evenly distributed. We call this a dense grid. Think Houdini volumes. The volume encapsulates the entire simulation, however this means that sometimes there is a lot of empty space that still gets computed and stored in memory.
In the PSEUDO solver only the area around the density is considered. See above that only the white leaf nodes contain voxels that get computed. We call this a sparse grid. Think OpenVDB. This volume data structure is much more memory efficient because we only store value in memory where density exists. The difference between PSEUDO’s volume and VDBs is that this volume data structure is compatible with OpenCL and can take advantage of the computational power of a GPU. Note you can also use the solver on the CPU. See the preferred device parameter under the solver settings.
When using the PSEUDO solver there a few things to keep in mind that are unique to this kind of solver.
The first is right near the top of the UI. It is the parameter called voxels. This value specifies the maximum number of voxels this simulation can use. You can make this number as large as you want, but keep your GPU vram or system ram limits in mind. You will find a text label below that will tell you how much memory the number of voxels you chose will need. The solver will not add more voxels if it hits this limit. The reason its not dynamic is because reallocating memory every time step is expensive. You can check the current number of active voxels by either checking the output VDB or by looking at the debug mode printout in the console. You can enable debug mode under the solver setting tab. See below for an example of what this printout looks like. Look for the Active Voxels row in green.
Next, you will need to look under solver -> settings -> sparse. Here are the lesser used settings for the sparse data structure. Typically you won’t need to worry about them but in some situation it is important to know what they do. Also, note you would never disable sparse. That just disables the solver completely. There is no dense option with this solver.
Some settings are simple, such as remove inactive leaves that will remove leaves who’s density value falls below the value threshold parameter.
You also have the margin iterations. This value dictates how many leaves will surround an active leaf. An active leaf is active on if its value is greater than the value threshold. You need at least one iteration to allow your volume to expand out, otherwise it will just collide with the boundaries. Think of this as a buffer zone around your sim to let it move around more freely. You would increase this value past 1 in situations where your simulation is so fast it could potentially move across more than one leaf each time step.
Then you have the leaf size. This value indicates the dimensions of each leaf which is the smallest data element and holds the individual voxels. The leafs defaults to 16x16x16 (16^3) voxels. If your simulation is very high resolution you might consider increasing this value to ease the load on the data structure. You can start to feel the effects of a large number of leaves once you get into the 10s of thousands of leaves in a simulation. Increasing the leaf size will normally decrease the total number of leaves in your simulation thus easing the load. The draw back of this is that the sparse data structure is less fine around the boundaries and there might be more wasted space. Conversely, you may want to lower the leave size if you have a lower res simulation to maximize memory efficiency.
Next you have the levels parameter. PSEUDO uses an octree which is a hierarchy structure for storing data. The levels number indicates how many hierarchy levels the octree has. If your simulation is very large you may consider increasing this value to speed up octree lookups. You can tell if it can be more efficient by looking to see if the number root nodes exceeds 8 in your simulation. Look to the console printout when in debug mode to see the details of your data structure. You can enable debug mode under the solver setting tab. See below for an example of what this printout looks like. More than likely you will never need to worry about this, but just in case you have a really massive sim over a very large area keep this parameter in mind.
Under sparse you also have the velocity sample type. I would always leave it on face. The reason why could be an entire separate page.