@Brecht Van Lommel (brecht), you are right. I had some logic for that, but removed in a cleanup.

Right, I mixed the names, sorry. Also, it works on Windows 10 + GeForce GTX 1070/PCIe/SSE2, 4.5.0 NVIDIA 411.63

So it is working? Closing the bug then.

I don't even know who is overseeing physics those days. @Sergey Sharybin (sergey)? @Brecht Van Lommel (brecht)?

Okay, talked to Clément and this is working by design. Although mixing RGB is fine, there is no way to reasonably mix SSR data.

The issue is on the ssr_data calculated in bsdf_common_lib.glsl:closure_mix().

Note: I can reproduce this in 2.79 as well.

Note: I can reproduce this in 2.79 as well.

I'm pretty sure this was introduced on rB5f2b4002f49b0 (@Sergey Sharybin (sergey)).

You need to turn on "Screen Space Reflections" for that. (right @Clément Foucault (fclem)?).

Strange that if I do UNDO again after object mode + UNDO, the image is back. For the records, tested with rBeff3728db912.

@Brecht Van Lommel (brecht) if you think this is not the best solution poke me. My initial attempt was to duplicate the entire screen, with fullscreen state and all that. But that was getting too complicated to implemented.
In the end I took a simpler approach after familiarizing myself again with the fullscreen code.

Submitted a different approach on: rB2b7752fb00737d29200d6c0aeb6a782b1a969c65.

Fixed on rB2b7752fb00737d29200d6c0aeb6a782b1a969c65.

Also problematic, the button to go out of fullscreen mode is nowhere to be seen in this case (since the non-main window has no topbar).
So I wonder from the design whether this was even suppose to be supported.

@Jacques Lucke (JacquesLucke) I didn't even confirm, but since this is animation nodes related, this is all yours.

I would add to it an option to hide the disabled collections in the filter.
I second what @Brecht Van Lommel (brecht) said, we need a way to tell that a collection (and object?) is not rendered since this is a big deal.

• Make sure multi-edit also respect the shift rules to extend.

• From review: Make mesh modes consistent with armature ones

For the records, I found an old report I created September last year (T56976) which is pretty much a duplicate of this one. It even has its own patch (D3750) though D4344 is more complete.
I will keep pestering my peers this time, so it doesn't fall into the oblivion void once again.

I ended up implementing the solution suggested by @Brecht Van Lommel (brecht) on D4344, pending review.

• Code cleanup: put more things in _common

Running with --debug shows:
Memoryblock free: pointer not in memlist
This should be easy to bisect to find the original commit where this was introduced.

@Antonio Vazquez (antoniov) hm why is moving a layer assigned to click in the first place? Why does it even work in a locked layer?
Mixed feelings about letting poll return true, since it is not the real fix I think.

@Brecht Van Lommel (brecht) indeed, reverting rB2778ecb58cd23 seems to fix it.

Bug confirmed on: f16763a01dfb

For the records, by following your instructions I cannot reproduce the crash:

@Ron Zandbergen (Taaske) Could you provide us with a simple sample created with 2.79 that reproduces the issue right before the conversion happens?
Right now when opening your file I get an immediate crash: curve.c:1862, BKE_curve_bevel_make(), at 'cu->bevobj->runtime.curve_cache != ((void *)0)'

@Thomas Androxman (ThomasAn) sorry but you are getting the Move to Collection operator wrongly.
That said I exhausted my arguments here and will no longer repeat myself.

This is more an interface/Python issue, not sure why it was assigned to me.
@Jacques Lucke (JacquesLucke) wants to look at this?

Isn't it for the same reason trying to fill a locked layer activates the Move operator?
I guess the operator poll is returning false, and the next operator in line is the move?

@William Reynish (billreynish) I think consistent should be pursuit here. Super low priority bug, but which way do you think we should go? Any idea why things changed since 2.7x?

For the last time, (at the moment), what you do in the viewport has nothing to do with the outliner. They are each their own contexts.
You can create "New Collection" when using "M" even inside a sub-collection (e.g., inside GeometryObjects in your case).

The active collection, the one shown in the status bar and in the viewport, is the one used to add new objects.
The "Move" to collection operator is intended to let you move your objects to ANY collection, not the active one.

When calling from the viewport it ignores all the outliners and simply shows the entire collection tree to the user.

At the Blender Animation Studio we have been working with the outliner and visibility settings of Blender 2.8 for almost a year now ... and almost every person ended up using those features in a completely different way.

For the records if you Alt+H in the outliner you will reveal but collections and hidden objects.

I would favour a solution that allows for forward compatibility. Even if the old DNA struct is filled with a default value, and not the data from the equivalent new struct. That should happen for both old files that are converted, and new files created after the rename.

Good point, done.

@ThinkingPolygons (ThinkingPolygons) the bug you mentioned is now fixed. As for undoing the isolate (ctrl+click), just use Alt+H in the outliner (it will affect the collections as well as the objetcs).

@Brecht Van Lommel (brecht) @Julien Kaspar (JulienKaspar) @Pablo Vazquez (pablovazquez) any thoughts on that? It will effectively add another layer of invisibility for users to deal with it.

This is not a bug. You are mixing hiding collections with hiding objects. We will have a shortcut to unhide all collections soon.

An alternative (and perhaps correct) fix seems to be to call BKE_collection_object_cache_free for any collection owning an object that has its disable state changed. Or simply BKE_collection_object_cache_free() for all collections whenever we tag relations to rebuild in depsgraph. cc @Brecht Van Lommel (brecht)

@Sergey Sharybin (sergey) I'm looking at this, but the issue seems to be related to depsgraph in a way. I guess the issue is that we need to do view_layer_remove_disabled_bases() for instanced collections as well.

Click with Alt should indeed hide the instanced object. Looking at it.

• When Ctrl clicking a collection, it will unhide all other collections but any objects that are in the scene root will remain shown.

@Julien Kaspar (JulienKaspar) shift+click was indeed still changing disable state of inside objects. Fixed now (rBdb231e87fc84).

@Julien Kaspar (JulienKaspar) implemented some of it on rB766741b0aa8.

• Note to self: I believe I'm changing the master collection visibility flags when isolating a collection, leading to subsequent collections to be created hidden.

I talked to @Campbell Barton (campbellbarton), his suggestion short-term is to not try to change modes unless current active mode is compatible. Something along the lines of B.

• From review: tooltip
• Tweaks for drag lock after recent commit in master
• From review: Outliner operators to affect all selected collections

This was fixed already on rB699b49e8e9d (same day as of the build you tried).

Addressed all but the "All Inside". @William Reynish (billreynish) was the one proposing the original names. Feel free to speak up WIlliam.

• From review: Fix restrict column width
• From review: Rename Outliner operators

We have a similar issue with mesh objects. Basically the issue is that the active object is in a mode different from the data mode.

• All the operators also in the collection context menu.

context.collection is very different than context.scene. The simplest conversion would be to use context.scene.collection here.
That said in many cases what you want is to create a collection and use that instead.

• Fix OBJECT_OT_hide_collection update