How do voxels work in a smoke simulation?

From what I have read, voxels are like 3D pixels that when put together can form shapes (like in minecraft).
What I am curious about is how voxels are used for the smoke simulator? I’m guessing they make up the shape of the domain which the smoke is in, but how do they convey volume? Is their transparency changed based on the shape of the smoke? Why does the smoke not appear to be made of semi-transparent blocks? Also what does the division resolution of 32 mean (voxel-wise) and what does the high resolution smoke do (divide (voxels)^(high resolution amount)?).

Thanks, I wasn’t sure where else to post this forum-wise, if there is a more suitable area could an admin please move it.

Any links to explanations would be greatly appreciated as at the moment I’m a little confused :confused:.

Yes, the simulator propogates a fluid simulation through the voxel grid, and each cell ends up a series of values (kind of like red, green, blue and alpha channels) describing the density of the smoke and fire (blender’s sim more or less treats flame like a second type of fluid), heat of the plume, velocity, etc. You can store all sorts of stats here, some other software has data like fuel mixture or pressure.

It does if your resolution isn’t high enough. BI and Cycles can also interpolate between blocks to help smooth out the look, something that doesn’t really work with minecraft structures.

Base res means the domain is cut that many times along each axis, the res=32 means there is a 32x32x32 cube of voxels. If the domain is non-square, only the longest side(s) will be equal to the res, the other sides will be truncated to keep the voxel square. So if you have a 2x2x1 cube, res-32 means a 32x32x16 grid.

High res cuts each cell along all 3 axes for each high-res division. So final res = baseRes + highResbaseRes. base=32 with high-res=2 gives 32+322=96. High res then applies some magic to smooth or fluff-up the plume at the new res.

Technically speaking, we have one grid containing multiple fields (or channels for the pixel analogy). I’m not going to go in great details about the current gaseous fluid solver algorithm used in Blender, but we one have field for the density (aka “density/smoke field”), multiple fields for the smoke velocities (“velocity fields”, one field per axis, plus some for the emitter’s velocities), one for the vorticity, one for the heat, some for the colors of the smoke/fire (which end being the colors you see in the viewport), etc… So no, the solver does not “more or less treat flame like a second type of fluid”, there are some fields to describe it, namely “flame”, “fuel”, and “reaction”.

The voxel’s values are stored at different locations depending on the field: the density is stored at the center of the voxel, while the x-axis velocity is stored at the x-axis voxel boundary, and so on.

Some rather computationally expensive operations are done on the various fields, in a specific order, but in the end we’re only interested in the density field, as this is the one we end up rendering.

Still technically speaking, each high res level multiplies the number of voxels by 8.

Whoops, thanks for the clarification.

Can I ask though, if there is only one density grid/fluid type, why does the “density” attribute in Cycles not return anything from the flames? If you set smoke from flames to 0, the density attribute contains nothing at all. Which is part of what gave me the impression that “flame” marked a “fire fluid” while density marked a “smoke fluid”. Which seemed further reinforced by the fact that the emitters types are “smoke”, “fire”, and “smoke+fire”. What’s going on there?

Usually, especially in literature on the subject, by density it is meant the “smoke field” (aka “density field”), this is mainly due to the fact that gas solvers are simulating smoke, steam or mist. In Blender’s code the smoke is actually named “density”, because the solver would only simulate smoke at first, fire was added in a subsequent GSoC, if I’m not mistaken. The names of the attributes in Cycles actually come from the names in the file I linked, thus you have “density” for the smoke, “flame” for the fire and “color”, well, for the color. Then I’m not too familiar with how Cycles gets things from Blender, but that’s the gist of it.

If you set smoke from flames to 0, the density attribute contains nothing at all. Which is part of what gave me the impression that “flame” marked a “fire fluid” while density marked a “smoke fluid”.

With the “smoke from flames” setting you set some smoke in the density/smoke field based on the flame field (and the associated ones such as the heat field).
As already stated “density” -> smoke field, “flame” -> flame field.

Which seemed further reinforced by the fact that the emitters types are “smoke”, “fire”, and “smoke+fire”. What’s going on there?

“smoke” will take into account the density field, “fire” will take into account the “flame” field, and “smoke+fire” will consider both. Those names (“smoke” and “fire”) are just set for the interface.


The biggest thing to note here is that I’m not too familiar with certain aspects of the smoke pipeline in Blender, by which I mean the way it is coded. Although I do know some implementation details, I did implement a basic fluid solver once and it is my attempt to some day contribute code in this very area, I hope I’m not really confusing anyone here, since I’m also a little confused by the code at some point, though I already figured quite a piece of it.