This issue was that `BKE_object_eval_uber_data` was not called for
the text object, because its geometry was not dependent upon
and its `is_directly_visible` tag was `false`. The crash happens in
rendering code, because the evaluated data is missing.
This not only affects text objects, but all object types that have a
geometry component that geometry nodes does not support yet.
The solution is to just add the missing dependencies.
Differential Revision: https://developer.blender.org/D11385
Root of the issue was actually hidden deep in depsgraph itself: it would
not properly update all of its COW IDs using a datablock when depsgraph
decides to evaluate or un-evaluate it.
This would lead to evaluated IDs pointing to either:
- orig IDs when there was an evaluated version of those (annoying bug,
but not a crashing one).
- old address of previously evaluated IDs that no longer exists in the
depsgraph (causing the crash from the report e.g.).
This commit adds an extra step at the end of nodes building, that goes
over all of already existing IDs in the depsgraph to check whether they
do one of the two things above, and tag them for COW update if so.
NOTE: This only affects depsgraph (re-)building, not its evaluation.
This remains consistent with the fact that operations that may change
the depsgraph content (like Collection exclusion etc.) need to trigger a
rebuild.
NOTE: Performances: Worst case scenarii, like (un-)excluding a whole
character collection in a production file, lead to 5% to 10% extra
processing time in depsgraph building. Most of it comming from extra COW
processing (in depsgraph's update in `build_step_finalize`), the detection
loop itself only accounts for 1% to 2% of the whole building time.
Maniphest Tasks: T85752
Differential Revision: https://developer.blender.org/D10907
Share the pointer with the original mesh instead, this matches behavior
of all other objects edit-mode data.
Duplicating the edit-mesh pointer makes updates to edit-mesh require
a COPY_ON_WRITE update, which is currently an expensive operation
(copying the entire mesh).
Notes:
- This change is from 802027f3f8
so the edit-meshes object pointer `BMEditMesh.ob` referenced the COW
version of the object. This pointer has since been removed, so the
copy is no longer needed.
- Having a separate edit-mesh pointer could be used so linked duplicates
could have their own generated meshes. For this to be supported,
many other changes would be needed: see D10920.
Resolve ownership ambiguity with shared physics pointers.
Previously, LIB_ID_CREATE_NO_MAIN allowed pointer sharing with
the source ID so physics caches can be shared between original and
evaluated data: (Object.soft.shared & Object.rigidbody_object.shared).
This only worked properly for LIB_TAG_COPIED_ON_WRITE ID's,
as LIB_TAG_NO_MAIN can be used in situations where the original ID's
lifetime limited by it's original data.
This commit adds `LIB_ID_COPY_SET_COPIED_ON_WRITE` so ID's only share
memory with original data for ID's evaluated in the depsgraph.
For all other uses, a full copy of physics data is made.
Ref D11228#287094
The sockets are not exposed in any nodes yet.
They work similar to the Object/Collection sockets, which also
just reference a data block.
This is part of D11222.
Issue was caused by anim handle being reset by
`DEG_evaluate_on_framechange()`
Preserve anim handle by backing it up in
`blender::deg::SequenceBackup`
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11059
This fixes T87666 and T83252.
The boolean modifier and geometry nodes can depend on the geometry
of an entire collection. Before, the modifiers had to manually create relations
to all the objects in the collection. This worked for the most part, but was
cumbersome and did not solve all issues. For example, the modifiers were not
properly updated when objects were added/removed from the referenced collection.
This commit introduces the concept of "collection geometry" in the depsgraph.
The geometry of a collection depends on the transforms and geometry of all
the objects in it. The boolean modifier and geometry nodes can now just depend
on the collection geometry instead of creating all the dependencies themselves.
Differential Revision: https://developer.blender.org/D11053
Some persistent data code was disable due to a deeper design issue, which
meant some updates were not communicated to renderers.
Dependency graph updates work in two passes, once where Blender scene
animation updates are done, then app handler scripts can run to make further
scene modifications, and then the depsgraph is updated again to take those
into account.
Previously the viewport would update renderers twice when such app handler
scripts were present. Now both viewport and persistent data rendering update
the renderers only once, accumulating updates from both passes.
Fix `nullptr` redeference when setting 'orig_data' pointers on CoW copies,
by stopping the loop also when `element_cow == nullptr`. This avoids a
crash of Blender when the original list of pointers is longer than the
CoW list of pointers.
I've also added a `BLI_assert()` that checks for equal lengths of the
two `ListBase`s, so that problems like these aren't hidden away completely.
The root cause of the crash was actually a modifier that was assigned to
an object of the wrong type (an Armature object doesn't support modifiers).
This caused the list of modifiers on the CoW copy to be shorter than the
list of modifiers on the original Object. It's still a mystery how that
object got that modifier in the first place.
This removes a lot of unnecessary code that is generated by
the compiler automatically.
In very few cases, a defaulted destructor in a .cc file is
still necessary, because of forward declarations in the header.
I removed some defaulted virtual destructors, because they are not
necessary, when the parent class has a virtual destructor already.
Defaulted constructors are only necessary when there is another
constructor, but the class should still be default constructible.
Differential Revision: https://developer.blender.org/D10911
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
Handle Lattice object the same way as Mesh objects. This is mostly to
execute the `object->data = data_eval;` line, which ensures that the
evaluated mesh is assigned to the evaluated object, and thus prevents
the lattice from un-deforming.
This adds the LineArt grease pencil modifier.
It takes objects or collections as input and generates various grease
pencil lines from these objects with the help of the active scene
camera. For example it can generate contour lines, intersection lines
and crease lines to name a few.
This is really useful as artists can then use 3D meshes to automatically
generate grease pencil lines for characters, enviroments or other
visualization purposes.
These lines can then be baked and edited as regular grease pencil lines.
Reviewed By: Sebastian Parborg, Antonio Vazquez, Matias Mendiola
Differential Revision: http://developer.blender.org/D8758
The `MAX_LIBARRAY` define was an annoying doublon to the `INDEX_ID_MAX` enum value
now defined in `DNA_ID.h`, and it is no more useful.
And comments were somewhat outdated. Also added an explanation about
chosen order for the `INDEX_ID_<IDTYPE>` order.
Rename:
- `BKE_animsys_store_rna_setting` → `BKE_animsys_rna_path_resolve`
- `BKE_animsys_read_rna_setting` → `BKE_animsys_read_from_rna_path`
- `BKE_animsys_write_rna_setting` → `BKE_animsys_write_to_rna_path`
The concept of "RNA setting" is unclear; the new names reflect better
what the functions actually do.
No functional changes.
Make the SHADING_PARAMETERS operation on node tree a real no-op.
The function used as a callback was only doing a debug print.
The issue with this function was that an original ID was passed
as an argument. This is a violation of design, and if anything it
should be left up to the implementation to check whether depsgraph
is active.
There are no functional changes for users in the interface. The
only difference is that the debug print will no longer happen.
Resolves modernize-raw-string-literal Clang-Tidy warning
The way warning works is it suggests to use raw literal when
overhead of having escape characters is higher than the overhead
of having raw literal syntax (talking about code size overhead).
This means that the warning will not trigger for "foo\"bar".
Differential Revision: https://developer.blender.org/D10322
This change removes copy-on-write operations from ID nodes which do not
need copy-on-write.
Should be no functional changes, as before the copy-on-write operation
would do nothing for those nodes anyway.
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
Previously this relied on the dependency graph to detect changes in the screen
datablock, which would then notify the renderers. This was rather indirect an
not even really by design. Instead use notifiers to tag specific 3D viewports
to be updated.
Includes changes to BKE_scene_get_depsgraph to accept a const Scene pointer.
Testing if this works correctly requires adding back commits 81d444c and 088904d,
since those have been temporarily reverted.
Differential Revision: https://developer.blender.org/D10235
If a force field was of type "Texture", any changes of that texture (e.g.
its type - as reported in T85139 - or also its properties) were not
properly updating rigid bodies and particle systems.
Now ensure that texture is actually in the depsgraph and set up relation
accordingly.
Also fixes T75198.
Maniphest Tasks: T85139
Differential Revision: https://developer.blender.org/D10234
This reverts commit 76fd41e9db. This should have
been reverted along with 0f95f51361, since this
change by itself is causing crashes when the depsgraph accesses a non-existent
copy-on-write component.
Ref T84717
Technically, the crash was caused by revert which happened in
rBcd24712c2c5: it reverted some code which is essential for
rB76fd41e9db1.
Bring back the essential code for the removal of un-needed
Copy-on-Write operations, so that the crash doesn't happen.
What was causing the crash is the ID tag assuming Copy-on-Write
operation always exists.
Revert "Fix T83411: Crash when using a workspace/layout data path in a driver"
The fix for the crash exposed design violation in the viewport shading updates,
which is for some reason relying on dependency graph tag of interface data.
The viewport module did not respond to the issue in 2 weeks, and the architect
considered missing update for multiple users a more serious issue than a crash
in a very specific case.
This reverts commit 0f95f51361.
For the most part, this just adds boilerplate code for volume support in geometry nodes:
* Add `VolumeComponent` next to `MeshComponent`, etc.
* Support `VolumeComponent` in depsgraph object iterator.
Furthermore, I added initial volume support in a few nodes:
* The Object Info node outputs an object instance when the input is a volume object
(that will be the same for mesh objects soonish, to avoid copies).
* Support transforming a `VolumeComponent` in the Transform node.
* Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the
inputs has a volume component for now.
Right now, there is no way to create a `VolumeComponent`, because the Object Info node
outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes,
which will generate volumes on the fly.
Viewport selection does not work correctly with `VolumeComponent`s currently. I don't
know why that is. That can be figured out a bit later, once we can actually create
new volumes in geometry nodes.
Ref T84604.
Differential Revision: https://developer.blender.org/D10147
The WORLD_UPDATE operation (needed to free the gpu material) was already
defined in DepsgraphNodeBuilder::build_world, but corresponding relation
was only set up for changes in the nodetree, not for changes in the
world/material itself in DepsgraphRelationBuilder::build_world.
Direct changes to these surface properties in the UI were updating
properly through RNA property update callbacks, but these are not called
from the animation system.
So now add these relations in the depsgraph.
Not 100% sure this is the right place for this (since e.g. eevee engine
seems to handle e.g. animated light paramters just fine through
EEVEE_cache_populate / eevee_light_setup, but properly freeing gpu
materials wont happen for worlds in e.g eevee_id_world_update and also
not for materials)
Maniphest Tasks: T84250
Differential Revision: https://developer.blender.org/D9959
