Krakatoa _ beta8
Max 2010 x64
Windows XP x64
Hi,
It seems that it is not possible to save multi-channel EXR with krakatoa passes. Is it a known limitation ?
I’m not exactly sure what you are talking about 
Is there supposed to be some way to save the render elements in a single EXR? If so, can you point me at the docs regarding that (assuming there are some) so that I can make sure we handle this like other renderers do.
Sure!
this was part of the Autodesk connection extension on max 2010 + native on max 2011. If you save as EXR , and check setup on file dialog then you can add all the elements easily in one exr. This is how we have been working the last year.
You can either choose which passes , or you can simply check the "Automatically add/remove render Elements from render dialog "
It seems that krakatoa does not support it at the moment! would be great if you could add it in.
We have not rolled out that Extension in our company because many of our tools depend on the old Splutterfish OpenEXR output and we cannot break the pipeline in the middle of a project. Obviously, Max 2011 uses it and being Cebas technology, it has its own set of quirks we will have to deal with when the day comes. Also, even when VRay added support for multi-layered EXRs, we decided not to use them because at the time we were using Fusion and it was a lot slower to read one huge file than a few smaller ones (and only the ones needed). AFAIK, even after switching some projects to Nuke, we are still producing separate files for render elements.
In short, we have no experience with this technology yet, and there is a chance the new OpenEXR I/O wouldn’t know what to do with Krakatoa render elements. We will look closer at how it works and check if it is able to include the dozens of VRay Render Elements. If it works with VRay but not with Krakatoa, then it could be our fault. Otherwise, it might be a limitation of the I/O plugin and we will have to talk to Autodesk or Cebas.
Thanks for the pointer…
Yeah, multichannel EXR is almost NEVER a speed gain. Users of RPF can attest to the misery encountered there. It only really makes sense in a compositing package where generation of the passes is trivial. Here, with Krakatoa, if you were to save out a 230MB EXR with a whole slew of channels, then load that 230MB into Fusion or Nuke, then find out that one of them is wrong (like you had the wrong texture coordinates or something), you have to rerender ALL the elements again and dump out another 230MB, load that 230MB back in to the compositing package, invalidate your existing cache, etc.
But if you used the current workflow, with one EXR per element, you are just going to rerender 15MB of data, reload 15MB, and the remaining elements will still be valid in your comp, no need to re-render them.
Lots of people have benchmarked these two approaches in Fusion and Nuke, and the results almost always show them being nearly the same speed for the first read, but then the multichannel falls apart during iteration. So there’s no upside, but lots of downside.
The multichannel workflow, in my experience, makes as much sense as rendering directly to tar. It’s convenient in theory, but when has a real production ever been just a single iteration?
I’ll get off my pipeline soapbox now.
- Chad
Sure!
We have been using it for a long time now and kind of learn where to use it and how to control it. Where it makes sense and where not to. of course we are not rendering everything as multi channel EXR but they are applications where it does make sense to some degree, if you build a pipeline around it.
VFX pipelines are becoming much and much custom and every house has it’s own preferences.Yeah I do agree, it does not make sense to render every krakatoa scenario as multi channel EXR. We work very closely with ILM and in the practical production they are a lot of benefit with the multi channel EXR once you build the right hardware and software pipeline around it . 
The intention was mainly to report a bug for a better integration.
Cheers
In the case of the Deep Opacity Shadows, where the additional channels are dependent on the first one, it makes a lot of sense. But Render Elements (the way Krakatoa is using them) doesn’t make as much sense. Save out the EXR’s independently, then combine them in the comp (especially useful for archiving).
Because Krakatoa is memory and I/O bound, we often have to bake down PRT’s to manage the per-particle data load. Because of this, we HAVE to render out separately anyway. Storing all those elements per particle in RAM for rendering is painful if you don’t have massive amounts of memory (depending on complexity). We often CANNOT render a beauty pass at the same time as a mapping02 pass because we can’t fit it all in memory at the same time. So we have to save the mapping out to an EXR, then back the beauty pass to emission and rasterize that by itself. My experience with Krakatoa (which is probably unique, I admit) has been that you are constantly iterating the PRT’s to get the right effects in the target memory budget.
Though the new workstations we have with up to 96GB will help…
I agree that it’s a bug, but I’m just pointing out that the workaround is better than the fix in real-world productions, even if you use Nuke.
- Chad