

If you are using the file output node, you would have to put //myFile/v01/ in the base path for each layer, and then remember to change the version number when upversioning your. I’m going to begin with an example of this solution: B) an out of the box viewable image, but with no crypto available (or, if it is, I couldn’t find the way, and so it would be, in the least, a convoluted way).A) a black image with semi-usable crytpo (because the metadata is not fully compatible namingwise, so you still need a modify metadata node in nuke).BUT! The output file node produces cryptomattes that are not recognize by Nuke because all the metadata is “mushed” together in a single list instead of multiple metadata entries, so you cannot modify them because you cannot access them individually Which is particularly upsetting, because the obvious solution would be to use the compositor instead and name the channels at will, right?.

If you render a simple rgba multilayer EXR with a bunch of channels in it, the “Combined” image, as it is named by blender, will appear black in Nuke, because it expects a channel named “rgba” instead. And when dealing with multilayer exr, it causes issues. But in the output panel you cannot do that, tha output channel names are hardcoded. One example: In the file output node, you can rename the channels to accomodate a third program input requirements, like Foundry’s Nuke. I think a better way to approach this would be to make it more abstract, allowing the users to put in “tags” (I don’t know the proper name for it, sorry), that could be defined per project/blender file (I think the preferences would be a good place to do it), and that at writing time woud get replaced with the actual informationĢ.

That behaviour is prone to human error and leads to overwriting valid renders when versioning up. The paths are literal (even if they can be relative to the blender file path, the subfile structure is still literal), you have to type in the name of the files/folders, or navigate to it. MORE FLEXIBLE NAMING SCHEMES FOR OUTPUT RENDERSĪt its current state, the blender does not offer the flexibility to define valid paths and naming configurations to be really useful when you have to generate multiple iterations of a blender file. Lack of consistency between the two ways of approaching it (compositor nodes vs properties panel’s output options).ġ. It needs to offer more flexibility to be really convenient. The naming of the file/layers/filepath/metadata is too constrained to what the program assumes is a logical naming scheme, but it is not always the case, since every production has different needs. To me, there is 2 main issues with how the output of a file currently works: However, if I save a new version of the file I’m working with, I have to go and change the basepath for all the layers, otherwise I end up writing over the previous version. I tend to use the compositor file output node to render the multiple layers that I usually need. (sorry if anything that I write here sounds harsh, it is certainly not intentional, english is a second language to me). I would like to suggest some changes to the file output naming and metadata options that I find inconsistent, inconvenient or even broken nowadays. If that’s the case, please point me in the right direction. How do set up my scene so that it renders the render layers correctly while also displaying correctly in the viewport?Īttached is the passes from my latest render.First of all…sorry if this is not the place for this. Is there a recommended way of doing renderlayers in max? For example, if I create a daylight system, the image is completely blown out unless I use the exposure control. Am I doing something wrong or is this a bug?Ģ. Also, when rendering AO for example, the output is unusable unless I render to layers, which is kind of unnecessary.ġ. This isn't a huge problem huge problem since I'm comping together the passes to make a new RGB anyway, but I'd like to have the alpha, and also the thumbnail displays the messed up RGB so it makes it harder to orient oneself in the comp tree. However, with the release of 2014, the default RGB-channel - the beaty pass if you like - is completely messed up when I render to exr. It usually turns out reasonably well, as long as I leave the mr Photographic exposure control to 0 or disable it altogether and dim my lights accordingly. I've been trying to render passes from 3ds Max in the diffuse-indirect-reflections-spec-style with mental ray.
