| Age | Commit message (Collapse) | Author |
|---|
|
You could still create groups as before, with Ctl + G. This will create a group
with a single visible collection.
However you can also create a group from an existing collection. Just go to
the menu you get in the outliner when clicking in a collection and pick
"Create Group".
Remember to instance the group afterwards, or link it into a new scene or file.
The group and the collection are not kept in sync afterwards. You need to manually
edit the group for further changes.
|
|
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.
|
|
Also avoid once queue push for cases when current operation has multiple
outgoing relations.
|
|
|
|
|
|
|
|
Those shouldn't be used anywhere for real now.
|
|
Wondering whether files from 2.37 are still working fine.
Don't have that version of Blender running here, so can't test :(
|
|
This is actually functions which needs bigger reconsideration, but for now let's
try to keep them working as much as possible.
|
|
This wouldn't be less precise than object level flag in theory, and we need to
move away from such a duplicating flags.
|
|
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.
|
|
|
|
|
|
|
|
It makes more sense to stick to DEG_iterator_object order in name, since we can
have functions to iterate over different entities and we want all of them to
have common prefix.
|
|
Required to updade uniforms
|
|
incorrect
|
|
Which is not in some cases since workspace is still partly implemented.
|
|
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.
|
|
|
|
|
|
We should keep base_flags after CoW object datablock was updated. Not entirely
happy with current solution, but it fixes crash and allows us to run tests
again.
More proper solution would be to make CoW operation a per-component thingie,
which will only update corresponding parts.
|
|
|
|
|
|
Remapping of pointers did not work properly, since it had no pointers yet to
remap base->object to a CoW object.
|
|
|
|
builder
|
|
|
|
|
|
We need all id nodes to be evaluated at least once when opening a file.
This is particuarly required for the upcoming group collection patch.
|
|
|
|
|
|
|
|
|
|
D2860 by @miqlas
Even though Haiku is a niche OS, only minor changes are needed.
|
|
Previously, the NLM kernels would be launched once per offset with one thread per pixel.
However, with the smaller tile sizes that are now feasible, there wasn't enough work to fully occupy GPUs which results in a significant slowdown.
Therefore, the kernels are now launched in a single call that handles all offsets at once.
This has two downsides: Memory accesses to accumulating buffers are now atomic, and more importantly, the temporary memory now has to be allocated for every shift at once, increasing the required memory.
On the other hand, of course, the smaller tiles significantly reduce the size of the memory.
The main bottleneck right now is the construction of the transformation - there is nothing to be parallelized there, one thread per pixel is the maximum.
I tried to parallelize the SVD implementation by storing the matrix in shared memory and launching one block per pixel, but that wasn't really going anywhere.
To make the new code somewhat readable, the handling of rectangular regions was cleaned up a bit and commented, it should be easier to understand what's going on now.
Also, some variables have been renamed to make the difference between buffer width and stride more apparent, in addition to some general style cleanup.
|
|
|
|
D2931 by @col-one
|
|
Guess 'remove all unlocked' is new-ish feature...
To be backported to 2.79a (I think).
|
|
Differential Revision: https://developer.blender.org/D2935
|
|
|
|
This works the same as the holdout shader and Z mask layer. Combined with
overrides in 2.8 this is intended to replace the Z mask layer bits.
|
|
Reduces render time by about 1-2% in benchmark scenes.
Differential Revision: https://developer.blender.org/D2911
|
|
Differential Revision: https://developer.blender.org/D2872
|
|
For some blend modes there would be no effect with factor 1.0, even if factor
0.999 would give a very different image. Now the result should have no
discontinuity.
Differential Revision: https://developer.blender.org/D2925
|
