While this was not a critical issue (that lib pointer is only used for
some kind of sanity check that no linked data uses local ID pointers),
better to keep `IDP_BlendReadLib` in sync with all other lib-linking
code.
As discussed, this only updates objects in and the world of the scene to which the view layer belongs, which also avoids the problem of not having a BMain available.
Differential Revision: https://developer.blender.org/D14740
Actualy 'safe' building of the base has in view layers (as part of
`BKE_main_collection_sync_remap`) would only happen when there was
already an existing one, otherwise it was skipped, and rebuilt later
(without the support for doublons) in collection sync code.
Very odd that that error was never spotted before, issue in code has
been there for a long time already. Probably only happens in rare cases
(specific conjuction of factors during remapping of old ID into itelf
new id)?
Reported by @hjalti from Blender studio. Reproducing case:
`heist/pro/shots/050_alarm/050_0160/050_0160.anim.blend`, r1407
We better handle NULL object pointers before doing layer collections
resync, otherwise said resync process has to deal with those NULL
pointers. By the look of it this mistake has been there since the origin
of the remapping/relinking code.
Also for safety (and optimization), do not perform layer collection
resync from `libblock_remap_data_postprocess_object_update` when
`libblock_remap_data_postprocess_collection_update` is called
immediately afterwards.
Also added same 'skip on NULL collection object pointer' check to
`layer_collection_local_sync` as the one in
`layer_collection_objects_sync`, since it's fairly hard to always
guaranty there is no such NULL pointer when calling that code.
Currently, only Lightgroups that exist in the current view layer can be
selected from object or world properties.
The internal UI code already has support for search fields that accept
unknown input, so I just added that to the API and use it for lightgroups.
When a lightgroup is entered that does not exist in the current view layer
(e.g. because it's completely new, because the view layer was switched or
because it was deleted earlier), a new button next to it becomes active and
adds it to the view layer when pressed.
Differential Revision: https://developer.blender.org/D14540
Light groups are a type of pass that only contains lighting from a subset of light sources.
They are created in the View layer, and light sources (lamps, objects with emissive materials
and/or the environment) can be assigned to a group.
Currently, each light group ends up generating its own version of the Combined pass.
In the future, additional types of passes (e.g. shadowcatcher) might be getting their own
per-lightgroup versions.
The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render
engines could make use of it in the future.
Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup
in the View Layer and the name that's set in an object's settings must match for it to be
included.
Currently, changing a Lightgroup's name does not update objects - this is planned for the
future, along with other features such as denoising for light groups and viewing them in
preview renders.
Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97).
Differential Revision: https://developer.blender.org/D12871
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Layer resync code would not yet fully properly deal with all possible
invalid status of ViewLayer comming from those older files.
Now put 2.80-doversion specific fixes into their own dedicated
function, so that they do not affect actual regular layer resync code
anymore. Also added some sanity-checks in main
`BKE_layer_collection_sync` code.
`BKE_layer_collection_sync` was missing a specific handling for one of
those pre-master collection cases,
NOTE: It is a bit unfortunate to have to do 'do-version' code in BKE...
At some point might look into moving this into actual `do_version` file,
but this is not fully trivial not critical improvement for now.
This commit fixes the crash itself, however this can still lead to a
same collection 'owning' the same object several time.
Issue here was a bad assumption in layer resync code, that would lead to
removing valid objects from the viewlayer's `object_bases_hash` in
`BKE_layer_collection_sync`, when deleting no-more-used bases, in case
of bases duplicate.
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
The Cycles accurate mode was removed, but the Eevee option for this has
a different meaning and should not have been removed. The Eevee accurate
makes cryptomatte accumulate for every sample, which Cycles has always
done regardless of any option.
Some compositing applications do not support spaces and dots in layer names, and change
these to other symbols on import. This causes various compatibility issues, including
with Cryptomatte metadata. While technically those could be considered bugs in the
Cryptomatte implementation of other software, where they are not properly accounting for
that layer renaming, it's not ideal.
The OpenEXR channel naming convention is "layer.pass.channel". We get away with dots in
the layer name since we parse this from right to left, but it's a weak assumption.
Now we don't forbid using spaces or dots, and existing files are unchanged. But at
least by default names will be compatible, and hopefully other software catches up in
time to support more flexible layer names.
Ref T68924
OpenEXR uses "." to separate layers/passes/channels, so using AOV.001 is
a problem. Other applications will not be able to parse it correctly.
Default to AOV_001 instead, and don't allow using dots in AOV names.
Fixes T89991
Ref T73266
Ref D12871
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycleshttps://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
Add a debug-only check regarding consistency of the cache (mapping from
objects to their bases) for a given ViewLayer.
Issues can happen otherwise when some code does remapping of objects,
and forgets to call `BKE_main_collection_sync_remap()` (which clears
those caches) instead of `BKE_main_collection_sync()`.
The immediate reason for this is that we want to be able to initialize them
to different defaults for light objects, which is hard with Python properties.
But in general it is useful to be able to share these with other renderers.
As a side effect, Eevee now supports a per-object holdout instead of only
per-collection.
Differential Revision: https://developer.blender.org/D12133
This makes the internal naming consistent with the public API. And also gives
us a visibility_flag rather than restrictflag that can be extended with more
flags.
It was somewhat arbitrary to have this one pass enabled that adds a bit of
additional memory and render time overhead, even though it's not necessarily
more important than others.
The goal of this refactor is to improve resync of LayerCollections
hierarchy to match again Collection one.
Current code would destroy and re-create valid layers whenever a parent
collection would be removed, which leads to losing way too often
layer-related settings when editing collection hierarchies.
While this could be partially addressed from operators side, there was
no way to fix those issues from lower level, more generic ID management
code like ID remapping or library override resync processes.
The new code builds a shallow wrapper around existing (aka old) layers
hierarchy, does a set of checks to define the status of all existing
layers, and try to find the closest matching unused layer in cases where
layers and collections hierarchies do not match anymore.
The intent is to both re-use as much as possible existing layers, and
to pick the 'best' possible layer to re-use, following those heuristics:
* Prefer layers children of current one first (in old hierarchy), and only
use those from other higher-level hierarchies if no (grand-)child is found.
* Prefer to use closest layers available in the old hierarchy.
NOTE: The new code is about 12%-15% slower than the previous one, which is
expected given the increased complexity. Note that this would not be an
issue in practice if this code was not called way too often (needs to
be converted to lazy update instead, which is a long known TODO).
NOTE: The LayerCollectionResync code uses its own built-in version of
FIFO queue, as performances in this code is currently a critical point
(it can get called tens of thousands of times during a single (heavy)
ID management operation currently, in a production file e.g.).
Differential Revision: https://developer.blender.org/D12016
Recent own rBabf3ce811f6e prevented any LayerCollection update during
the whole liboverride resync process, for both performances and feature
reasons.
However that means that the various runtime caches like the Base GHash
are not cleared anymore during ID remapping process, so we need to call
`BKE_main_collection_sync_remap` instead of `BKE_main_collection_sync`
when we finally are ready for this update.
Reported by @eyecandy (Andy Goralczyk) from Blender studio, thanks!
This is an easy & safe, yet not-so-nice way to address the
LayerCollections vs. Collections hierarchy resync problem.
Currently this resync is enforced everytime something changes in the
Collections hierarchy, which is extremely inneficient, and can even
produce 'loss' of LayerCollection data during complex Collection
processes.
Current example is during Library Overrides resync process. New code:
* Makes resync significantly faster (between 10 and 15%).
* Fixes 'disappearing' layer collections settings on sub-collections'
layers.
NOTE: This is not a proper fix for the underlying issue. However,
implementing and testing the 'lazy update' solution as proposed by
{T73411} requires a significant amount of time (especially in testing
and tracking all places where code would need to ensure LayerCollections
are up-to-date), which is not possible currently.
Differential Revision: https://developer.blender.org/D11889
Mainly naming (also droping the `layer_collection` in favor of just
`layer` for internal code, this is clear enough and much shorter). Add
proper parent/child identifiers, `r_` prefix for parameters also used as
return values, etc.
Also made some parameters const.
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.
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.
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
