Why does fire take so long to render?

Question

This is actually more of a general question, but why does fire take much longer to render despite baking? I've done a lot of reading about fire/smoke simulations and liquid, and even at only 128 resolution (for the fire domain) and 500 samples (at 1920X1080 and 50% camera resolution) each frame of my scene takes about 30-45 min to render with a Nvidia GeForce GTX 860M GPU. It's not so much a complaint as wondering if I am missing something or if this is just the way it is? Hopefully this could help others who are working with fire/smoke simulations as well.

If you require screen shots or more info let me know.

Thanks!

Answer 1

Because fire is a volume, and volume rendering is slow. First of all, the baking you did doesn't help with rendering, it just caches the simulation itself. Anyway, the problem with rendering volumes is that you can't just sample the shader once at the surface like you can for solid objects. To render a volume, you need to evaluate the shader and sample what light is available multiple times along the transit through the volume. The finer the detail in the volume, the more steps you need to sample. The distance between steps in controlled by the "step size" attribute: The distance is in meters, although the property doesn't show as distance for some reason. You don't need a step length any smaller than 1/2 the size of the smallest volume detail. For a smoke/fire sim, that would be the size of your voxels. You can find this for Blender's smoke sim by getting the dimensions of your domain, and plugging the length of the longest size into the formula: voxel size + length / (base res * (hi-res level + 1)). So a 10m domain with 80 res and 2 hi-res divisions would be 10 / (80 * (2+1)), or about 4cm.

There is also a "max steps" option you can use to force it to stop at some point along the path, although I'd recommend avoiding this control. Running out of steps mid-volume can potentially give some weird shading.

Additionally, if you're using the volume scatter shader, rays can be scattered (aka deflected) during the volume transit. And if your volume bounces is set greater than 0 under render settings > light path? That scattered path can scatter again. So higher values for volume bounces can increase render times a lot. Too few volume bounces can lead to dark volumes, especially for highly reflective clouds such as water vapor. You can compensate for this by adding some (more) emission to the volume if needed.

One way you can optimize a bit for smoke and the like is to prevent the shaders from running if the density is below a certain threshold. The node setup looks like this:

If the density is below the value set in the "less than" math node, it will output 0, causing the mix shader to switch to it's second socket, which as no shader. Thus, the volume closures are only executed if there's a enough density for it to matter. Figuring out the proper value for the less than node might take some trial and error.

Answer 2

Firstly simulation baking and rendering are two different steps. Baking a simulation calculates where the smoke is at a given time, rendering turns that simulated data into a visual representation.

Smoke and fire use volumetric data, which is a block of space that adds calculations to the render.

Start with a simple render, from the camera a ray goes out and sees the monkey, then bounces into the sphere and goes off to find a light. How much of the sphere reflects on the monkey? how much light bounces onto it at that point?

Now put a fire in front of the monkey. As the ray is passing through the domain, how much smoke is there? how much fire? how much fire is seen through the smoke? how much of the monkey shows at that point?

That all needs to be calculated multiple times and added together as the ray passes through the domain.

It isn't hard to see that volumetric rendering can add a lot of time to your render.