There are three flags, two for viewport one for render.
Agree it’s confusing. Render flag should be sync’d with viewport flag (one of them) by default, I think.
Well, the flags are not to hard to grasp, it’s the viewport Cycles renderer not obeying them is just wrong imho…
Oh you mean ray visibility ?? yes it sits on top on the Blender flags. I don’t usually use it… just the viewport and render flags.
Try this…
Open a new scene in Blender, and in the Outliner turn on all 3 filters for visibility.
Ste Cycles to be your renderer, and switch to viewport preview rendering.
Select the cube, turn off the eye icon. Cube disappears. Do a F12 render, it’s back. Frame render obeys flags set in the Outliner.
Turn on eye icon, turn off the display icon. Cube disappears again. Do a F12 render, it’s back. Frame render obeys flags set in the Outliner.
Turn on display icon, turn off the render icon. Cube is still there. Do a F12 render, it’s gone from rendered frame. Frame render obeys flags set in the Outliner…
But the - preview render - makes it very confusing this way. This in on anything 2.8x and 2.9x. It makes for easy mistakes, as the visible results make no sense.
rob
2 Likes
I think Cycles has to have those ray visibility options because it can theoretically connect to any other 3D program, but since Blender has those too (albeit a little different) they end up duplicated. The thing is, when working on relatively simple scenes, you want to see what is going to be rendered, ie you want viewport and render flags to be one and only. However on more complex scenes, where you might have references, plenty of helper objects, etc. viewport and render make sense to be split. Do you think having just one flag by default and have the render flag be optional would make it better ? There’s room for a good UI proposal here I think, you’re not the first person to complain about this
For now there’s a ‘syncing issue’ between the Outliner flags & the object rendering flags.
Just select the cube and turn on/off flags in the Outliner & look at the Object Visibility properties.
Turning off the eye flag does not turn off the ‘show in viewports/renders’ Visibility flag.
Turning off the display flag does not turn off the ‘show in renders’ Visibility flag.
Turning off the render flag in the outliner does sync up in the Visibility properties, but doesn’t do anything render wise in the viewport?
So yeah… it might be nice to see something happening here at some point, as this is just with one view.
Imagen the confusion when working with multiple views in combination with the object visibility dropdown options…
Yes, no, no , yes, yes, no…??
It’s nice to have a ton of new features every point release, but certain area’s need some proper love to make them workable in larger productions (cough… Outliner selection options & rendering workflow cough…)
That’s because you’re looking at the wrong flag : viewport visbility is the other “visibility” flag, the one showing a monitor. Don’t worry it makes no sense to me either.
Well no that’s the render flag, it doesn’t change what is shown in the viewport
I understand that they’re different, but they show different behavior in the Outliner -and- Visibility properties.
If I turn something off in the viewport, I want my Cycles rendered viewport - obey the render flag - set in the Outliner. So even though I turned off the eye or display flag, the object should pop up again in the rendered viewport if the render flag is still turned on.
Or if I turn OFF the render flag, it still shows up in the Cycles rendered viewport.
That’s my main beef atm.
Can’t explain it ion another way I’m afraid… 
1 Like
I agree this is a design flaw and it doesn’t make sense for a rendering workflow.
It happens to me so often that i hit render and there are objects in the scene that I couldn’t see in the viewport. In my opinion there are 2 ways to fix this
- either the viewport render obeys the render flag (camera icon) and not the visibility flag (eye or monitor)
- or invisible means invisble in render as well. I think it could be the other way around where visibility hides it everywhere and there is an override somwhere in the settings to show it in the viewport without rendering it
3 Likes
Yeah…
I don’t really mind what option is chosen, there should be a logical ‘flow’ for this.
And yes, add a override if you want it to have it differently for that case.
Especially turning -off- the render display flag and it is still being rendered in the Cycles viewport is hair losing annoying.
You can set the render flag of a Collection to not render (but it still shows up in Cycles viewport), and have a child Object of it set to viewport/display off. In the Cycles viewport you now have something completely different than your frame render.
So much wasted time rendering frames to see if it shows up in camera by any chance. 
2 Likes
In the meantime you can still have a script run through your objects and sync flags, but that’s not automatic.
That may be nice for smaller scenes, but with lots of linked files and scenes it becomes a nightmare to manage…
I rather have the Blender chaps look into this and make some changes to the way it works now
I said in the meantime
1 Like
1 Like
The hidden stuff aren’t really the problem. We should, though, have the ability to see what’s hidden and will show up on renders. Maybe as an add-on, which shows what is visible but not rendering and what isn’t visible but is rendering…
If I understand correctly, the problem is that viewport preview uses the viewport visibility settings, not the render visibility settings. Maybe it’s because I’m used to it, but this makes sense to me - viewport preview is for seeing what you’re currently working on, F12 is for seeing the actual result of rendering.
On the other hand, I do see the value in being able to see your actual render in the viewport too. At the risk of adding even more complexity, perhaps an option in the viewport shading settings for rendered mode “Use viewport visibility” or “Use rendered visibility” would work?
The second issue is the naming of the flags in the properties panel the “Show in Viewport” checkbox is actually controlling the “Disable in viewport” flag in the outliner. I think this should be regarded as a bug, and should be reported.
Actually, aren’t the tool tips of the outliner buttons the problem? The “disable in viewports” button is activated by default. That suggests the “disable function” is activated and the object should be disabled. But that’s not how it works. Thus it would be better if those buttons had tooltips that follow the object panel and be “show/enable” not “hide/disable”, no?
Sorry for didn’t read all the thread but I agree that it is strange to have difference between render viewport and F12…
I often confused about that
Otoh it doesn’t take that long to get used to it. And it’s very handy to be able to easily&quickly hide stuff in the viewport while you’re working, while not affecting your final render. Especially on a slower system it’s essential in keeping blender responsive.
Wanting stuff to be hidden in the render is much more rarely needed. I think the current system is good. Only maybe the labeling should be more clear. Or maybe change the eye icon for the ‘viewport visibility’ icon which is used in modifiers. (Though that icon is in itself less clear).
’
While you can get used to the whole hidden from renders/hidden from viewports thing, there are situations where it can be pretty irritating to troubleshoot preview/render differences, since you have to actually render to get render settings. This isn’t just visibility settings, but modifier and particle settings as well, “simplify” plays into it, wireframe object display isn’t respected by render, etc-- so many moving parts, so many different interfaces to check. It’s easy for a difference in subdivision levels to accidentally break a surface deform, which, if on a non-rendering mesh, might break a shrinkwrap to that mesh on a rendering object, and then you have to figure out what’s happening, render by render, because the viewport’s not going to show you where the problem is.
For sure, all of that is fixable with a script that remembers preview settings and then toggles between render and preview settings for a preview, which would let you rapidly check your scene for problems before shipping to a render farm. But yes, I don’t understand why such a script isn’t built into Blender.