Speed up smoke simulations

[Lyonz]

Hey all,

Am wondering does anyone know how to speed up smoke simulations in H12 ? As I am currently working on a sim with a division size of 0.5 and 100 frames is takes approximately 15minutes to cook. Thought there may be a way to put more stress on the cpu similar to increasing the tile size on mantra when rendering.

Cheers

Lyonz

[woodenduck]

That sounds like a long time??? Can you post a hip file??

[Lyonz]

That sounds like a long time??? Can you post a hip file??

Unfortunately not at the moment,until then any ideas ?

[woodenduck]

How big is the container? What is the source geometry like? Have you looked in to clustering?

[eetu]

If it's plain old smoke, have you tried toggling OpenCL on in the solver?

[Lyonz]

If it's plain old smoke, have you tried toggling OpenCL on in the solver?

Yea tried using the opencl but getting similar rendering times.

[aghourab]

Yea tried using the opencl but getting similar rendering times.

Its really a matter of your setup. There is no magical way to speed things up. But there are some tricks to get the overall process out the door quicker.

For starters make your lowres lower. You want to dial it down to the point where its simply the abstract of your intended final result. Don't worry about details at this point, you can get these back later in the upres, so long as the overall motion, and volume are what you intend. I also usually unlock the solver and copy disturbance to the upres solver just to add some extra details.

Clustering is always more difficult with smoke than it is with fire because smoke is slower, lasts longer, and encompasses a greater region. If you do go the clustering root, try clustering in the XZ plane, and not Y (unless of course you have a lot of vertical distribution). This allows smoke to build up naturally as it travels up, and reduces the overall scale of the containers you work with.

Is resizing working for you? That can also save a lot of time. Turning down substeps (this may cause artifacts, but you can worry about that latter when you want to do a finalish sim). In the solver there are different advection systems to choose from (Advanced -> Advection). The default Modified MacCormack is actually the most accurate. But changing it to single stage may be quicker AFAIK. Change Advection method to single step as well and see how that works for you. This will take away from the sharpness and accuracy of your sim, but if its speed you want...

[Lyonz]

Think i will ride out the waiting time and see what i get, since i want to see some details in the smoke.

Cheers for the advice

Lyonz

[old school]

This may sound stupid but did you try the Performance Monitor? It's the first place I go when I want to debug performance issues... (seems to be a perfmon day)

One slow-down that can occur is in SOPs calculating the various volumes (sources, colliders, pumps, sinks, etc) supplying the DOP sim. Perfmon will definitely find these out.

[md5]

division size of 0.5 doesn't mean anything without knowing the dimensions of your container

would be better to give voxel dimensions, eg : 500x800x900

also by "rendering times" do you mean "simulation time" ?

Edited August 29, 2012 by md5

[ikarus]

You can turn off calculations of extra fields like heat/burn/temperature if you aren't using them in your simulation.

[Lyonz]

Have now fixed the simulation speed issues i was facing, by writing them out locally instead of through a network.

However have noticed that once i get a decent simulation at .5 and then increase the division size to .2 my simulation completely changes, why is this happening ? all im after is more detail ? Does forces need to be doubled when adding double voxel detail ?

Cheers

Lyonz

Edited August 31, 2012 by Lyonz

[cubiccube]

If you're after detail, try using the upres node (setup with the upres shelf tool)

[Lyonz]

If you're after detail, try using the upres node (setup with the upres shelf tool)

Thanks for the reply this works really well.

I'm still interested to know though, why increasing the division size on the smoke object changes the simulation so dramatically ? Its as if the simulation gets heavy, however doubling forces doesn't achieve the same results as the low res.

Cheers

Lyonz

[loudsubs]

Hard to tell without seeing your hip file. Usually the sim should overall stay the same though, hence the workflow of getting a "base look" at low res before doing an hour long high res sim.

One thing that can change a sim though is when you are using disturbance (in the shaping tab). If you use "block size," the detail should stay similar when you change the res of the sim because it's based on world units. But if you are using "locality," it creates the disturbance based on the number of voxels. So locality of 4 will create disturbance based around 4 voxels. So the look can change quite a bit based on how fine of detail you res up to.

[aghourab]

Thanks for the reply this works really well.

I'm still interested to know though, why increasing the division size on the smoke object changes the simulation so dramatically ? Its as if the simulation gets heavy, however doubling forces doesn't achieve the same results as the low res.

Cheers

Lyonz

Its only natural that changing the resolution will affect the sim.

Say you increase the resolution by a scale of two, the one voxel you had previously was an average of the 4 voxels you now have. These 4 voxels may have different densities/velocities than the averaged voxel you had at a lower resolution. How dramatic a change in the sim depends on your source and dop setup. Difficult to tell without a file.

I imagine the change wouldn't be very dramatic if you had a low resolution source. Like Arrev mentioned, use the upres solver to avoid similar issues.

From left to right a)High res source, Hi res sim b)hi sim, low sourse c)low sim, low source d) low sim, hi source. Ive attached a file that demonstrates this.

smokeResTest.hipnc

Edited September 4, 2012 by aghourab

[eetu]

Another small thing would be to disable caching to disk. While developing the sim, it can be very useful to have a cache of the whole sim even if it is not in memory, but for raw sim speed it can slow things down a bit more than one would think.

Here is a screenshot of my first starting a sim with caching to disk enabled, and then the same sim again with cache to disk disabled. You can see how, after a dozen frames or so, the mem cache gets filled up and it starts to move the cache over to disk. The effect on frame time looks like 25% or more, and this on an ssd, mind you!

[anupamd]

I've always found that the simming at high rez straight away produces better results especially for large scale effects. (would be curious to hear opinions of the other studio guys here) Also I almost never use resizing as it also tends to generate wierdness especially for fast moving smoke. I dont use OpenCL but I have heard that sims will go faster if you dont resize (when using OCL)

Obviously this comes at a cost of sim-time and I guess its not going to work if you dont have a beefy farm.

Not that Im ranting as I've "figured out the formulas" for optimizing sims but for the newbie its not obvious. Other tools such as FumeFX makes some optimizations behind the scenes that you really cant control, but for the average Joe it gives great results that run fast. SideFX needs some improvement in this area to make it a bit more approachable for more artist/non-TD types. I imagine most mid-large studios have Senior TDs developing simpler user friendly OTLs for the rest of the shot TDs to use.

- Anupam

Another small thing would be to disable caching to disk. While developing the sim, it can be very useful to have a cache of the whole sim even if it is not in memory, but for raw sim speed it can slow things down a bit more than one would think.

Here is a screenshot of my first starting a sim with caching to disk enabled, and then the same sim again with cache to disk disabled. You can see how, after a dozen frames or so, the mem cache gets filled up and it starts to move the cache over to disk. The effect on frame time looks like 25% or more, and this on an ssd, mind you!