Volume direct, Volume indirect, Volume color - It’s surprising that the Blender devs. have not as of now even considered adding this, as it seems to be too basic a thing to just leave hanging. Strangely enough, it’s not a common request in this forum either.
Reflected / Transmitted Normal, Z, and Color information - Pretty much needed if you want to have advanced user-made denoising setups made with ease (as seen with it being needed for renderman’s new algorithm). Also important if you wanted composited effects to apply to everything seen in the image and not just with camera rays.
My ideas for now, when you composite, what do you feel is missing still?
I do not know much about compositing, so I will learn here with what people say.
I am interested in everything related to noise reduction with good preservation of the edges.
The world position coordinate of the geometry node is absolutely useful. I can’t make good compositing without it. The generated coords should be nice too. (this is possible but need extra render)
Also, a little bit like your second point, the Z, normal etc of a volume shader doesn’t give Z volume, but the Z of container.
The main problem here is that pass information is stored in two bitflags (On the Blender side: “srl->passflag”, on the Cycles side: “enum PassFlag”). Blender’s flag is already full, Cycles’ flag only has 3 bits left.
Apart from that, there are a few passes I’d like to see:
Volume Direct/Indirect is a good idea, Volume color is hard because the color can change in the Volume. I’d rather go for Transmittance from the Camera to the first Surface.
Additional info like Normals or Color at the first non-specular bounce (mavbe even with a controllable roughness threshold)
I don’t remember something being said about AOVs from a developer - forgive me if it has been mentioned already - @Lukas, do AOVs sit somewhere on the roadmap or not yet ? VincentG was talking about world posiion etc. it’s easy to have them as separate passes but like he said that means an extra render.
Currently it is 32 bit (4 bytes, the size of an integer), we can’t use something else here as then it would dependent on the architecture (32 or 64 bit).
I was going to suggest this as well. Custom passes would remove the need to directly add some of the more obscure ones, and give a lot of extra flexibility as well.
In addition to some ones that have been mentioned in this thread already, I’d also like a debug pass for render time. (pixel value = render for that pixel in…some unit…seconds? 1/10 seconds?)
It should be no big problem to switch to 64 bits, types like uint64_t are guaranteed to be 64 bits long even on 32bit platforms.
This is just a workaround, though, and doesn’t solve the real problem, which is that passes are hard-coded at many places. This makes things like AOVs impossible with the current code.
So, a redesign of the pass system would be needed, but that’s a quite big project. Actually, that might be something for 2.8.
I remember having some issues with using a different type when I tried to add some new passes quite some time ago (nothing serious, more like an exercise to lean Blender’s code base). Some types are not allowed in the DNA, but I’m not sure about what I was using. (uint64_t should be ok, and I think it’s used in a couple of places.) Anyway, the pass system needs a rewrite indeed.
Interesting insight, I had no idea that the issues with how Blender handles pass information in general run so deep.
So does Blender then have a general pass handling system that is used by both BI and Cycles (since implementing the suggested ones aren’t as easy as one would think)?
Also, is it at all possible to simply have more than one buffer for all of the passes (one for the lighting and color passes and one for the rest)?
Generally the pass stuff is part of the Render API, and therefore passes are also part of the Blender DNA. This is a problem: The Render API is supposed to provide abstraction for renderers so that the core of Blender needs no changes, but since passes are in there, external renderers like Lux can’t provide their own passes in Blender.
I assume you mean separate bitflags? Yes, that’d work, but there are multiple issues there:
Compatibility: If you just split up the passes, older versions won’t be able to read newer .blends
Eventually, you’ll run out again - we already have at least 8 suggestions in this thread, and there’s so much potentially interesting stuff to export in passes
That still doesn’t allow true AOVs - the pass list is still hardcoded
Renderers still need to modify the Blender core to support passes
Generally, that’d be a hack that works for now, but you’ll run into more problems sooner or later.
One example of a flexible solution would be to have Passes as own data objects, and every RenderLayer would store a list of Passes, like scenes store a list of RenderLayers. However, this is also not perfect in every regard, so redesigning this would require some planning and consideration.
So what is an AOV and how does it differ then from a traditional render pass? How much of a project would such an implementation be and is it even possible?
I always assumed it was more or less the same but apparently it isn’t.
Well, a true AOV (Arbitrary Output Variable) would be the possibility to add an Output Node to your shader, select which pass it belongs to and just put any value you like in there. Often, stuff like Cycles’ Normal or UV pass are called “AOV”, but it’s not really arbitrary…
Would it be possible then to simply ax all of the internal pass handling code on Blender’s part and instead turn it into a function of the render engine, which then produces the information via a temporary multi-layer .exr file?
Basically, much of the renderlayers context becomes a simple command panel which passes values (via Python or otherwise) to the render engine in question. The Render Layer node in the meantimes goes to simply reading the .exr layers to produce the output sockets (which the only thing that Blender needs to do is save them indefinitely until the layer information changes).
Blender would probably still be in charge in creating the different render-layers though, but not so much the sockets.
A matte pass. We need a working matte passes without artifacts like jaggy edges… No need to invent bicycle or 256 jaggy matte passes in one 32 bit channel. Just plain standard matte pass vray/mentalray/arnold… etc have
This would be really useful : not only the solve the mask artifacts issue, but also to blend Cycles render with other render engines that also have deep support (almost all of render engines now). This would allow to bring Blender in any studio without breaking their current workflow. The people who don’t know what’s deep image, basically, each pixel can store multiple values in any depth. It can be used for example to render a smoke without objects that occlude it and then, in compositing, put it in the foreground, background or in the middle and the holdout mask will be generated on the fly. A little bit like the Z Combine but in much much more accurate. So, this is perfect to mix Arnold or V-Ray renders with Cycles without any problem and you don’t need to import your animated meshes to mask things.
It can also generate ID mask or gradient with no artifacts at all even with a strong motion blur.