Forgive me if this is a silly question, but does Krakatoa support Deadline’s tiles rendering mode? My first test today seems to be saying no.
Any other ways to achieve similar results? (Blowup region rendering, etc?) While I realize the particles separate at higher resolutions, I was looking to render something really wide and was running into memory issues trying to render it all at once, so was exploring other options.
As you found out, Krakatoa does not currently support region rendering.
The problem with the large scale output and memory is that in its current version, Krakatoa allocates one frame buffer for each thread (core, CPU). While this allows us to draw much faster in regular resolutions, it can eat up a lot of memory when the resolution is, say, 20K.
One way to work around this is to disable the Multi-Threaded option for drawing particles. Look under Preferences > System Preferences. This will make the actual drawing of the particles into frame buffer run on a single thread, but only one frame buffer will be allocated. You could also disable the Max Rendered Image viewer to further reduce the memory consumption. Obviously the drawing will be slower, but you might get your image in one piece that way.
We are looking into supporting a thread limit (in fact we started looking into it yesterday). So in the future you might be able to limit the number of drawing threads to 2 or 4 if you have 8 or 16 cores to tweak the performance vs. memory usage in these extreme cases.
I will leave it to the Krakatoa developers to decide whether region rendering would be possible to implement. I think there is an issue with the way particles are drawn over multiple pixels and blended with the previous particles when in Particle mode (as opposed to Voxel mode) which makes it hard to impossible to support simple tiling. Using a significant overlap between the tiles though (which Deadline supports), it might be doable.
Excellent information Bobo thank you, It looks like disabling the multi-threaded drawing and Max’s render window was able to get me the image in one piece successfully, so I’m good for this one. Thanks for the detailed info.
If it’s just a matter of not generating dozens of frame buffers for memory conservation purposes, maybe have the user set a limit on the amount of RAM to use? So if they are rendering 4K images, it makes 4 threads, but if they are rendering qHD, then make 64 threads?
The real problem was that earlier versions of TBB did not let us change the thread count after the fact. We could set it, but not reset it. Looks like the last version allows this, so yesterday we posted a first build of Krakatoa SR with threads control.
Now that this is possible, we could talk about smarter ways to employ this manually and automatically in the future.
For Krakatoa 3, running within limited memory space is a big goal.