| Age | Commit message (Collapse) | Author |
|---|
|
Since we are ditching layers from Blender (2.8) we need a replacement to
control groups visibility. This commit introduces collections as the building
blocks for groups, allowing users to control visibility as well as overrides
for groups.
Features
========
* Groups now have collections
This way you can change the visibility of a collection inside a group, and add
overrides which are part of the group and are prioritized over other overrides.
* Outliner
Groups can inspect their collections, change visibility, and add/remove members.
To change an override of a group collection, you need to select an instance of
the group, and then you can choose "group" in the collection properties editor
to edit this group active collection instead of the view layer one.
* Dupli groups overrides
We can now have multiple instances of the same group with an original "override"
and different overrides depending on the collection the instanced object is part
of.
Technical
=========
* Layers
We use the same api for groups and scene as much as possible.
Reviewers: sergey (depsgraph), mont29 (read/write and user count)
Differential Revision: https://developer.blender.org/D2892
|
|
Instead of storing a single active view-layer in the workspace, one is
stored for each scene the workspace showed before.
With this, some things become possible:
* Multiple windows in the same workspace but showing different scenes.
* Toggling back and forth scene keeps same active view-layer for each scene.
* Activating workspace which didn't show current scene before, the current view-layer is kept.
A necessary evil for this is that accessing view-layer and object mode
from .py can't be done via workspace directly anymore. It has to be done
through the window, so RNA can use the correct scene.
So instead of `workspace.view_layer`, it's `window.view_layer` now (same
with mode) even though it's still workspace data.
Fixes T53432.
|
|
|
|
It's not possible to bypass new depsgraph, but also flush to other CoW copies
might be needed here.
|
|
object
This avoids us from directly calling object update, and doing other type of
update flushing.
Prepares us to get rid of Object->recalc flags.
|
|
Why is it called legacy when this is a legit flags which are still to be checked
at a runtime???
|
|
|
|
a dependent object
The idea of this flag was to prevent snapping onto an object which depends on
currently modifying ones. Using single flag makes more sense here, and also
makes it possible to replace some ob->recalc based magic with depsgraph query
to set those flags.
|
|
It looks stupid to first force some flag being set and then have workaround
to ignore that flag in snapping code. Let's just not set the flag in the first
place.
The only useful situation where such snapping was usable is to move roots of
disconnected hair, which still works just fine. However, there might be some
other hidden corner case where this workaround was needed.
|
|
|
|
|
|
|
|
D2931 by @col-one
|
|
|
|
Differential Revision: https://developer.blender.org/D2872
|
|
You can now override loc/rot/scale of objects and posebones.
Also added a basic operator to make an override of active linked object,
but this is very limited/wip/testing feature (you have to manually override
object and its armature, and relink to proper local overrides
yourself...). Final 'make proxy killer' will be much more automated of
course.
|
|
We could do that in several different way, e.g. adding some tag during
DEG evaluation, etc. But this is not a critical process (it's main
purpose is user feedback), so current solution seems to work well enough
- and it's dead simple! ;)
|
|
properties.
|
|
For now, using a new color for overridden properties (similar to
animated/driven status), UI team will need to work on a better solution
maybe...
|
|
|
|
Do a direct update of object transform instead, without involving
manual trickery of recalc flag.
Shouldn't be functional changes as far as artists are concerned,
but will allow us to get rid of recalc flags in 2.8.
Thanks Bastien for review!
|
|
This replaces dedicated flag which wasn't clean who sets it and who clears it,
and which was also trying to re-implement existing functionality in a way.
Flushing is not currently very efficient but there are ways to speed this up
a lot, but needs more investigation.
|
|
This way it is more clear what is needed to be passed and what is available
in the callback itself.
Thanks Dalai for review and tips about engine type!
|
|
|
|
|
|
This way we can extend it much easier.
|
|
This commit effectively reverts fix T45702 done in 067fe2719a99.
Reasoning:
- Blender Internal is being replaced with Eevee, and will be removed entirely
rather soon.
- All render engines are planned to have own depsgraph, so such threading
conflicts should no longer be an issue.
- We don't want to spend time on porting workarounds for EOL things to a new
design. Less code -- faster the work :)
- If such notifications will end up needed for some other cases, we would
need to re-implement this a more proper depsgraph tagging/flushing and make
it to work with all copy-on-write datablocks and everything.
|
|
There might be much more logic involved there, also we might not know proper
evaluated CoW pointer there yet. So we leave this to dependency graph to
decide what exactly to do here.
|
|
|
|
|
|
|
|
Neither me nor Campbell could redo the issue, lets get rid of this workaround
and fix it properly if still needed.
|
|
|
|
DoF disabled
|
|
|
|
The title says it all actually, controlled with DoF check box next to textured
solid check box.
Thanks Campbell for review!
|
|
This is fully unreadable to have lots of boolean arguments scattered across the
whole argument list. What does `false, true, true` mean in terms of behavior?
Replace those with bitfield which has advantage of having more human readable
meaning.
|
|
|
|
Support duplicating, switching workspaces too.
|
|
|
|
|
|
|
|
Conflicts:
source/blender/editors/mask/mask_draw.c
|
|
`BKE_maskrasterize_buffer`!
So this deduplicates and simplifies code, yeah.
Also, as an odd bonus, new code seems slighly quicker than previous one
(about 5 to 10% quicker).
|
|
activated immediately instead of upon LMB
|
|
indirectly
|
|
|
|
Previously it was done during depsgraph iteration, which is not good at all,
since after evaluation nobody should really modify how object was evaluated.
|
|
This is crucial bit since batch cache is stored in the evaluated object,
meaning we can't tag it's hatch cache dirty from the notifier system.
Not easily at least. Better to leave this job to depsgraph, it knows
all the copies of data.
|
|
Property range setup initially used values that can change.
|
