This was introduced to the outliner when we had no User Preference
window back in 2.5x. Right now it makes no sense to keep this around.
But how about addon user preferences:
* They belong in the user preference window under the addon.
How about the user preferences themselves:
* You find them in the user preference window.
And templates?
* Why are they here in the first place?
After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found
it reasonable to get rid of this. If it turns out that we were wrong we
revert this.
As for leaving this exposed as a debug option (as suggested on IRC) I would say
no, please. This end up polluting the code and never cleaned up in the end.
(this was specific talking about templates).
Technical note: I left the functions in outliner still hanging around.
While I used UNUSED_FUNCTION for one of them, for the other one I had to use:
`#if 0` because the function was calling itself, which would fail to build if
I used UNUSED_FUNCTION.
We have different ways of explore the scene objects, namely View Layer and
Collections. This change let us focus on compositing elements only such as:
* View Layers
** Collections
** Render Passes
* Freestyle
* Grease Pencil?
Not included in this commit is an option to handle filtering of
collections passes, ... Not sure if we would like, though.
Since they are all properly nested under a "Collections" / "Passes"
parent.
User notes:
The outliner so far was a great system to handle the object oriented workflow
we had in Blender prior to 2.8. However with the introduction of collections
the bloated ammount of data we were exposed at a given time was eventually
getting on the way of fully utilizing the outliner to manage collections and
their objects.
We hope that with this filtering system the user can put together the outliner
with whichever options he or she seem fit for a given task.
Features:
* Collection filter: In case users are only focused on objects.
* Object filter: Allow users to focus on collections only.
* (Object) content filter: Modifiers, mesh, contrainst, materials, ...
* (Object) children filter: Hide object children [1].
* Object State (visible, active, selected).
* Compact header: hide search options under a search toggle.
* Preserve scrolling position before/after filtering [2].
[1] - Note we still need to be able to tell if a children of an object is in a
collection, or if the parent object is the only one in the collection.
This in fact was one of the first motivations for this patch. But it is to
be addressed separately now that we can at least hide children away.
[2] - We look at the top-most collection in the outliner, and try to find it again
after the filtering and make sure it is in the same position as before.
This works nice now. But to work REALLY, REALLY nice we need to also store
the previous filter options to be sure the element we try to keep on top
was valid for both old and new filters. I would rather do this later though
since this smell a lot like feature creeping ;)
Remove no longer needed display options:
* Current Scene (replaced by View Layer/Collections)
* Visible (replaced by filter)
* Selected (same)
* Active (same)
* Same Type (same-ish)
How about All Scenes? I have a patch that will come next to replace the current
behaviour and focus only on compositing. So basically stop showing the objects
and show only view layers, their passes and collections, besides freestyle.
Also, while at this I'm also reorganizing the menu to keep View Layer and
Collections on top.
Developer notes:
* Unlike the per-object filtering, for collections we need to filter at tree
creation time, to prevent duplication of objects in the outliner.
Acknowledgements:
Thanks Pablo Vazquez for helping testing, thinking some design questions
together and pushing this to its final polished state as you see here.
Thanks Sergey Sharybin and Julian Eisel for code review. Julian couldn't do a
final review pass after I addressed his concerns. So blame is on me for any
issue I may be introducing here. Sergey was the author of the "preserve
scrolling position" idea. I'm happy with how it is working, thank you.
Reviewers: sergey, Severin, venomgfx
Subscribers: lichtwerk, duarteframos
Differential Revision: https://developer.blender.org/D2992
Both object level and camera datablock properties animation did not work with
copy on write enabled.
The root of the issue is going to the fact, that all interface elements are
referencing original datablock. For example, View3D has pointer to camera it's
using, and all areas which does access v3d->camera should in fact query for
the evaluated version of that camera, within the current context.
Annoying part of this change is that we now need to pass depsgraph in lots
of places. Which is rather annoying.
Alternative would be to cache evaluated camera in viewport itself, but then
it makes it annoying to keep things in sync.
Not sure if there is nicer solution here.
Reviewers: dfelinto, campbellbarton, mont29
Subscribers: dragoneex
Differential Revision: https://developer.blender.org/D3007
Drawing hair weights read before the hair array start.
This code could be improved since it currently copy-pastes,
from do_particle_interpolation, but this would need larger changes.
For now just correct existing logic.
Sun is treated as a unit distant disk like in cycles.
Opti: Since computing the diffuse contribution via LTC is the same as not using the Linear Transformation, we can bypass most of the LTC code.
This replaces the sphere analytical diffuse computation as it gives a more pleasing result very close to cycles' AND cheaper.
Lights power have been retweaked to be coherent with cycles (except sun lamp with large radius where cycles has a non-uniform light distribution).
This is an improvement on the old spining quad method that was giving artifacts when the reflection ray was nearly aligned with the sphere center.
This might be a bit heavier but it's worth it.
Headers should not have operators as much as possible. The exception here is
for datablocks mode when you want to see the active keyset.
Edit menus on the other hand should be clearly distinct from the RMB context
menus. Edit menu options should be only the ones that apply to the entire
outliner, regardless of the selected element.
Context (rmb) menus should be related to the element you RMB on to invoke the
menu. I'm also taking this opportunity to start bringing the context menus
to Python. There is little reason not to, and it helps editing them (In this
case I'm doing it only for the Scene Collection one).
