Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
/*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2013 Blender Foundation.
|
|
|
|
|
* All rights reserved.
|
2015-05-20 12:54:45 +10:00
|
|
|
*/
|
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup depsgraph
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
*
|
2018-08-23 01:24:48 +12:00
|
|
|
* Implementation of Querying API
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2020-12-04 11:28:09 +01:00
|
|
|
#include <cstring> /* XXX: memcpy */
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_listbase.h"
|
|
|
|
|
#include "BLI_utildefines.h"
|
2019-05-28 15:42:08 +02:00
|
|
|
|
|
|
|
|
#include "BKE_action.h" /* XXX: BKE_pose_channel_find_name */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
#include "BKE_customdata.h"
|
2020-03-19 19:37:00 +01:00
|
|
|
#include "BKE_idtype.h"
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
#include "BKE_main.h"
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
|
2017-04-21 11:42:59 +02:00
|
|
|
#include "DNA_object_types.h"
|
2017-04-20 17:09:18 +02:00
|
|
|
#include "DNA_scene_types.h"
|
|
|
|
|
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
#include "RNA_access.h"
|
|
|
|
|
|
2017-06-01 15:26:47 +02:00
|
|
|
#include "DEG_depsgraph.h"
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
#include "DEG_depsgraph_query.h"
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
#include "intern/depsgraph.h"
|
2018-04-12 09:47:51 +02:00
|
|
|
#include "intern/eval/deg_eval_copy_on_write.h"
|
2019-01-31 12:56:40 +01:00
|
|
|
#include "intern/node/deg_node_id.h"
|
Depsgraph: Initial groundwork for copy-on-write support
< Dependency graph Copy-on-Write >
--------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
This is an initial commit of Copy-on-write support added to dependency graph.
Main priority for now: get playback (Alt-A) and all operators (selection,
transform etc) to work with the new concept of clear separation between
evaluated data coming from dependency graph and original data coming from
.blend file (and stored in bmain).
= How does this work? =
The idea is to support Copy-on-Write on the ID level. This means, we duplicate
the whole ID before we cann it's evaluaiton function. This is currently done
in the following way:
- At the depsgraph construction time we create "shallow" copy of the ID
datablock, just so we know it's pointer in memory and can use for function
bindings.
- At the evaluaiton time, the copy of ID get's "expanded" (needs a better
name internally, so it does not conflict with expanding datablocks during
library linking), which means the content of the datablock is being
copied over and all IDs are getting remapped to the copied ones.
Currently we do the whole copy, in the future we will support some tricks
here to prevent duplicating geometry arrays (verts, edges, loops, faces
and polys) when we don't need that.
- Evaluation functions are operating on copied datablocks and never touching
original datablock.
- There are some cases when we need to know non-ID pointers for function
bindings. This mainly applies to scene collections and armatures. The
idea of dealing with this is to "expand" copy-on-write datablock at
the dependency graph build time. This might introduce some slowdown to the
dependency graph construction time, but allows us to have minimal changes
in the code and avoid any hash look-up from evaluation function (one of
the ideas to avoid using pointers as function bindings is to pass name
of layer or a bone to the evaluation function and look up actual data based
on that name).
Currently there is a special function in depsgraph which does such a
synchronization, in the future we might want to make it more generic.
At some point we need to synchronize copy-on-write version of datablock with
the original version. This happens, i.e., when we change active object or
change selection. We don't want any actual evaluation of update flush happening
for such thins, so now we have a special update tag:
DEG_id_tag_update((id, DEG_TAG_COPY_ON_WRITE)
- For the render engines we now have special call for the dependency graph to
give evaluated datablock for the given original one. This isn't fully ideal
but allows to have Cycles viewport render.
This is definitely a subject for further investigation / improvement.
This call will tag copy-on-write component tagged for update without causing
updates to be flushed to any other objects, causing chain reaction of updates.
This tag is handy when selection in the scene changes.
This basically summarizes ideas underneath this commit. The code should be
reasonably documented.
Here is a demo of dependency graph with all copy-on-write stuff in it:
https://developer.blender.org/F635468
= What to expect to (not) work? =
- Only meshes are properly-ish aware of copy-on-write currently, Non-mesh
geometry will probably crash or will not work at all.
- Armatures will need similar depsgraph built-time expansion of the copied
datablock.
- There are some extra tags / relations added, to keep things demo-able but
which are slowing things down for evaluation.
- Edit mode works for until click selection is used (due to the selection
code using EditDerivedMesh created ad-hoc).
- Lots of tools will lack tagging synchronization of copied datablock for
sync with original ID.
= How to move forward? =
There is some tedious work related on going over all the tools, checking
whether they need to work with original or final evaluated object and make
the required changes.
Additionally, there need synchronization tag done in fair amount of tools
and operators as well. For example, currently it's not possible to change
render engine without re-opening the file or forcing dependency graph for
re-build via python console.
There is also now some thoughts required about copying evaluated properties
between objects or from collection to a new object. Perhaps easiest way
would be to move base flag flush to Object ID node and tag new objects for
update instead of doing manual copy.
here is some WIP patch which moves such evaluaiton / flush:
https://developer.blender.org/F635479
Lots of TODOs in the code, with possible optimization.
= How to test? =
This is a feature under heavy development, so obviously it is disabled by
default. The only reason it goes to 2.8 branch is to avoid possible merge
hell.
In order to enable this feature use WITH_DEPSGRAPH_COPY_ON_WRITE CMake
configuration option.
2017-06-14 10:26:24 +02:00
|
|
|
|
2020-06-29 15:19:56 +02:00
|
|
|
namespace deg = blender::deg;
|
|
|
|
|
|
2018-04-06 09:17:53 +02:00
|
|
|
struct Scene *DEG_get_input_scene(const Depsgraph *graph)
|
|
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2018-04-06 09:17:53 +02:00
|
|
|
return deg_graph->scene;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ViewLayer *DEG_get_input_view_layer(const Depsgraph *graph)
|
|
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2018-04-06 09:17:53 +02:00
|
|
|
return deg_graph->view_layer;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 15:45:58 +02:00
|
|
|
struct Main *DEG_get_bmain(const Depsgraph *graph)
|
|
|
|
|
{
|
|
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
|
|
|
|
return deg_graph->bmain;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-06 09:17:53 +02:00
|
|
|
eEvaluationMode DEG_get_mode(const Depsgraph *graph)
|
|
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2018-04-06 09:17:53 +02:00
|
|
|
return deg_graph->mode;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
float DEG_get_ctime(const Depsgraph *graph)
|
|
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2018-04-06 09:17:53 +02:00
|
|
|
return deg_graph->ctime;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-29 15:57:14 +02:00
|
|
|
bool DEG_id_type_updated(const Depsgraph *graph, short id_type)
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2020-03-19 19:37:00 +01:00
|
|
|
return deg_graph->id_type_updated[BKE_idtype_idcode_to_index(id_type)] != 0;
|
2018-05-29 15:57:14 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool DEG_id_type_any_updated(const Depsgraph *graph)
|
|
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2018-05-29 15:57:14 +02:00
|
|
|
|
|
|
|
|
/* Loop over all ID types. */
|
2020-12-07 12:21:11 +01:00
|
|
|
for (char id_type_index : deg_graph->id_type_updated) {
|
|
|
|
|
if (id_type_index) {
|
2018-05-29 15:57:14 +02:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
}
|
|
|
|
|
|
2019-05-28 09:11:55 +02:00
|
|
|
bool DEG_id_type_any_exists(const Depsgraph *depsgraph, short id_type)
|
|
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(depsgraph);
|
2020-03-19 19:37:00 +01:00
|
|
|
return deg_graph->id_type_exist[BKE_idtype_idcode_to_index(id_type)] != 0;
|
2019-05-28 09:11:55 +02:00
|
|
|
}
|
|
|
|
|
|
2018-10-24 19:38:50 +03:00
|
|
|
uint32_t DEG_get_eval_flags_for_id(const Depsgraph *graph, ID *id)
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
{
|
2020-01-28 14:50:13 +01:00
|
|
|
if (graph == nullptr) {
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
/* Happens when converting objects to mesh from a python script
|
|
|
|
|
* after modifying scene graph.
|
|
|
|
|
*
|
|
|
|
|
* Currently harmless because it's only called for temporary
|
2019-01-31 12:56:40 +01:00
|
|
|
* objects which are out of the DAG anyway. */
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
|
|
|
|
const deg::IDNode *id_node = deg_graph->find_id_node(DEG_get_original_id(id));
|
2020-01-28 14:50:13 +01:00
|
|
|
if (id_node == nullptr) {
|
Depsgraph: New dependency graph integration commit
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
|
|
|
/* TODO(sergey): Does it mean we need to check set scene? */
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return id_node->eval_flags;
|
|
|
|
|
}
|
2017-04-20 17:09:18 +02:00
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
void DEG_get_customdata_mask_for_object(const Depsgraph *graph,
|
|
|
|
|
Object *ob,
|
|
|
|
|
CustomData_MeshMasks *r_mask)
|
2018-12-03 18:09:45 +03:00
|
|
|
{
|
2020-01-28 14:50:13 +01:00
|
|
|
if (graph == nullptr) {
|
2018-12-03 18:09:45 +03:00
|
|
|
/* Happens when converting objects to mesh from a python script
|
|
|
|
|
* after modifying scene graph.
|
|
|
|
|
*
|
|
|
|
|
* Currently harmless because it's only called for temporary
|
2019-01-31 12:56:40 +01:00
|
|
|
* objects which are out of the DAG anyway. */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
return;
|
2018-12-03 18:09:45 +03:00
|
|
|
}
|
|
|
|
|
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
|
|
|
|
const deg::IDNode *id_node = deg_graph->find_id_node(DEG_get_original_id(&ob->id));
|
2020-01-28 14:50:13 +01:00
|
|
|
if (id_node == nullptr) {
|
2018-12-03 18:09:45 +03:00
|
|
|
/* TODO(sergey): Does it mean we need to check set scene? */
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
return;
|
2018-12-03 18:09:45 +03:00
|
|
|
}
|
|
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
r_mask->vmask |= id_node->customdata_masks.vert_mask;
|
|
|
|
|
r_mask->emask |= id_node->customdata_masks.edge_mask;
|
|
|
|
|
r_mask->fmask |= id_node->customdata_masks.face_mask;
|
|
|
|
|
r_mask->lmask |= id_node->customdata_masks.loop_mask;
|
|
|
|
|
r_mask->pmask |= id_node->customdata_masks.poly_mask;
|
2018-12-03 18:09:45 +03:00
|
|
|
}
|
|
|
|
|
|
2018-01-17 12:26:43 +01:00
|
|
|
Scene *DEG_get_evaluated_scene(const Depsgraph *graph)
|
2017-04-20 17:09:18 +02:00
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2018-04-25 14:58:19 +02:00
|
|
|
Scene *scene_cow = deg_graph->scene_cow;
|
2019-06-12 09:04:10 +10:00
|
|
|
/* TODO(sergey): Shall we expand data-block here? Or is it OK to assume
|
2019-11-27 14:54:53 +11:00
|
|
|
* that caller is OK with just a pointer in case scene is not updated yet? */
|
2020-06-29 15:19:56 +02:00
|
|
|
BLI_assert(scene_cow != nullptr && deg::deg_copy_on_write_is_expanded(&scene_cow->id));
|
2018-04-12 09:47:51 +02:00
|
|
|
return scene_cow;
|
2017-04-20 17:09:18 +02:00
|
|
|
}
|
2017-04-20 18:59:47 +02:00
|
|
|
|
2018-01-17 12:26:43 +01:00
|
|
|
ViewLayer *DEG_get_evaluated_view_layer(const Depsgraph *graph)
|
2017-04-20 18:59:47 +02:00
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = reinterpret_cast<const deg::Depsgraph *>(graph);
|
2017-11-09 16:42:10 +01:00
|
|
|
Scene *scene_cow = DEG_get_evaluated_scene(graph);
|
2020-01-28 14:50:13 +01:00
|
|
|
if (scene_cow == nullptr) {
|
|
|
|
|
return nullptr; /* Happens with new, not-yet-built/evaluated graphes. */
|
2018-08-02 17:15:56 +02:00
|
|
|
}
|
2018-04-12 09:47:51 +02:00
|
|
|
/* Do name-based lookup. */
|
|
|
|
|
/* TODO(sergey): Can this be optimized? */
|
2017-11-22 10:52:39 -02:00
|
|
|
ViewLayer *view_layer_orig = deg_graph->view_layer;
|
|
|
|
|
ViewLayer *view_layer_cow = (ViewLayer *)BLI_findstring(
|
|
|
|
|
&scene_cow->view_layers, view_layer_orig->name, offsetof(ViewLayer, name));
|
2020-01-28 14:50:13 +01:00
|
|
|
BLI_assert(view_layer_cow != nullptr);
|
2017-11-22 10:52:39 -02:00
|
|
|
return view_layer_cow;
|
2017-04-20 18:59:47 +02:00
|
|
|
}
|
2017-04-21 11:29:47 +02:00
|
|
|
|
2018-01-17 12:26:43 +01:00
|
|
|
Object *DEG_get_evaluated_object(const Depsgraph *depsgraph, Object *object)
|
2017-04-21 11:29:47 +02:00
|
|
|
{
|
2017-07-13 12:57:19 +02:00
|
|
|
return (Object *)DEG_get_evaluated_id(depsgraph, &object->id);
|
Depsgraph: Initial groundwork for copy-on-write support
< Dependency graph Copy-on-Write >
--------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
This is an initial commit of Copy-on-write support added to dependency graph.
Main priority for now: get playback (Alt-A) and all operators (selection,
transform etc) to work with the new concept of clear separation between
evaluated data coming from dependency graph and original data coming from
.blend file (and stored in bmain).
= How does this work? =
The idea is to support Copy-on-Write on the ID level. This means, we duplicate
the whole ID before we cann it's evaluaiton function. This is currently done
in the following way:
- At the depsgraph construction time we create "shallow" copy of the ID
datablock, just so we know it's pointer in memory and can use for function
bindings.
- At the evaluaiton time, the copy of ID get's "expanded" (needs a better
name internally, so it does not conflict with expanding datablocks during
library linking), which means the content of the datablock is being
copied over and all IDs are getting remapped to the copied ones.
Currently we do the whole copy, in the future we will support some tricks
here to prevent duplicating geometry arrays (verts, edges, loops, faces
and polys) when we don't need that.
- Evaluation functions are operating on copied datablocks and never touching
original datablock.
- There are some cases when we need to know non-ID pointers for function
bindings. This mainly applies to scene collections and armatures. The
idea of dealing with this is to "expand" copy-on-write datablock at
the dependency graph build time. This might introduce some slowdown to the
dependency graph construction time, but allows us to have minimal changes
in the code and avoid any hash look-up from evaluation function (one of
the ideas to avoid using pointers as function bindings is to pass name
of layer or a bone to the evaluation function and look up actual data based
on that name).
Currently there is a special function in depsgraph which does such a
synchronization, in the future we might want to make it more generic.
At some point we need to synchronize copy-on-write version of datablock with
the original version. This happens, i.e., when we change active object or
change selection. We don't want any actual evaluation of update flush happening
for such thins, so now we have a special update tag:
DEG_id_tag_update((id, DEG_TAG_COPY_ON_WRITE)
- For the render engines we now have special call for the dependency graph to
give evaluated datablock for the given original one. This isn't fully ideal
but allows to have Cycles viewport render.
This is definitely a subject for further investigation / improvement.
This call will tag copy-on-write component tagged for update without causing
updates to be flushed to any other objects, causing chain reaction of updates.
This tag is handy when selection in the scene changes.
This basically summarizes ideas underneath this commit. The code should be
reasonably documented.
Here is a demo of dependency graph with all copy-on-write stuff in it:
https://developer.blender.org/F635468
= What to expect to (not) work? =
- Only meshes are properly-ish aware of copy-on-write currently, Non-mesh
geometry will probably crash or will not work at all.
- Armatures will need similar depsgraph built-time expansion of the copied
datablock.
- There are some extra tags / relations added, to keep things demo-able but
which are slowing things down for evaluation.
- Edit mode works for until click selection is used (due to the selection
code using EditDerivedMesh created ad-hoc).
- Lots of tools will lack tagging synchronization of copied datablock for
sync with original ID.
= How to move forward? =
There is some tedious work related on going over all the tools, checking
whether they need to work with original or final evaluated object and make
the required changes.
Additionally, there need synchronization tag done in fair amount of tools
and operators as well. For example, currently it's not possible to change
render engine without re-opening the file or forcing dependency graph for
re-build via python console.
There is also now some thoughts required about copying evaluated properties
between objects or from collection to a new object. Perhaps easiest way
would be to move base flag flush to Object ID node and tag new objects for
update instead of doing manual copy.
here is some WIP patch which moves such evaluaiton / flush:
https://developer.blender.org/F635479
Lots of TODOs in the code, with possible optimization.
= How to test? =
This is a feature under heavy development, so obviously it is disabled by
default. The only reason it goes to 2.8 branch is to avoid possible merge
hell.
In order to enable this feature use WITH_DEPSGRAPH_COPY_ON_WRITE CMake
configuration option.
2017-06-14 10:26:24 +02:00
|
|
|
}
|
|
|
|
|
|
2018-01-17 12:26:43 +01:00
|
|
|
ID *DEG_get_evaluated_id(const Depsgraph *depsgraph, ID *id)
|
Depsgraph: Initial groundwork for copy-on-write support
< Dependency graph Copy-on-Write >
--------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
This is an initial commit of Copy-on-write support added to dependency graph.
Main priority for now: get playback (Alt-A) and all operators (selection,
transform etc) to work with the new concept of clear separation between
evaluated data coming from dependency graph and original data coming from
.blend file (and stored in bmain).
= How does this work? =
The idea is to support Copy-on-Write on the ID level. This means, we duplicate
the whole ID before we cann it's evaluaiton function. This is currently done
in the following way:
- At the depsgraph construction time we create "shallow" copy of the ID
datablock, just so we know it's pointer in memory and can use for function
bindings.
- At the evaluaiton time, the copy of ID get's "expanded" (needs a better
name internally, so it does not conflict with expanding datablocks during
library linking), which means the content of the datablock is being
copied over and all IDs are getting remapped to the copied ones.
Currently we do the whole copy, in the future we will support some tricks
here to prevent duplicating geometry arrays (verts, edges, loops, faces
and polys) when we don't need that.
- Evaluation functions are operating on copied datablocks and never touching
original datablock.
- There are some cases when we need to know non-ID pointers for function
bindings. This mainly applies to scene collections and armatures. The
idea of dealing with this is to "expand" copy-on-write datablock at
the dependency graph build time. This might introduce some slowdown to the
dependency graph construction time, but allows us to have minimal changes
in the code and avoid any hash look-up from evaluation function (one of
the ideas to avoid using pointers as function bindings is to pass name
of layer or a bone to the evaluation function and look up actual data based
on that name).
Currently there is a special function in depsgraph which does such a
synchronization, in the future we might want to make it more generic.
At some point we need to synchronize copy-on-write version of datablock with
the original version. This happens, i.e., when we change active object or
change selection. We don't want any actual evaluation of update flush happening
for such thins, so now we have a special update tag:
DEG_id_tag_update((id, DEG_TAG_COPY_ON_WRITE)
- For the render engines we now have special call for the dependency graph to
give evaluated datablock for the given original one. This isn't fully ideal
but allows to have Cycles viewport render.
This is definitely a subject for further investigation / improvement.
This call will tag copy-on-write component tagged for update without causing
updates to be flushed to any other objects, causing chain reaction of updates.
This tag is handy when selection in the scene changes.
This basically summarizes ideas underneath this commit. The code should be
reasonably documented.
Here is a demo of dependency graph with all copy-on-write stuff in it:
https://developer.blender.org/F635468
= What to expect to (not) work? =
- Only meshes are properly-ish aware of copy-on-write currently, Non-mesh
geometry will probably crash or will not work at all.
- Armatures will need similar depsgraph built-time expansion of the copied
datablock.
- There are some extra tags / relations added, to keep things demo-able but
which are slowing things down for evaluation.
- Edit mode works for until click selection is used (due to the selection
code using EditDerivedMesh created ad-hoc).
- Lots of tools will lack tagging synchronization of copied datablock for
sync with original ID.
= How to move forward? =
There is some tedious work related on going over all the tools, checking
whether they need to work with original or final evaluated object and make
the required changes.
Additionally, there need synchronization tag done in fair amount of tools
and operators as well. For example, currently it's not possible to change
render engine without re-opening the file or forcing dependency graph for
re-build via python console.
There is also now some thoughts required about copying evaluated properties
between objects or from collection to a new object. Perhaps easiest way
would be to move base flag flush to Object ID node and tag new objects for
update instead of doing manual copy.
here is some WIP patch which moves such evaluaiton / flush:
https://developer.blender.org/F635479
Lots of TODOs in the code, with possible optimization.
= How to test? =
This is a feature under heavy development, so obviously it is disabled by
default. The only reason it goes to 2.8 branch is to avoid possible merge
hell.
In order to enable this feature use WITH_DEPSGRAPH_COPY_ON_WRITE CMake
configuration option.
2017-06-14 10:26:24 +02:00
|
|
|
{
|
2020-01-28 14:50:13 +01:00
|
|
|
if (id == nullptr) {
|
|
|
|
|
return nullptr;
|
2018-04-17 13:48:39 +02:00
|
|
|
}
|
2017-07-19 15:05:49 +02:00
|
|
|
/* TODO(sergey): This is a duplicate of Depsgraph::get_cow_id(),
|
|
|
|
|
* but here we never do assert, since we don't know nature of the
|
2019-06-12 09:04:10 +10:00
|
|
|
* incoming ID data-block. */
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = (const deg::Depsgraph *)depsgraph;
|
|
|
|
|
const deg::IDNode *id_node = deg_graph->find_id_node(id);
|
2020-01-28 14:50:13 +01:00
|
|
|
if (id_node == nullptr) {
|
2017-07-19 15:05:49 +02:00
|
|
|
return id;
|
|
|
|
|
}
|
|
|
|
|
return id_node->id_cow;
|
2017-04-21 11:29:47 +02:00
|
|
|
}
|
2017-04-21 11:42:59 +02:00
|
|
|
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
/* Get evaluated version of data pointed to by RNA pointer */
|
2018-05-19 19:12:26 +02:00
|
|
|
void DEG_get_evaluated_rna_pointer(const Depsgraph *depsgraph,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PointerRNA *r_ptr_eval)
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
{
|
2020-01-28 14:50:13 +01:00
|
|
|
if ((ptr == nullptr) || (r_ptr_eval == nullptr)) {
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
return;
|
|
|
|
|
}
|
2019-08-23 09:52:12 +02:00
|
|
|
ID *orig_id = ptr->owner_id;
|
2018-05-19 19:26:19 +02:00
|
|
|
ID *cow_id = DEG_get_evaluated_id(depsgraph, orig_id);
|
2019-08-23 09:52:12 +02:00
|
|
|
if (ptr->owner_id == ptr->data) {
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
/* For ID pointers, it's easy... */
|
2019-08-23 09:52:12 +02:00
|
|
|
r_ptr_eval->owner_id = cow_id;
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
r_ptr_eval->data = (void *)cow_id;
|
|
|
|
|
r_ptr_eval->type = ptr->type;
|
|
|
|
|
}
|
2018-05-19 19:42:36 +02:00
|
|
|
else if (ptr->type == &RNA_PoseBone) {
|
|
|
|
|
/* HACK: Since bone keyframing is quite commonly used,
|
|
|
|
|
* speed things up for this case by doing a special lookup
|
2019-01-31 12:56:40 +01:00
|
|
|
* for bones */
|
2018-05-19 19:42:36 +02:00
|
|
|
const Object *ob_eval = (Object *)cow_id;
|
|
|
|
|
bPoseChannel *pchan = (bPoseChannel *)ptr->data;
|
|
|
|
|
const bPoseChannel *pchan_eval = BKE_pose_channel_find_name(ob_eval->pose, pchan->name);
|
2019-08-23 09:52:12 +02:00
|
|
|
r_ptr_eval->owner_id = cow_id;
|
2018-05-19 19:42:36 +02:00
|
|
|
r_ptr_eval->data = (void *)pchan_eval;
|
|
|
|
|
r_ptr_eval->type = ptr->type;
|
|
|
|
|
}
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
else {
|
2018-05-19 19:12:26 +02:00
|
|
|
/* For everything else, try to get RNA Path of the BMain-pointer,
|
|
|
|
|
* then use that to look up what the COW-domain one should be
|
2019-01-31 12:56:40 +01:00
|
|
|
* given the COW ID pointer as the new lookup point */
|
2018-05-19 19:42:36 +02:00
|
|
|
/* TODO: Find a faster alternative, or implement support for other
|
2019-01-31 12:56:40 +01:00
|
|
|
* common types too above (e.g. modifiers) */
|
2018-05-19 19:12:26 +02:00
|
|
|
char *path = RNA_path_from_ID_to_struct(ptr);
|
|
|
|
|
if (path) {
|
|
|
|
|
PointerRNA cow_id_ptr;
|
|
|
|
|
RNA_id_pointer_create(cow_id, &cow_id_ptr);
|
2020-01-28 14:50:13 +01:00
|
|
|
if (!RNA_path_resolve(&cow_id_ptr, path, r_ptr_eval, nullptr)) {
|
2018-05-19 19:26:19 +02:00
|
|
|
/* Couldn't find COW copy of data */
|
|
|
|
|
fprintf(stderr,
|
|
|
|
|
"%s: Couldn't resolve RNA path ('%s') relative to COW ID (%p) for '%s'\n",
|
|
|
|
|
__func__,
|
|
|
|
|
path,
|
|
|
|
|
(void *)cow_id,
|
|
|
|
|
orig_id->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2018-05-19 19:12:26 +02:00
|
|
|
}
|
2018-05-19 19:26:19 +02:00
|
|
|
else {
|
|
|
|
|
/* Path resolution failed - XXX: Hide this behind a debug flag */
|
|
|
|
|
fprintf(stderr,
|
|
|
|
|
"%s: Couldn't get RNA path for %s relative to %s\n",
|
|
|
|
|
__func__,
|
|
|
|
|
RNA_struct_identifier(ptr->type),
|
|
|
|
|
orig_id->name);
|
|
|
|
|
}
|
WIP COW Fix: Insert keyframe operators/api now queries depsgraph for evaluated data
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
2018-05-18 20:36:48 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-20 11:01:43 +02:00
|
|
|
Object *DEG_get_original_object(Object *object)
|
|
|
|
|
{
|
|
|
|
|
return (Object *)DEG_get_original_id(&object->id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ID *DEG_get_original_id(ID *id)
|
|
|
|
|
{
|
2020-01-28 14:50:13 +01:00
|
|
|
if (id == nullptr) {
|
|
|
|
|
return nullptr;
|
2018-04-20 11:01:43 +02:00
|
|
|
}
|
2020-01-28 14:50:13 +01:00
|
|
|
if (id->orig_id == nullptr) {
|
2018-04-20 11:01:43 +02:00
|
|
|
return id;
|
|
|
|
|
}
|
2018-06-04 15:11:09 +02:00
|
|
|
BLI_assert((id->tag & LIB_TAG_COPIED_ON_WRITE) != 0);
|
2018-04-20 11:01:43 +02:00
|
|
|
return (ID *)id->orig_id;
|
|
|
|
|
}
|
2019-05-09 15:50:46 +02:00
|
|
|
|
2020-04-29 12:36:33 +10:00
|
|
|
bool DEG_is_original_id(const ID *id)
|
2019-05-09 15:50:46 +02:00
|
|
|
{
|
|
|
|
|
/* Some explanation of the logic.
|
|
|
|
|
*
|
|
|
|
|
* What we want here is to be able to tell whether given ID is a result of dependency graph
|
|
|
|
|
* evaluation or not.
|
|
|
|
|
*
|
2019-06-12 09:04:10 +10:00
|
|
|
* All the data-blocks which are created by copy-on-write mechanism will have will be tagged with
|
|
|
|
|
* LIB_TAG_COPIED_ON_WRITE tag. Those data-blocks can not be original.
|
2019-05-09 15:50:46 +02:00
|
|
|
*
|
2019-06-12 09:04:10 +10:00
|
|
|
* Modifier stack evaluation might create special data-blocks which have all the modifiers
|
|
|
|
|
* applied, and those will be tagged with LIB_TAG_COPIED_ON_WRITE_EVAL_RESULT. Such data-blocks
|
2019-05-09 15:50:46 +02:00
|
|
|
* can not be original as well.
|
|
|
|
|
*
|
2019-06-12 09:04:10 +10:00
|
|
|
* Localization is usually happening from evaluated data-block, or will have some special pointer
|
2019-05-09 15:50:46 +02:00
|
|
|
* magic which will make them to act as evaluated.
|
|
|
|
|
*
|
2019-07-07 15:38:41 +10:00
|
|
|
* NOTE: We consider ID evaluated if ANY of those flags is set. We do NOT require ALL of them. */
|
2019-05-09 15:50:46 +02:00
|
|
|
if (id->tag &
|
|
|
|
|
(LIB_TAG_COPIED_ON_WRITE | LIB_TAG_COPIED_ON_WRITE_EVAL_RESULT | LIB_TAG_LOCALIZED)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-29 12:36:33 +10:00
|
|
|
bool DEG_is_original_object(const Object *object)
|
2019-05-09 15:50:46 +02:00
|
|
|
{
|
|
|
|
|
return DEG_is_original_id(&object->id);
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-29 12:36:33 +10:00
|
|
|
bool DEG_is_evaluated_id(const ID *id)
|
2019-05-09 15:50:46 +02:00
|
|
|
{
|
|
|
|
|
return !DEG_is_original_id(id);
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-29 12:36:33 +10:00
|
|
|
bool DEG_is_evaluated_object(const Object *object)
|
2019-05-09 15:50:46 +02:00
|
|
|
{
|
|
|
|
|
return !DEG_is_original_object(object);
|
|
|
|
|
}
|
2019-05-28 15:42:08 +02:00
|
|
|
|
|
|
|
|
bool DEG_is_fully_evaluated(const struct Depsgraph *depsgraph)
|
|
|
|
|
{
|
2020-06-29 15:19:56 +02:00
|
|
|
const deg::Depsgraph *deg_graph = (const deg::Depsgraph *)depsgraph;
|
2019-05-28 15:42:08 +02:00
|
|
|
/* Check whether relations are up to date. */
|
|
|
|
|
if (deg_graph->need_update) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
/* Check whether IDs are up to date. */
|
2020-04-28 17:40:23 +02:00
|
|
|
if (!deg_graph->entry_tags.is_empty()) {
|
2019-05-28 15:42:08 +02:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|