R19 multipass automatically outputs an rgb pass


We’ve noticed since using R19 that if multipass is activated, c4d will render a redundant rgba pass whether checked or not.

Anyone else confirm?

Is this a new “feature” or a bug?


That happens for me even in R18 - seems almost impossible to stop C4D from making that pass.


Strange–I’ve never seen this happen in 18. Not for any of the guys working with us either. Its only showed up the past week or 2 since we switched to 19.


The other thing is that it outputs the rgb pass but that pass does not show up in the picture viewer layer tab with the other multipass assets. Like a phantom pass.

It also happens just with the multipass box checked, even if there are no multipass elements added in the render settings.


Just tested again in R18.

R18 does not output an rgba image pass unless checked in multipass.
R19 outputs rgba whether checked or not.


A general question about the rgba pass

Besides the ability to blend an alpha into the output, is there any other purpose for rgba?
Reading another thread on the subject and although it was my understanding that rgba was the beauty pass minus AO or other additional passes, it seems like the rgba pass is actually no different than the beauty pass. AO etc are merged into both rgba and beauty. Is this correct?


Noticed the same recently, using R19.


To me RGBA is just another beauty pass, except that you can give it a different bit depth/folder structure than the original one.


Thanks guys

Maxon TS is investigating.


Havent checked yet but can anyone confirm if this issue has been fixed?
ie: multipass outputting a redundant rgba pass that was not wanted?


Still a problem for me with on the new 19.053 - and now it seems worse actually.

If I specify a destination folder outside of the folder the C4D file is in then TR just dumps all the PNGs in the root of the folder that contains the C4D file and ignores the specified file path.


Yep, confirmed here as well. Frustrating.


you guys confirming the redundant rgba pass or something else?



Confirming the RGB pass output despite being shut of.


Thanks Troyan

I have emailed TS again. Last time I was told that maxon was aware of the issue but it hadn’t been identified as a bug. This was a few months back.


While we’re on this subject of the object buffer, I’ve always wondered 2 things.

Why does it have to calculate the rgb pass to output a buffer?

Why can’t buffer maps be added to the alpha channel on output? This would be incredibly useful and timesaving.


If you set up a Buffers take, and create a render setting for it with material override in play, no AO , and geometry AA, and make the ‘buffer’ objects white luma in that take, even though it’s still calculating the RGB pass, it will do so with the speed of a buffer pass, and can be a real time saver for instances in which you need a new piece of your scene buffered in an otherwise already fully rendered scene…


That’s a great workaround, but I still don’t understand why you have to take those steps. Why can’t it just calculate the buffer?


Strange that some parts parts of C4D seems to have been designed by an alien completely foreign to the ease of use of other parts.


I think you can if its a layered exr?

I believe team render can only output a total of 4 channels per file rgb and a.

I may be wrong.