Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Maxon Cinema 4D Different Glow in Editor vs. Picture Viewer

  • Different Glow in Editor vs. Picture Viewer

    Posted by Ryan Kehn on July 25, 2017 at 9:05 pm

    Hello all,

    Have an irritating issue with a scene file with some material glows applied to some objects. When I preview the render in the editor, everything looks great. When i render to picture viewer, the glows are muted and have a harder edge.

    working in r18 at 1920×1080, Workspace is linearized, glow is enabled on materials and object glow turned on in render settings. Saw a few posts about final resolution affecting the glow output, but haven’t found any secret formula on how to adjust accordingly.

    Attached image shows the editor preview on the left and the picture viewer output on the right.

    Any ideas?

    ——-UPDATE——-
    Haven’t solved this completely, but i did find that turning off multi-pass led to the renders in editor/picture viewer to be the same. Not sure why multipasses (object buffers only) would be having an effect on color space. I’m all ears!!

    Ryan Kehn
    Creative Director
    VWSE

    Steve Bentley replied 9 years ago 2 Members · 4 Replies
  • 4 Replies
  • Steve Bentley

    July 26, 2017 at 6:11 am

    Hey Ryan,
    Ya we run into this a lot. Especially when you’ve spent hours tweaking that look in the view port and then run the multipass and no transfer function in the world in the composite will get you close to the viewport look you have gotten used to.

    We used to think this was a c4d dynamic range issue but as you found out if you render without multipass, no issues.
    What format are you rendering to? EXR rendered at 16bit or higher might help as you can really crush things in the larger color space when you comp and pull a killer hot spot out of the glowy things. Also, try having the exr’s “preserve RGB” when they come into your compostiting program and make sure your comp is in 16 bit or higher color space.
    You didn’t mention if you were GI rendering or using a thirdparty engine.

    Personally I think this is caused by the way the internal composite engine works vs the transfer functions (screen, add etc) in the external packages when using multi pass, and the fact that the internal engine can combine everything before it has to pick a color space, but when you make a multipass each layer has to be “set” to a dynamic range – at least you are off to a good start with linear, although a log version might give you more headroom. We also find this problem with shadows and some glass/reflection/fresnel settings too. So it seems that the internal engine is better (or at least different) at combining light-based-glowy things than another package will do with output layers.

    So try a file format with a larger range (EXR) or try just rendering out the glowy things seperatelty on your own with everything else set to a black texture that will still catch the ambient and reflected glow and then do a composite with a screen blend function – we like this the best as you can often over do the glow in the viewport after staring at it for hours – your eye gets tired and needs more and more glow to make it sexy. This way you can tone it down in the post process (but then that’s the whole idea behind multipass isn’t it!)

    I too would love to know if there is something we’re missing and a proper or better way of approaching this.

  • Steve Bentley

    July 26, 2017 at 10:10 am

    Hey Ryan,
    What version are you running and what platform? Can you set the color mode of your viewport? I have a feeling that (ironically) it’s the linear mode that’s causing the “problem” (ok its not actually a problem). When you multipass, all files are written in linear mode, but I’ll bet dollars to donuts that the viewport is showing SRGB or some other antiquated space. Many of the premium color spaces can’t actualy be viewed directly on a monitor since most screens are 8bit linear (or close to it) so there is always a Look Up Table at work converting the vast range of colors and curves in your files down to something that looks normal on an 8 bit screen. And SRGB is made for the old CRT’s which hardly anyone is running anymore (sniff… I miss my blacks!)

    I can’t see anywhere I can set the color space of the viewport (nor could I find what it defaults to). There is a linear setting for a background image but that’s just how C4D should interpret an incoming image to display in the background for reference. (so you could use a cineon file or exr without converting and c4d will do its best to interpret). But that setting won’t actually affect what a render looks like in the viewport. I just don’t have enough info on what’s going on between c4d rendering, and showing you what it made.

    I have a feeling that with the linear multipass, especially if you use 16bit or above, you have the head room to apply curves to the glow pass in your compositor without it blooming or clipping and you will get something you would be happy with. Try to get there in your compositor without using Screen or Multiply as once they are in the image stack everything below gets slammed down to a lower color space and you loose the headroom you need to make the adjustment in the first place.

    We’ve been trying for a while to figure out a pipeline to use the Acadamy’s ACES format inside cinema, or even Filmic Log encoding. EXR is pretty damn good but…. Keep in mind too that unless you have an interpreting LUT on the composting end (or something similar), while the comp might output just fine, it might not “look” fine while you are working on it. So if you did the work “by the numbers” and ignored odd antialiasing and color shifts it might output to a film recorder and would look perfectly fine, but on your 8bit screen, without some sort of conversion, somethings gotta give.

    One other tip: always use straight alphas when it comes to light effects rendered out for compositing. The renderer creates a bloom of light that extends beyond the alpha area and its the alpha that cuts off the light at the edges and puts it cleanly over the background in the composite. If you use premultiply, then the light effect is rendered on black and the black is passed through the alpha along with the light – technically it’s getting cookie cuttered twice – once in the initial render when it’s compositited by C4D on to the black and then again when it’s passed through the alpha “window” and on top of your background. This is why you will often see a dark halo on light effects comped onto light-colored backgrounds.

    One other tip – rendering out quicktime severely limits your color space options. It won’t even handle a vector motion or depth pass properly in its limited space. 9 times out of 10 when someone is having depth of field issues it’s because they rendered out to a quicktime for that pass (that and the fact that C4D’s depth is just plain wrong out of the box)

    I know that’s more than a simple solution answer but I think you can push and pull that file in your comper more than you think.

  • Ryan Kehn

    July 26, 2017 at 6:12 pm

    Hi Steve!

    Wow! thanks for the thorough replie(s)!! Let me see if I can give a condensed update/response.

    So, first off we’re on r18 on Mac OSx 10.11.6. Same as you, I had the thought to adjust the color space of the viewport but couldn’t find a way to do so.

    To clarify a bit on my end, the multipasses that i have setup are strictly object buffers. I’m not even rendering out an RGBA pass through the multipass menu, just a straight render through the save header. I did notice that changing the output between sRGB and Linear on the main save output rendered the same unfavorable result as when rendering with multipass turned on. It’s strange to me the the regular RGB pass is affected by simply turning on the multipass option, even when i’m only rendering black/white mattes.

    I was rendering with PNGs and TIFFS at 16bit and 32bit (just to experiment). I’ve rarely used EXRs, mostly jsut because i haven’t ever really felt the need. Interesting you mention reflections and shadows…i’ve come across that a couple of times.

    For as long as i’ve been at this, i’m still trying to wrap my head around the LWF and this is honestly the first time it’s really started to bite me in the backside as I usually do most of my glows etc. in post!

    Skipping ahead, I was able to bring the 16-bit linear “multipass” RGB render into AE and apply a curves adjustment that gets me VERY close to how I saw it in the viewfinder. Definitely have plenty of headroom and seems to get me to where I need to be. I’m very accustomed to “getting it close” in Cinema and sweetening in 3D, this is just the first time I’ve had a stick in my craw with C4D not giving what I thought I was getting!

    Thanks again for all the info. I’m going to read back through this some and probably add some more notes/thoughts/questions!

    Ryan Kehn
    Associate Creative Director
    VWBSN

  • Steve Bentley

    July 27, 2017 at 8:49 am

    Its funny how things happen in clusters in seemingly unrealted ways. A friend was having some color/lighting issues in blender today – there’s a very sweet third party solution for those guys. But similar issue to the problem you were having.

    After saying there is no way to tweak the view port – turns out there is – although not on my system, I’m not sure if that’s a video card thing or a versioning issues or what. In the C4D preferences, under View, is the display color profile. And if it’s there you can set the viewport to a number of built in things or link to an external file (i’m not sure if that’s going to a be LUT you link to or what but I’ll look into it).
    I personally don’t have that feature on my system (PCWin 7 R16 and R17) but I was shown it on an R16 and R18 today on another system – and to be fair I have been having some vid card issues so it could be a glitch that is unique to me (that’ll teach me for buying a top end nvidia!)

    I’m glad that helped. I’m about to start doing what you were doing for a project we have here so I’ll let you know what I find.

    I have noticed, and I”ve had no good answers on this, that when I render multipass with EXRs, if I don’t include RGBA in the list, usually I get an RGBA layer but sometimes not. I think it’s there regardless, as I can see it in the picture view window as its rendering but try as I might (even with extractoR) I can’t pull an RGB from the multi pass sometimes (which is really annoying after a long render – ever down a presentation to a client with depth channel only?). But when I force an RGBA layer by adding it to the multipass list, that RGB looks very different from my viewport; whereas the one that comes with the multipass usually has no surprises vs the viewport look). Now I think that’s because I don’t have the setting to change my viewport to Linear (and the multipass remember is always linear). We tried it on another system that did have the view port set to linear so forced RGB’s looked the same as the view.

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy