http://qs321.pair.com?node_id=920366


in reply to Re: 2d animation
in thread 2d animation

Ah, yes, excellent point. I think this will work.

In my early tests, the PNG frame export brought a SAS RAID 0 array to its knees, but if I partition as you suggest, I can easily save 200000 frames to a ramdisk (the render machines have 32GB).

As a bonus, I pretty much get a distributed solution for free. I can chunk and distribute the (small) data file across the render farm, have each machine render 200k frames at a time and send back the small mkv, and then trivially cat the result on the master.

So, it's actually a good thing you posted twice, because I can give you two richly deserved upvotes. :-)

Replies are listed 'Best First'.
Re^3: 2d animation
by wanna_code_perl (Friar) on Aug 20, 2011 at 09:28 UTC

    Thanks again to everyone who replied.

    I was able to easily modify the graphing routine to output frames to a ramdisk in configurable batches. The Perlmagick-based output loop is able to output frames at about 720fps on our render machines (dual Xeons with 32GB RAM). Every 10000 frames (batch size--within reason--didn't make a significant difference), I just call a sub that runs ffmpeg, which encodes at about the same rate. Therefore typical 29.97 project encodes at about 12x realtime.

    Everything is still single threaded, and I haven't optimized anything yet. I will probably tinker with the old thread code and the FFmpeg library for interest's sake. But 12x is already more than good enough for our needs (1/2x would have been acceptable), so I plan to keep it simple.

    Even at modest bitrates, lines are sharp and artifacts are barely perceptible, if at all, to the technicians who look at these graphs/videos for a living, and do not affect the ability to interpret the data whatsoever.