| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Those were missing proper (explicit) object cache clear, and DEG
tagging.
Note that this was most likely not an common issue in practice (Collection
object cache clearing recursively goes into all parents, so master
collection would only miss it in case they had no child collections at
all, and tagging of those happens almost always at other steps on
remapping). But better to be explicit and consistent here in any case.
|
|
In collection/viewlayer synchronization code, in some cases, there are
extra unused view layer collections left in old list after all needed
ones have been moved to the new list.
Found while working on T86741.
|
|
Callback function was using int while update_render_passes_cb_t was
using eNodeSocketDatatype leading to a build warning about different
argument types with MSVC.
|
|
Cryptomatte is a standard to efficiently create mattes for compositing. The
renderer outputs the required render passes, which can then be used in the
compositor to create masks for specified objects. Unlike the Material and Object
Index passes, the objects to isolate are selected in compositing, and mattes
will be anti-aliased.
Cryptomatte was already available in Cycles this patch adds it to the EEVEE
render engine. Original specification can be found at
https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf
**Accurate mode**
Following Cycles, there are two accuracy modes. The difference between the two
modes is the number of render samples they take into account to create the
render passes. When accurate mode is off the number of levels is used. When
accuracy mode is active, the number of render samples is used.
**Deviation from standard**
Cryptomatte specification is based on a path trace approach where samples and
coverage are calculated at the same time. In EEVEE a sample is an exact match on
top of a prepared depth buffer. Coverage is at that moment always 1. By sampling
multiple times the number of surface hits decides the actual surface coverage
for a matte per pixel.
**Implementation Overview**
When drawing to the cryptomatte GPU buffer the depth of the fragment is matched
to the active depth buffer. The hashes of each cryptomatte layer is written in
the GPU buffer. The exact layout depends on the active cryptomatte layers. The
GPU buffer is downloaded and integrated into an accumulation buffer (stored in
CPU RAM).
The accumulation buffer stores the hashes + weights for a number of levels,
layers per pixel. When a hash already exists the weight will be increased. When
the hash doesn't exists it will be added to the buffer.
After all the samples have been calculated the accumulation buffer is processed.
During this phase the total pixel weights of each layer is mapped to be in a
range between 0 and 1. The hashes are also sorted (highest weight first).
Blender Kernel now has a `BKE_cryptomatte` header that access to common
functions for cryptomatte. This will in the future be used by the API.
* Alpha blended materials aren't supported. Alpha blended materials support in
render passes needs research how to implement it in a maintainable way for any
render pass.
This is a list of tasks that needs to be done for the same release that this
patch lands on (Blender 2.92)
* T82571 Add render tests.
* T82572 Documentation.
* T82573 Store hashes + Object names in the render result header.
* T82574 Use threading to increase performance in accumulation and post
processing.
* T82575 Merge the cycles and EEVEE settings as they are identical.
* T82576 Add RNA to extract the cryptomatte hashes to use in python scripts.
Reviewed By: Clément Foucault
Maniphest Tasks: T81058
Differential Revision: https://developer.blender.org/D9165
|
|
This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the
render pass tab and used in shader materials. Both Object and World based
shaders are supported. The AOV can be previewed in the viewport using the
renderpass selector in the shading popover.
AOV names that conflict with other AOVs are automatically corrected. AOV
conflicts with render passes get a warning icon. The reason behind this is that
changing render engines/passes can change the conflict, but you might not notice
it. Changing this automatically would also make the materials incorrect, so best
to leave this to the user.
**Implementation**
The patch adds a copies the AOV structures of Cycles into Blender. The goal is
that the Cycles will use Blenders AOV defintions. In the Blender kernel
(`layer.c`) the logic of these structures are implemented.
The GLSL shader of any GPUMaterial can hold multiple outputs (the main output
and the AOV outputs) based on the renderPassUBO the right output is selected.
This selection uses an hash that encodes the AOV structure. The full AOV needed
to be encoded when actually drawing the material pass as the AOV type changes
the behavior of the AOV. This isn't known yet when the GLSL is compiled.
**Future Developments**
* The AOV definitions in the render layer panel isn't shared with Cycles.
Cycles should be migrated to use the same viewlayer aovs. During a previous
attempt this failed as the AOV validation in cycles and in Blender have
implementation differences what made it crash when an aov name was invalid.
This could be fixed by extending the external render engine API.
* Add support to Cycles to render AOVs in the 3d viewport.
* Use a drop down list for selecting AOVs in the AOV Output node.
* Give user feedback when multiple AOV output nodes with the same AOV name
exists in the same shader.
* Fix viewing single channel images in the image editor [T83314]
* Reduce viewport render time by only render needed draw passes. [T83316]
Reviewed By: Brecht van Lommel, Clément Foucault
Differential Revision: https://developer.blender.org/D7010
|
|
|
|
Some operations, like remapping and ID (Object) to another, can lead to
having the same object in more than one base.
While this is not a valid state, this is being taken care of by the
`BKE_layer_collection_sync` call, so the object-to-base GHash generation
itself should be resilient to such issue.
Note: another way to fix this would be to make remapping post-process
code check explicitely for such doublons, but I would rather avoid
adding even more 'specialized' code there, it already has to deal with
too many of those corner cases.
|
|
Ref T76372.
|
|
|
|
This one was a bit more tricky, because the file loading is
mixed with versioning code and because collections are
embedded into scenes.
All tests that passed before, still pass.
|
|
Follow our code style guide by using C-comments for text descriptions.
|
|
Found as part of D8324, multithreaded Cycles object sync, where it caused
a crash on concurrent access to object holdout state.
|
|
Regression in 12bc34b0b81b1, add assert so this doesn't happen again.
|
|
in Local View
Hiding a collection should hide all children objects even when we are in Local
view with one of them.
Note from reviewer: We are doing this already for local collections. So
may as well do it when hiding the collections for the entire view layer.
Developer details: In function "BKE_object_is_visible_in_viewport" object flag
BASE_VISIBLE_VIEWLAYER wasn't being checked when we were in Local view,
It's now changed so that it's checked even if we are in Local view.
And this function was called by some viewport draw functions to check if it
should draw an object or not.
Maniphest Tasks: T72584
Differential Revision: https://developer.blender.org/D7894
|
|
|
|
Warning introduced on a5db981b0ea044313239c3cc2ee92d.
|
|
The fix involves going over ALL the possible combinations of viewlayers
and viewports and re-sync.
I tested this with multiple windows, multiple scenes and multiple
viewlayers.
Since (for now?) the operation of syncing the local layer collections is
not too expensive, this is not so bad. In theory we could improve this
by checking if the collection the object was moved to and from is in the
scene before iterating over it. I don't think it is worthy though.
Thanks Arun Parolikkal for the initial attempt on D8342.
Final patch reviewed by Brecht Van Lommel.
|
|
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenkernel` module.
No functional changes.
|
|
|
|
|
|
Previous ones were extremely confusing and innacurate (probably
inherited from older versions of scene collections?).
Also, use named fields in struct initialization, much much safer and
cleaner than anonymous, positionned-based thing.
|
|
are disabled
There is no reason to have the children enable/disable state to
influence the parent collection. Specially considering that the parent
collection itself can have objects that would be visible.
Reviewed by: dfelinto, brecht
Differential Revision: http://developer.blender.org/D7864
|
|
|
|
Excluding a collection also changes the exclude setting on all child collections
so that it is possible to selectively enable some children without the parent
being enabled.
This change makes it so that if you unexclude the parent, the exclude setting
of children are restored again instead of being permanently lost.
Original patch by Szymon with modifications by Brecht.
Differential Revision: https://developer.blender.org/D7016
|
|
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
|
|
Modify the view layer add operator (and underlying `BKE_view_layer_add`)
to allow for copying the current view layer, as well as adding a new one
but with all LayerCollections disabled by default (this is important for
heavy scenes where currently adding view layers can take a long time due
to enabling every collection by default).
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D6862
|
|
|
|
Note that `BKE_library.h`/`library.c` were renamed to
`BKE_lib_id.h`/`lib_id.c` to avoid having a too generic name here.
Part of T72604.
|
|
Credit for the original patch goes to @scorpion81.
|
|
Before this patch you could go to a local view with a single object,
while you had other objects also in edit mode, and your operators would
affect all objects even the ones outside your local view (same for local
collection).
Differential Revision: https://developer.blender.org/D6064
|
|
My bad for not figuring out how to run our unittests since I got back to
Windows.
|
|
Now local collections are fully working with cycles preview, while the
collection visibility bug is fixed.
Local collections were not working with cycles viewport even before the recent
commit to allow users to show collections that are hidden in the view layer.
It just got worse with said commit (0812949bbc3d).
Differential Revision: https://developer.blender.org/D6034
|
|
Users now can turn on in a viewport collections that are temporarily
hidden (eye) in the view layer.
Design task: T61327
As for the implementation, I had to decouple the visibility in the
depsgraph from the visibility in the view layer.
Also there is a "bug" that in a way was there before which is some
operators (e.g., writing a text inside of a text object, tab into edit
mode) run regardless of the visibility of the active object. The bug was
present already (with object type visibility restriction) in 2.80 so if
we decide to tackle it, can be done separately (I have a patch for it
though P1132).
Reviewed by: brecht (thank you)
Differential Revision: D5992
|
|
The tricky part here is to support a hidden parent and a "visible" child
collection. In this case the object should obviously be invisible. It is
all working now.
|
|
This fix T67162.
|
|
Steps to reproduce were:
* Add a new collection
* Put an object into it
* Exclude the selection (the checkbox in front of the name)
* Enable "Local Collections" in any viewport
-> Crash
Did not skip the excluded collections, causing an unsuccessful object
lookup (returned null-pointer).
|
|
The problem was that the object and collection pointers in Base and
LayerCollection would get lost of file read. Normally such ID pointers would
be resolved by pointing to an ID_ID placeholder which has the datablock name,
and then replacing it will the real datablock. However ID_ID is only written
for directly linked datablocks.
This adds the concept of an indirectly linked datablock with a weak reference
to it. For this we write an ID_ID_WEAK_REF code, which is a reference that
will only be resolved if the datablock was read for another reason.
Differential Revision: https://developer.blender.org/D4416
|
|
Support per-viewport collection visibility options.
Note 1: There is no way to show a collection that was not visible before
due to depsgraph. Otherwise we would risk having all the collections in
the depsgraph and I believe this is not the idea.
An alternative would be to have a new depsgraph for viewports that are
not local. Something to keep in mind if we do per-viewport current frame
in the future.
So for now what we do is to only allow collections visibility to be
disabled/hidden in this mode.
Note 2: hide_viewport (the eye icon) doesn't really matter for
depsgraph. So after the merge we can still ignore it to show the
collections locally in a viewport with no problems for the depsgraph.
Reviewers: brecht, sergey
Subscribers: billreynish
Related task: T61327
Differential Revision: https://developer.blender.org/D5611
|
|
When the active collection is hidden or excluded, change the active
collection to the first visible parent collection. This behavior existed
previously for excluding collections, and is now expanded to also
switch the active collection when viewport hidden or restricted.
This does not prevent viewport hidden or restricted collections from
being reactivated later. This could be added as a separate commit.
Excluded collections cannot be activated, so it may make sense to
extend this behavior to hiding collections.
|
|
T68035 by @luzpaz
|
|
Basically layer_collection_sync was calling BKE_base_eval_flags right away while
iterating over the bases.
However when a parent/sibling collection is to influence the collection flag of
an object that exists in more than one collection, it is too late since we
deselect the object in BKE_base_eval_flags right away.
Related to T64312.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D5243
|
|
|
|
How to reproduce: use 1-10 to change the visible collection. If the
collection was globally invisible, it would be set to globally visible.
This was a left over from the previous collection visibility design.
Now that we have a more clear separation between temporary visibility
(i.e., layer collection visibiilty) and a global visibility setting
(i.e., collection visibility) we should keep them separated.
|
|
|
|
This also makes `IDP_CopyProperty` the "opposite"
of `IDP_FreeProperty`, which is what I'd expect.
Two refactoring steps:
* rename IDP_FreeProperty to IDP_FreePropertyContent
* new IDP_FreeProperty function that actually frees the property
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4872
|
|
No major API change here, only in the outliner restriction column
variables (e.g., show_restrict_column_selectable > show_restrict_column_select).
* Get rid of _INSTANCE (introduced on b1af68200159).
* Differentiate (everywhere but the API) between HIDE (temporary) and VIEWPORT (global).
* Use the expected icon for restrict viewport (same as objects and modifiers).
* selectable > select
|
