0
$\begingroup$

I have a 75 frame smoke sim (Mantaflow- made in 2.82 release version) , with noise baked on it- all good so far. Now- how do I freeze, say frame 75 and have the same smoke, static, for as long as I want? Basically I want to use the resulting smoke trail, as simulated on frame 75, but without any animation and I want it to stay/last as long as I want/need. I’ve tried deleting all the cache files from whatever.0001 to whatever.0074 and renaming all the left over frame 75 files to whatever.0001 (like you could do to fool the ‘old’ smoke sim) and I don’t get terribly much of anything happening smoke wise… any ideas?

$\endgroup$
0
$\begingroup$

I've managed to do it 'work around' style, but my god it's an UGLY way to do it! Basically I copied all the different cache files for the last frame (75 in my case), created another set of cache folders, then pasted 400 copies of the same file and 'bulk renamed' them (fantastic free Windows app!!!) so Iended up with 400 copies of each 'frame 75' file numbered sequentially from 0001-0400. So that's 400 copies of config_0075 renamed to; config_0001 - config_0400 files in the 'config' folder. 4800 density_0001 to density_0400, densityIn_0001-densityIn_0400 etc.etc. in the 'data' folder. and 1200 files similarly in the 'noise' folder. And it works!!! But it's a huge ball ache to do (and 30Gb of disk for a relatively simple sim), so if anyone knows a more elegant way to do it, I really am all-ears!

Cheers! Mark

$\endgroup$
0
$\begingroup$

I had the same problem and tried to address the issue with keyframing the time scale value. I had a problem with setting the time scale to zero (perhaps due to something else) so I keyframed it to 0.001 from 1.000. For reasons I don't understand, even though I 'downshifted', the size of the cache files and adaptive domain size continued to grow at a not-so-apparently slowed rate. Its size in the viewport and rendered images while decidedly slower was not frozen satisfactorily.

In my case, I had a 180 frame total loop of which I wanted the domain to evolve in first 15 and thereafter be frozen for frames 16-180. On my first attempt I baked the first 15 frames and then duplicated frame 15 for 165 copies, renaming them sequentially. (Ditto your kudos on the Bulk Rename Utility, BTW.) I ran into difficulty with the duplicated frames in the cache not being picked up for the 'playing' the 180 frame loop. I'm punching above my weight class in dealing with the nuances of Mantaflow and haven't found an explanation for this. I did come up with a workaround by baking all 180 frames and then discarding 16-180, and substituting 165 copies of frame 15. This worked up to a point. I am now able to see a viewport view of all 180 frames but can only render frames 1-45 without it crashing. (I can render all 180 frames if the domain cache contains only the first 15 (?) steps. The 180 renderings show the domain data for those steps and complete the remainder without it showing.)

Obviously, the crashes may be unrelated but given they happen in both cycles (CPU and GPU) and Eevee I suspect at least some association with Mantaflow. I've run the Blender file in the Windows command terminal and monitored the memory required and the upper demands are well within my system's capabilities. If I render the full loop with the domain present but switched off via the outliner pane, it works properly.

Given this is a workaround in the first place I'm not sure if this is worth pursuing in its current state but thought I'd relate my experience in case others run into a similar issue.

I'm running on an AMD 8-core processor, 32G of RAM and a Nvidia GTX960 with 4G of video memory. I'm working in Blender 2.90.1 but have similar issues in 2.80

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.