| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Active camera is a property of Scene, so need to take scene changes into
account for such drivers to work reliably.
The fix covers all the common cases of such configurations, but some of
them might not be yet fully supported. Mainly cases when the target ID
is not covered by the copy-on-write mechanism.
There is a fuller explanation available in the code for the ease of reading
by the future generations.
Differential Revision: https://developer.blender.org/D15146
|
|
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
|
|
|
|
Mostly duplicate includes, also use nullptr, and using default
member initializers.
|
|
`bNodeTree` has a lot of run-time embedded in it currently. Having a separately
allocated run-time struct has some benefits:
* Run-time data is not stored in files.
* Makes it easy to use c++ types as run-time data.
* More clear distinction between what data only exists at run-time and which doesn't.
This commit doesn't move all run-time data to the new struct yet, only the data where
I know for sure how it is used. The remaining data can be moved separately.
Differential Revision: https://developer.blender.org/D15033
|
|
|
|
This is a regression caused by a230445caec6.
The internal cause of the issue was that the synchronization component
was no longer tagged as visible (and hence not evaluated) as it not
connected to any directly visible IDs.
Changed the logic in a way that if any component of an ID is evaluated
the synchronization component will be evaluated as well.
The naming of the flag in the component node is a bit confusing, but
for the simplicity of the change for the upcoming release left it
unchanged.
|
|
|
|
The goal is to make it easier to track down sources of errors during
the dependency graph builder.
With this change whenever a relation can not be added a trace to the
entity which requested the relation will be printed. For example:
```
Failed to add relation "Copy Location"
Could not find op_from: OperationKey(type: BONE, component name: 'MissingBone', operation code: BONE_DONE)
Trace:
Depth Type Name
----- ---- ----
1 Object Armature.001
2 Pose Channel Bone
3 Constraint Copy Location
```
On an implementation detail traced places where `checkIsBuiltAndTag`
is called, with some additional places to help tracking pose channels,
constraints, and modifiers.
Further improvements in granularity are possible, but that could happen
as a followup development once the core part is proven to work.
An example of such improvement would be to have entries in the trace
which will indicate NLA and drivers building. Currently it might be
a bit confusing to see IDs in the trace referenced from driver.
Even with such limitation the current state of the patch brings a
very valuable information (some information is much better than no
information at all).
Differential Revision: https://developer.blender.org/D15017
|
|
|
|
|
|
Previously, the depsgraph assumed that every node tree might contain
a reference to a video. This resulted noticeable overhead when there
was no video.
Checking whether a node tree contained a video was relatively expensive
to do in the depsgraph. It is cheaper now due to the structure of the new
node tree updater.
This also adds an additional run-time field to `bNodeTree` (there are
quite a few already). We should move those to a separate run-time
struct, but not as part of a bug fix.
Differential Revision: https://developer.blender.org/D14957
|
|
|
|
Fix a crash when a driver variable targets an object and uses
`data.shape_keys.key["name"].value` in its expression.
The fix consists of adding an extra relation from the targeted object's
`GEOMETRY` component to the driver evaluation. This ensures that its
`data` pointer has been evaluated by the depsgraph and is safe to
follow.
This also resolves the concern raised on rB56407432a6aa.
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D14956
|
|
|
|
The ID is not modified by this function, so it can be const.
Needed to tweak const correctness for original ID accessor as
well. Additionally, did the same for accessor of evaluated ID
for symmetry.
|
|
Originally was noticed when using a linked background scene and a scene
camera from another (local) scene.
The root issue was that relation from view layer to object's base flags
evaluation was using wrong view layer. This is because the relation was
created between object and currently built view layer, and it only was
happening once (since the object-level relations are only built once).
Depending on order in which `build_object` was called it was possible
that relation from a wrong view layer was used.
Now the code is better split to indicate which parts of object relations
are built when object comes from a base in the view layer, and which ones
are built on indirect linking of object to the dependency graph.
This patch makes relations correct in the cases when the same object is
used as a base in both active and set scenes. But, the operation which
handles object-level flags might not behave correctly as there is no
known design of what is the proper thing to do in this case. Making a
clear design and implementation of case when object is shared between
active and set scene is outside of the scope of this patch.
Differential Revision: https://developer.blender.org/D14626
|
|
Solves compilation warning with Clang, and moves manipulation with
DNA structures to the designed way for C++.
The tests and few other places are update to the new code by Jacques.
Ref T96847
Maniphest Tasks: T96847
Differential Revision: https://developer.blender.org/D14625
|
|
- Missing star prefix.
- Unnecessary indentation.
- Blank line after dot-points
(otherwise doxygen merges with the previous dot-point).
- Use back-slash for doxygen commands.
- Correct spelling.
|
|
This adds missing cases to detect edit mode for Curves objects.
Unlike other object types, Curves do not have specific edit data,
rather we edit the original data directly, and rely on `Object.mode`.
For this, `BKE_object_data_is_in_editmode` had to be modified to
take a pointer to the object. This affects two places: the outliner
and the dependency graph. For the former place, the object pointer
is readily available, and we can use it. For the latter, the object
pointer is not available, however since it is used to update edit
mode pointers, and since Curves do not have such data, we can
safely pass null to the function here.
This also fixes the assertion failure that happens when closing a file
in edit mode.
Differential Revision: https://developer.blender.org/D14330
|
|
Regression in [0] which missed excluding FRAME_CHANGE from
deg_recalc_flags_for_legacy_zero causing all
DEG_id_tag_update(&scene->id, 0) calls to re-calculate animation data.
When this tagging was done in the RNA update function, changing
key-framed values in the UI would be immediate reset to their
keyed-values.
Thanks to Philipp Oeser for finding the root cause.
[0]: 35aedd87e78d44aa0a622d26261ecac7ece12925
|
|
The Alembic procedural was only enabled during viewport renders
originally because it did not have any caching strategy. Now that
is does, we can allow its usage in final renders.
This also removes the `dag_eval_mode` argument passing to
`ModifierTypeInfo.dependsOnTime` which was originally added to detect if
we are doing a viewport render for enabling the procedural.
Differential Revision: https://developer.blender.org/D14520
|
|
Checking BKE_image_user_id_has_animation loops over ID users
which never needs to run for material & world data-blocks.
|
|
|
|
|
|
|
|
This change makes it possible to add implementation of common
C++ methods for DNA structures which helps ensuring unsafe
operations like shallow copy are done explicitly.
For example, creating a shallow copy used to be:
Object temp_object = *input_object;
In the C++ context it was seen like the temp_object is
properly decoupled from the input object, while in the
reality is it not. Now this code becomes:
Object temp_object = blender::dna::shallow_copy(*input_object);
The copy and move constructor and assignment operators are
now explicitly disabled.
Other than a more explicit resource management this change
also solves a lot of warnings generated by the implicitly
defined copy constructors w.r.t dealing with deprecated fields.
These warnings were generated by Apple Clang when a shallow
object copy was created via implicitly defined copy constructor.
In order to enable C++ methods for DNA structures a newly added
macro `DNA_DEFINE_CXX_METHODS()` is to be used:
tpyedef struct Object {
DNA_DEFINE_CXX_METHODS(Object)
...
} Object;
For the shallow copy use `blender::dna::shallow_copy()`.
The implementation of the memcpy is hidden via an internal DNA
function to avoid pulling `string.h` into every DNA header.
This means that the solution does not affect on the headers
dependencies.
---
Ideally `DNA_shallow_copy` would be defined in a more explicit
header, but don;t think we have a suitable one already. Maybe
we can introduce `DNA_access.h` ?
Differential Revision: https://developer.blender.org/D14427
|
|
This reverts commit 8c44793228750537c08ea7b19fc18df0138f9501.
Apparently, this generated a lot of warnings in GCC.
Didn't find a quick solution and is it not something I want to be
trading between (more quiet Clang in an expense of less quiet GCC).
Will re-iterate on the patch are re-commit it.
|
|
This change makes it possible to add implementation of common
C++ methods for DNA structures which helps ensuring unsafe
operations like shallow copy are done explicitly.
For example, creating a shallow copy used to be:
Object temp_object = *input_object;
In the C++ context it was seen like the temp_object is
properly decoupled from the input object, while in the
reality is it not. Now this code becomes:
Object temp_object = blender::dna::shallow_copy(*input_object);
The copy and move constructor and assignment operators are
now explicitly disabled.
Other than a more explicit resource management this change
also solves a lot of warnings generated by the implicitly
defined copy constructors w.r.t dealing with deprecated fields.
These warnings were generated by Apple Clang when a shallow
object copy was created via implicitly defined copy constructor.
In order to enable C++ methods for DNA structures a newly added
macro `DNA_DEFINE_CXX_METHODS()` is to be used:
tpyedef struct Object {
DNA_DEFINE_CXX_METHODS(Object)
...
} Object;
For the shallow copy use `blender::dna::shallow_copy()`.
The implementation of the memcpy is hidden via an internal DNA
function to avoid pulling `string.h` into every DNA header.
This means that the solution does not affect on the headers
dependencies.
---
Ideally `DNA_shallow_copy` would be defined in a more explicit
header, but don;t think we have a suitable one already. Maybe
we can introduce `DNA_access.h` ?
Differential Revision: https://developer.blender.org/D14427
|
|
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3dbec we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
|
|
|
|
|
|
This quick fix will populate the runtime orig pointers to avoid
crashes when a grease pencil object uses layer transforms, parenting
or modifiers.
This will have to be revisited and fixed with a better solution.
|
|
|
|
Differential Revision: https://developer.blender.org/D14260
|
|
|
|
previously_visible_components_mask was not preserved for Image ID nodes, which
meant it was always detected as newly visible and tagged to be updated, which
in turn caused the geometry nodes using it to be always updated also.
Reviewed By: sergey, JacquesLucke
Maniphest Tasks: T94609
Differential Revision: https://developer.blender.org/D14217
|
|
|
|
Caused by 0f89bcdbebf5 and was not fully addressed by 6f9828289f39:
tagging an ID with flag 0 is to be seen as an explicit tag for copy
on write.
Would be nice to either consolidate code paths of flag 0 and explicit
component tag, or get rid of tagging with 0 flag, but that is above of
what we can do for the upcoming release.
|
|
|
|
Make relation match material and world nodes. Does not address the reported
issue regarding muted nodes, but another missing update found investigating.
|
|
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
|
|
Use using instead of typedef, remove redundant string init,
use "empty", address qualified auto, use nullptr.
|
|
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
|
|
|
|
|
|
The main issue is that the image and image user is not updated correctly
in `rna_ImageUser_update`. `BKE_image_user_frame_calc` does not set the
correct frame, because the image is null. Also `IMA_GPU_REFRESH` is not
set for the same reason.
When gpu materials are first created, it is expected that the frame is set
correctly, and the flag is set if necessary. Therefore, somewhere during
depsgraph evaluation, those have to be updated. The depsgraph node
to do the update existed already. Now there is a new relation so that it is
executed when the node tree changed, not only when the frame changed.
|
|
This implements the update cache described in T95401.
The cache is currently only used for drawing strokes and
sculpting (using the push brush).
**Note: Making use of the cache throughout grease pencil will
have to be done incrementally in other patches. **
The update cache stores what elements have changed in the
original data-block since the last time the eval object
was updated. Additionally, the update cache can store multiple
updates to the data and minimizes the number of elements
that need to be copied.
Elements can be tagged using `BKE_gpencil_tag_full_update` and
`BKE_gpencil_tag_light_update`. A full update means that the element
itself will be copied but also all of the content inside. E.g. when a
layer is tagged for a full update, the layer, all the frames inside the
layer and all the strokes inside the frames will be copied.
A light update means that only the properties of the element are copied
without any of the content. E.g. if a layer is tagged with a light
update, it will copy the layer name, opacity, transform, etc.
When the update cache is in use (e.g. elements have been tagged) then
the depsgraph will not trigger a copy-on-write, but an update-on-write.
This means that the update cache will be used to determine what elements
have changed and then only those elements will be copied over to the
eval object.
If the update cache is empty or the data block was tagged with a full
update, we always fall back to a copy-on-write.
Currently, the update cache is only used by the active depsgraph. This
is because we need to free the update cache after an update-on-write so
it's reset and we need to make sure it is not freed or read by other
depsgraphs.
Co-authored-by: @yann-lty
This patch was contributed by The SPA Studios.
Reviewed By: sergey, antoniov, #dependency_graph, pepeland, mendio
Maniphest Tasks: T95401
Differential Revision: https://developer.blender.org/D13984
|
|
Also some descriptive text into doc-strings.
|
