pencil2d / pencil

Pencil2D is an easy, intuitive tool to make 2D hand-drawn animations. Pencil2D is open source and cross-platform.
http://pencil2d.org
GNU General Public License v2.0
1.45k stars 272 forks source link

[Feature Request] Memory per-Frame "Cache & Release" #965

Open Jose-Moreno opened 6 years ago

Jose-Moreno commented 6 years ago

--Issue Summary--

Various users have been complaining on recent issues with long-er animation projects that are failing to be rendered. I investigated and found that Pencil2D eats your RAM memory (at least on windows) when trying to render export video or image sequences.

With this in mind I'd like to propose to model a feature similar to one found in After Effects. This would depend on having caching system for our animation frames and / or our layers as a whole, as well as a purge system to "liberate" the memory that's being used by Pencil2D resources.

Here's a brief explanation an After Effects user on how these reference features works in after effects:

A)"Disable Layer Cache: This tells AE not to retain layer information during it's renders. "

Note: It's use case is that if you edit one layer our of many, only that layer with change in the cache and when you render "previews" you won't have AE caching all the layers but only those that were modified.

B)"Purge Every X frames during Make Movie:

This tells AE how often to purge its memory. The smallest allowable number is 1 - which means AE will purge its memory at each frame. The smaller the number the less likely it will be that AE will face a memory issue. The trade-off is that at smaller values, your renders will be slower, as occasionally, stuff will be purged that AE still requires. Under such circumstances AE will have to recalculate that information again - purging also takes time."

This is important because the most common pitfall I've seen from users that experience rendering failures, is because they don't have top grade hardware. And even if they do, be it with Pencil2D or with After Effects, there's a moment when the memory becomes full and the process cannot continue, so the application either crashes, or else.

Programming wise I have no idea how to implement this, but by having a purge system along the mem cache implementation we could simulate how the feature works, and similar to AE it should be a feature only to be used with longer animation projects.

This is a feature that is used in real-world scenarios and productions when rendering projects, because no amount of optimization will help you when your project is big enough and you don't have access to a render farm or 32 gigs of RAM to render solo.

Would love to hear your thoughts on this later on.

--Video or Image Reference--

image This happened when I rendered file with 800 frames and also 4K resolution. This was the amount of memory being used just at 9% of the export operation, and before I canceled.

scribblemaniac commented 6 years ago

As of #1038 the should be fixed. The frames are purged after every 200 frames, and this does fix the excessive memory usage during export*. @Jose-Moreno Can this be closed now?

* During animated GIF export, ffmpeg will keep all frames in memory. The alternative to this approach more than doubles the rendering. This has been discussed before. Given that GIFs are usually reserved for smaller animations, the current option seems like the best choice. Some code to automatically determine which approach is best based on the expected memory consumption and the total memory available would be optimal, but that would require platform-specific code and plenty of work for a rather low priority.

Jose-Moreno commented 6 years ago

@scribblemaniac I'll test it out and I'll update this issue accordingly. Thanks!

Jose-Moreno commented 6 years ago

@scribblemaniac @chchwy Okay I sort of stress-tested issue 1038 with that huge file we got last time from it (The 4K +1000 frames long one). There was certainly improvement as the program was responsive for a bit longer than before during export, but still it is not ideal. At least it consumed more memory before becoming unstable forcing me to close the software. (This time it consumed up to 6 gigabytes before windows started to misbehave, and It didn't even register my PRNT SCRN command from the keyboard hah)

The idea behind this proposal however is not to optimize RAM consumption subtly, but rather provide the user with the ability to choose how many frames they want purged after those have been "rendered" (encoded into the movie container after being processed by ffmpeg?). This is a brute force kind of thing, because I know it's rather difficult to optimize even though chchwy already profiled and helped reduce the memory footprint (hence the improved responsiveness during export).

In After effects I have the automatic purging set for every 15 frames, or else most projects I deal with would become unmanageable at render time, and even then it's just one part of the solution for rendering. I normally have to export to image sequences, have no other programs opened, create a workspace with minimal panels to reduce VRAM consumption due to the using both RAM and VRAM and also have to visually reduce the window size to the minimum size available; Funny thing is this also happens with Blender and it works; I've tried to use the command line renderer but the speed improvements are negligible on large scenes.

So in summary I can't really consider closing this request until the user has the ability to choose the amount of frames they want to purge at the very least. If you want to hide that in an "advanced" section on the preferences I think that's fine, but each project will require different settings and thus user input, The 200 frames magic number might be a good default for most cases with lightweight scenes but we should be able to go to have a minimum of 1 frame purged and a max of 512 or 1024 frames (it's pointless to go beyond that obviously).