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
|
|
|
*
|
|
|
|
|
* Methods for constructing depsgraph
|
|
|
|
|
*/
|
|
|
|
|
|
Depsgraph: Cleanup and code simplification
This is mainly a maintenance commit which was aimed to make work with
this module more pleasant and solve such issues as:
- Annoyance with looong files, which had craftload in them
- Usage of STL for the data structures we've got in BLI
- Possible symbol conflicts
- Not real clear layout of what is located where
So in this commit the following changes are done:
- STL is prohibited, it's not really predictable on various compilers,
with our BLI algorithms we can predict things much better.
There are still few usages of std::vector, but that we'll be
solving later once we've got similar thing in BLI.
- Simplify foreach loops, avoid using const_iterator all over the place.
- New directory layout, which is hopefully easier to follow.
- Some files were split, some of them will be split soon.
The idea of this is to split huge functions into own files with
good documentation and everything.
- Removed stuff which was planned for use in the future but was never
finished, tested or anything.
Let's wipe it out for now, and bring back once we really start using
it, so it'll be more clear if it solves our needs.
- All the internal routines were moved to DEG namespace to separate
them better from rest of blender.
Some places now annoyingly using DEG::foo, but that we can olve by
moving some utility functions inside of the namespace.
While working on this we've found some hotspot in updates flush, so
now playback of blenrig is few percent faster (something like 96fps
with previous master and around 99-100fps after this change).
Not saying it's something final, there is still room for cleanup and
API simplification, but those might happen as a regular development
now without doing any global changes.
2016-05-27 18:01:18 +02:00
|
|
|
#include "intern/builder/deg_builder_relations.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 <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
2016-11-07 12:09:42 +01:00
|
|
|
#include <cstring> /* required for STREQ later on. */
|
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"
|
|
|
|
|
|
|
|
|
|
#include "BLI_utildefines.h"
|
2017-06-06 12:14:39 +02:00
|
|
|
#include "BLI_blenlib.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
|
|
|
|
2017-06-06 12:14:39 +02:00
|
|
|
extern "C" {
|
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 "DNA_action_types.h"
|
|
|
|
|
#include "DNA_anim_types.h"
|
|
|
|
|
#include "DNA_armature_types.h"
|
|
|
|
|
#include "DNA_camera_types.h"
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
#include "DNA_cachefile_types.h"
|
2018-08-29 15:32:50 +02:00
|
|
|
#include "DNA_collection_types.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 "DNA_constraint_types.h"
|
|
|
|
|
#include "DNA_curve_types.h"
|
|
|
|
|
#include "DNA_effect_types.h"
|
|
|
|
|
#include "DNA_gpencil_types.h"
|
|
|
|
|
#include "DNA_key_types.h"
|
2019-02-27 12:34:56 +11:00
|
|
|
#include "DNA_light_types.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 "DNA_material_types.h"
|
2016-11-17 15:29:22 +01:00
|
|
|
#include "DNA_mask_types.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 "DNA_mesh_types.h"
|
|
|
|
|
#include "DNA_meta_types.h"
|
2016-11-17 16:37:25 +01:00
|
|
|
#include "DNA_movieclip_types.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 "DNA_node_types.h"
|
|
|
|
|
#include "DNA_particle_types.h"
|
2017-06-12 20:59:54 +10:00
|
|
|
#include "DNA_lightprobe_types.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 "DNA_object_types.h"
|
|
|
|
|
#include "DNA_rigidbody_types.h"
|
|
|
|
|
#include "DNA_scene_types.h"
|
2018-06-25 11:53:38 +02:00
|
|
|
#include "DNA_speaker_types.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 "DNA_texture_types.h"
|
|
|
|
|
#include "DNA_world_types.h"
|
2018-02-07 11:14:08 +11:00
|
|
|
#include "DNA_object_force_types.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_action.h"
|
|
|
|
|
#include "BKE_armature.h"
|
|
|
|
|
#include "BKE_animsys.h"
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
#include "BKE_collection.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_constraint.h"
|
|
|
|
|
#include "BKE_curve.h"
|
|
|
|
|
#include "BKE_effect.h"
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
|
|
|
#include "BKE_collision.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_fcurve.h"
|
2019-02-18 13:23:49 +01:00
|
|
|
#include "BKE_image.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_key.h"
|
|
|
|
|
#include "BKE_material.h"
|
|
|
|
|
#include "BKE_mball.h"
|
|
|
|
|
#include "BKE_modifier.h"
|
2018-07-31 10:22:19 +02:00
|
|
|
#include "BKE_gpencil_modifier.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_node.h"
|
|
|
|
|
#include "BKE_object.h"
|
|
|
|
|
#include "BKE_particle.h"
|
2018-11-14 11:24:54 +01:00
|
|
|
#include "BKE_pointcache.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_rigidbody.h"
|
2018-07-31 10:22:19 +02:00
|
|
|
#include "BKE_shader_fx.h"
|
2018-10-03 19:09:43 +03:00
|
|
|
#include "BKE_shrinkwrap.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_sound.h"
|
|
|
|
|
#include "BKE_tracking.h"
|
|
|
|
|
#include "BKE_world.h"
|
|
|
|
|
|
|
|
|
|
#include "RNA_access.h"
|
|
|
|
|
#include "RNA_types.h"
|
|
|
|
|
} /* extern "C" */
|
|
|
|
|
|
2017-06-06 12:14:39 +02:00
|
|
|
#include "DEG_depsgraph.h"
|
|
|
|
|
#include "DEG_depsgraph_build.h"
|
|
|
|
|
|
Depsgraph: Cleanup and code simplification
This is mainly a maintenance commit which was aimed to make work with
this module more pleasant and solve such issues as:
- Annoyance with looong files, which had craftload in them
- Usage of STL for the data structures we've got in BLI
- Possible symbol conflicts
- Not real clear layout of what is located where
So in this commit the following changes are done:
- STL is prohibited, it's not really predictable on various compilers,
with our BLI algorithms we can predict things much better.
There are still few usages of std::vector, but that we'll be
solving later once we've got similar thing in BLI.
- Simplify foreach loops, avoid using const_iterator all over the place.
- New directory layout, which is hopefully easier to follow.
- Some files were split, some of them will be split soon.
The idea of this is to split huge functions into own files with
good documentation and everything.
- Removed stuff which was planned for use in the future but was never
finished, tested or anything.
Let's wipe it out for now, and bring back once we really start using
it, so it'll be more clear if it solves our needs.
- All the internal routines were moved to DEG namespace to separate
them better from rest of blender.
Some places now annoyingly using DEG::foo, but that we can olve by
moving some utility functions inside of the namespace.
While working on this we've found some hotspot in updates flush, so
now playback of blenrig is few percent faster (something like 96fps
with previous master and around 99-100fps after this change).
Not saying it's something final, there is still room for cleanup and
API simplification, but those might happen as a regular development
now without doing any global changes.
2016-05-27 18:01:18 +02:00
|
|
|
#include "intern/builder/deg_builder.h"
|
|
|
|
|
#include "intern/builder/deg_builder_pchanmap.h"
|
2019-01-31 12:56:40 +01:00
|
|
|
#include "intern/debug/deg_debug.h"
|
|
|
|
|
#include "intern/depsgraph_tag.h"
|
|
|
|
|
#include "intern/depsgraph_physics.h"
|
2018-11-19 12:04:02 +01:00
|
|
|
#include "intern/eval/deg_eval_copy_on_write.h"
|
Depsgraph: Cleanup and code simplification
This is mainly a maintenance commit which was aimed to make work with
this module more pleasant and solve such issues as:
- Annoyance with looong files, which had craftload in them
- Usage of STL for the data structures we've got in BLI
- Possible symbol conflicts
- Not real clear layout of what is located where
So in this commit the following changes are done:
- STL is prohibited, it's not really predictable on various compilers,
with our BLI algorithms we can predict things much better.
There are still few usages of std::vector, but that we'll be
solving later once we've got similar thing in BLI.
- Simplify foreach loops, avoid using const_iterator all over the place.
- New directory layout, which is hopefully easier to follow.
- Some files were split, some of them will be split soon.
The idea of this is to split huge functions into own files with
good documentation and everything.
- Removed stuff which was planned for use in the future but was never
finished, tested or anything.
Let's wipe it out for now, and bring back once we really start using
it, so it'll be more clear if it solves our needs.
- All the internal routines were moved to DEG namespace to separate
them better from rest of blender.
Some places now annoyingly using DEG::foo, but that we can olve by
moving some utility functions inside of the namespace.
While working on this we've found some hotspot in updates flush, so
now playback of blenrig is few percent faster (something like 96fps
with previous master and around 99-100fps after this change).
Not saying it's something final, there is still room for cleanup and
API simplification, but those might happen as a regular development
now without doing any global changes.
2016-05-27 18:01:18 +02:00
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
#include "intern/node/deg_node.h"
|
|
|
|
|
#include "intern/node/deg_node_component.h"
|
|
|
|
|
#include "intern/node/deg_node_id.h"
|
|
|
|
|
#include "intern/node/deg_node_operation.h"
|
|
|
|
|
#include "intern/node/deg_node_time.h"
|
Depsgraph: Cleanup and code simplification
This is mainly a maintenance commit which was aimed to make work with
this module more pleasant and solve such issues as:
- Annoyance with looong files, which had craftload in them
- Usage of STL for the data structures we've got in BLI
- Possible symbol conflicts
- Not real clear layout of what is located where
So in this commit the following changes are done:
- STL is prohibited, it's not really predictable on various compilers,
with our BLI algorithms we can predict things much better.
There are still few usages of std::vector, but that we'll be
solving later once we've got similar thing in BLI.
- Simplify foreach loops, avoid using const_iterator all over the place.
- New directory layout, which is hopefully easier to follow.
- Some files were split, some of them will be split soon.
The idea of this is to split huge functions into own files with
good documentation and everything.
- Removed stuff which was planned for use in the future but was never
finished, tested or anything.
Let's wipe it out for now, and bring back once we really start using
it, so it'll be more clear if it solves our needs.
- All the internal routines were moved to DEG namespace to separate
them better from rest of blender.
Some places now annoyingly using DEG::foo, but that we can olve by
moving some utility functions inside of the namespace.
While working on this we've found some hotspot in updates flush, so
now playback of blenrig is few percent faster (something like 96fps
with previous master and around 99-100fps after this change).
Not saying it's something final, there is still room for cleanup and
API simplification, but those might happen as a regular development
now without doing any global changes.
2016-05-27 18:01:18 +02:00
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
#include "intern/depsgraph_type.h"
|
Depsgraph: Cleanup and code simplification
This is mainly a maintenance commit which was aimed to make work with
this module more pleasant and solve such issues as:
- Annoyance with looong files, which had craftload in them
- Usage of STL for the data structures we've got in BLI
- Possible symbol conflicts
- Not real clear layout of what is located where
So in this commit the following changes are done:
- STL is prohibited, it's not really predictable on various compilers,
with our BLI algorithms we can predict things much better.
There are still few usages of std::vector, but that we'll be
solving later once we've got similar thing in BLI.
- Simplify foreach loops, avoid using const_iterator all over the place.
- New directory layout, which is hopefully easier to follow.
- Some files were split, some of them will be split soon.
The idea of this is to split huge functions into own files with
good documentation and everything.
- Removed stuff which was planned for use in the future but was never
finished, tested or anything.
Let's wipe it out for now, and bring back once we really start using
it, so it'll be more clear if it solves our needs.
- All the internal routines were moved to DEG namespace to separate
them better from rest of blender.
Some places now annoyingly using DEG::foo, but that we can olve by
moving some utility functions inside of the namespace.
While working on this we've found some hotspot in updates flush, so
now playback of blenrig is few percent faster (something like 96fps
with previous master and around 99-100fps after this change).
Not saying it's something final, there is still room for cleanup and
API simplification, but those might happen as a regular development
now without doing any global changes.
2016-05-27 18:01:18 +02:00
|
|
|
|
|
|
|
|
namespace DEG {
|
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
|
|
|
|
|
|
|
|
/* ***************** */
|
|
|
|
|
/* Relations Builder */
|
|
|
|
|
|
2016-09-15 12:12:59 +02:00
|
|
|
/* TODO(sergey): This is somewhat weak, but we don't want neither false-positive
|
|
|
|
|
* time dependencies nor special exceptions in the depsgraph evaluation.
|
|
|
|
|
*/
|
|
|
|
|
static bool python_driver_depends_on_time(ChannelDriver *driver)
|
|
|
|
|
{
|
|
|
|
|
if (driver->expression[0] == '\0') {
|
|
|
|
|
/* Empty expression depends on nothing. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
if (strchr(driver->expression, '(') != NULL) {
|
|
|
|
|
/* Function calls are considered dependent on a time. */
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2017-01-31 12:17:42 +01:00
|
|
|
if (strstr(driver->expression, "frame") != NULL) {
|
|
|
|
|
/* Variable `frame` depends on time. */
|
2016-09-15 12:12:59 +02:00
|
|
|
/* TODO(sergey): This is a bit weak, but not sure about better way of
|
2019-01-31 12:56:40 +01:00
|
|
|
* handling this. */
|
2016-09-15 12:12:59 +02:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
/* Possible indirect time relation s should be handled via variable
|
2019-01-31 12:56:40 +01:00
|
|
|
* targets. */
|
2016-09-15 12:12:59 +02:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-17 14:56:51 +01:00
|
|
|
static bool particle_system_depends_on_time(ParticleSystem *psys)
|
|
|
|
|
{
|
|
|
|
|
ParticleSettings *part = psys->part;
|
|
|
|
|
/* Non-hair particles we always consider dependent on time. */
|
|
|
|
|
if (part->type != PART_HAIR) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
/* Dynamics always depends on time. */
|
|
|
|
|
if (psys->flag & PSYS_HAIR_DYNAMICS) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
/* TODO(sergey): Check what else makes hair dependent on time. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-17 15:27:02 +01:00
|
|
|
static bool object_particles_depends_on_time(Object *object)
|
2017-11-17 14:56:51 +01:00
|
|
|
{
|
2018-06-06 11:22:20 +02:00
|
|
|
if (object->type != OB_MESH) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (ParticleSystem *, psys, &object->particlesystem) {
|
2017-11-17 14:56:51 +01:00
|
|
|
if (particle_system_depends_on_time(psys)) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-03 12:41:03 +02:00
|
|
|
static bool check_id_has_anim_component(ID *id)
|
|
|
|
|
{
|
|
|
|
|
AnimData *adt = BKE_animdata_from_id(id);
|
|
|
|
|
if (adt == NULL) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return (adt->action != NULL) ||
|
|
|
|
|
(!BLI_listbase_is_empty(&adt->nla_tracks));
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
static OperationCode bone_target_opcode(ID *target,
|
2019-02-15 12:45:56 +01:00
|
|
|
const char *subtarget,
|
|
|
|
|
ID *id,
|
|
|
|
|
const char *component_subdata,
|
|
|
|
|
RootPChanMap *root_map)
|
2018-08-09 17:17:40 +03:00
|
|
|
{
|
2018-11-14 11:24:54 +01:00
|
|
|
/* Same armature. */
|
2018-08-09 17:17:40 +03:00
|
|
|
if (target == id) {
|
|
|
|
|
/* Using "done" here breaks in-chain deps, while using
|
|
|
|
|
* "ready" here breaks most production rigs instead.
|
|
|
|
|
* So, we do a compromise here, and only do this when an
|
2019-01-31 12:56:40 +01:00
|
|
|
* IK chain conflict may occur. */
|
2018-08-09 17:17:40 +03:00
|
|
|
if (root_map->has_common_root(component_subdata, subtarget)) {
|
2019-01-31 12:56:40 +01:00
|
|
|
return OperationCode::BONE_READY;
|
2018-08-09 17:17:40 +03:00
|
|
|
}
|
|
|
|
|
}
|
2019-01-31 12:56:40 +01:00
|
|
|
return OperationCode::BONE_DONE;
|
2018-08-09 17:17:40 +03:00
|
|
|
}
|
|
|
|
|
|
2018-11-22 13:38:03 +03:00
|
|
|
static bool bone_has_segments(Object *object, const char *bone_name)
|
|
|
|
|
{
|
|
|
|
|
/* Proxies don't have BONE_SEGMENTS */
|
|
|
|
|
if (ID_IS_LINKED(object) && object->proxy_from != NULL) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
/* Only B-Bones have segments. */
|
|
|
|
|
bPoseChannel *pchan = BKE_pose_channel_find_name(object->pose, bone_name);
|
|
|
|
|
return pchan && pchan->bone && pchan->bone->segments > 1;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* **** General purpose functions **** */
|
|
|
|
|
|
2017-11-08 17:43:53 +01:00
|
|
|
DepsgraphRelationBuilder::DepsgraphRelationBuilder(Main *bmain,
|
|
|
|
|
Depsgraph *graph)
|
2019-02-27 11:17:36 +01:00
|
|
|
: DepsgraphBuilder(bmain, graph),
|
2019-02-15 12:45:56 +01:00
|
|
|
scene_(NULL),
|
|
|
|
|
rna_node_query_(graph)
|
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-01-31 12:56:40 +01:00
|
|
|
TimeSourceNode *DepsgraphRelationBuilder::get_node(
|
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
|
|
|
const TimeSourceKey &key) const
|
|
|
|
|
{
|
|
|
|
|
if (key.id) {
|
|
|
|
|
/* XXX TODO */
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
else {
|
2017-11-08 17:38:42 +01:00
|
|
|
return graph_->time_source;
|
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-01-31 12:56:40 +01:00
|
|
|
ComponentNode *DepsgraphRelationBuilder::get_node(
|
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
|
|
|
const ComponentKey &key) const
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
IDNode *id_node = graph_->find_id_node(key.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
|
|
|
if (!id_node) {
|
|
|
|
|
fprintf(stderr, "find_node component: Could not find ID %s\n",
|
|
|
|
|
(key.id != NULL) ? key.id->name : "<null>");
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentNode *node = id_node->find_component(key.type, key.name);
|
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 node;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationNode *DepsgraphRelationBuilder::get_node(
|
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
|
|
|
const OperationKey &key) const
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationNode *op_node = find_node(key);
|
2017-11-24 15:35:42 +01:00
|
|
|
if (op_node == NULL) {
|
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
|
|
|
fprintf(stderr, "find_node_operation: Failed for (%s, '%s')\n",
|
2018-04-30 17:20:42 +02:00
|
|
|
operationCodeAsString(key.opcode), key.name);
|
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 op_node;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-15 12:45:56 +01:00
|
|
|
Node *DepsgraphRelationBuilder::get_node(const RNAPathKey &key)
|
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-02-15 12:45:56 +01:00
|
|
|
return rna_node_query_.find_node(&key.ptr, key.prop, key.source);
|
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-01-31 12:56:40 +01:00
|
|
|
OperationNode *DepsgraphRelationBuilder::find_node(
|
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
|
|
|
const OperationKey &key) const
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
IDNode *id_node = graph_->find_id_node(key.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
|
|
|
if (!id_node) {
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentNode *comp_node = id_node->find_component(key.component_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
|
|
|
key.component_name);
|
|
|
|
|
if (!comp_node) {
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2017-11-24 15:26:54 +01:00
|
|
|
return comp_node->find_operation(key.opcode, key.name, key.name_tag);
|
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
|
|
|
}
|
|
|
|
|
|
2017-11-24 15:34:53 +01:00
|
|
|
bool DepsgraphRelationBuilder::has_node(const OperationKey &key) const
|
|
|
|
|
{
|
|
|
|
|
return find_node(key) != NULL;
|
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-02-12 12:01:17 +01:00
|
|
|
void DepsgraphRelationBuilder::add_modifier_to_transform_relation(
|
|
|
|
|
const DepsNodeHandle *handle,
|
|
|
|
|
const char *description)
|
|
|
|
|
{
|
|
|
|
|
/* Geometry operation, this is where relation will be wired to. */
|
|
|
|
|
OperationNode *geometry_operation_node =
|
|
|
|
|
handle->node->get_entry_operation();
|
2019-02-12 12:32:03 +01:00
|
|
|
ComponentNode *geometry_component = geometry_operation_node->owner;
|
|
|
|
|
BLI_assert(geometry_component->type == NodeType::GEOMETRY);
|
|
|
|
|
IDNode *id_node = geometry_component->owner;
|
2019-02-12 12:01:17 +01:00
|
|
|
/* Transform operation, the source of the relation. */
|
2019-02-12 12:32:03 +01:00
|
|
|
ComponentNode *transform_component =
|
|
|
|
|
id_node->find_component(NodeType::TRANSFORM);
|
2019-02-12 12:01:17 +01:00
|
|
|
ID *id = geometry_operation_node->owner->owner->id_orig;
|
2019-02-12 12:32:03 +01:00
|
|
|
BLI_assert(GS(id->name) == ID_OB);
|
|
|
|
|
Object *object = reinterpret_cast<Object *>(id);
|
|
|
|
|
OperationNode *transform_operation_node = NULL;
|
|
|
|
|
if (object->rigidbody_object == NULL) {
|
|
|
|
|
transform_operation_node = transform_component->get_exit_operation();
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
transform_operation_node = transform_component->get_operation(
|
|
|
|
|
OperationCode::TRANSFORM_EVAL);
|
|
|
|
|
}
|
2019-02-12 12:01:17 +01:00
|
|
|
/* Wire up the actual relation. */
|
|
|
|
|
add_operation_relation(
|
|
|
|
|
transform_operation_node, geometry_operation_node, description);
|
|
|
|
|
}
|
|
|
|
|
|
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 DepsgraphRelationBuilder::add_customdata_mask(
|
|
|
|
|
Object *object,
|
|
|
|
|
const DEGCustomDataMeshMasks &customdata_masks)
|
2018-10-14 19:59:27 +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
|
|
|
if (customdata_masks != DEGCustomDataMeshMasks() && object != NULL && object->type == OB_MESH) {
|
2019-01-31 12:56:40 +01:00
|
|
|
DEG::IDNode *id_node = graph_->find_id_node(&object->id);
|
2018-10-14 19:59:27 +03:00
|
|
|
|
2018-12-03 18:09:45 +03:00
|
|
|
if (id_node == NULL) {
|
|
|
|
|
BLI_assert(!"ID should always be valid");
|
|
|
|
|
}
|
|
|
|
|
else {
|
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
|
|
|
id_node->customdata_masks |= customdata_masks;
|
2018-10-14 19:59:27 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-24 19:38:50 +03:00
|
|
|
void DepsgraphRelationBuilder::add_special_eval_flag(ID *id, uint32_t flag)
|
2018-10-24 12:31:24 +03:00
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
DEG::IDNode *id_node = graph_->find_id_node(id);
|
2018-10-24 12:31:24 +03:00
|
|
|
if (id_node == NULL) {
|
|
|
|
|
BLI_assert(!"ID should always be valid");
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
id_node->eval_flags |= flag;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
Relation *DepsgraphRelationBuilder::add_time_relation(
|
|
|
|
|
TimeSourceNode *timesrc,
|
|
|
|
|
Node *node_to,
|
2018-04-23 16:42:37 +02:00
|
|
|
const char *description,
|
2018-11-22 14:54:08 +01:00
|
|
|
int flags)
|
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
|
|
|
{
|
|
|
|
|
if (timesrc && node_to) {
|
2018-11-22 14:54:08 +01:00
|
|
|
return graph_->add_new_relation(
|
2019-01-31 12:56:40 +01:00
|
|
|
timesrc, node_to, description, flags);
|
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
|
|
|
}
|
|
|
|
|
else {
|
2018-05-02 11:52:49 +02:00
|
|
|
DEG_DEBUG_PRINTF((::Depsgraph *)graph_,
|
|
|
|
|
BUILD, "add_time_relation(%p = %s, %p = %s, %s) Failed\n",
|
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
|
|
|
timesrc, (timesrc) ? timesrc->identifier().c_str() : "<None>",
|
|
|
|
|
node_to, (node_to) ? node_to->identifier().c_str() : "<None>",
|
|
|
|
|
description);
|
|
|
|
|
}
|
2018-04-23 16:42:37 +02:00
|
|
|
return NULL;
|
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-01-31 12:56:40 +01:00
|
|
|
Relation *DepsgraphRelationBuilder::add_operation_relation(
|
|
|
|
|
OperationNode *node_from,
|
|
|
|
|
OperationNode *node_to,
|
2017-12-05 12:52:17 +01:00
|
|
|
const char *description,
|
2018-11-22 14:54:08 +01:00
|
|
|
int flags)
|
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
|
|
|
{
|
|
|
|
|
if (node_from && node_to) {
|
2018-04-23 16:42:37 +02:00
|
|
|
return graph_->add_new_relation(node_from,
|
|
|
|
|
node_to,
|
|
|
|
|
description,
|
2018-11-22 14:54:08 +01:00
|
|
|
flags);
|
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
|
|
|
}
|
|
|
|
|
else {
|
2018-05-02 11:52:49 +02:00
|
|
|
DEG_DEBUG_PRINTF((::Depsgraph *)graph_,
|
|
|
|
|
BUILD, "add_operation_relation(%p = %s, %p = %s, %s) Failed\n",
|
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
|
|
|
node_from, (node_from) ? node_from->identifier().c_str() : "<None>",
|
|
|
|
|
node_to, (node_to) ? node_to->identifier().c_str() : "<None>",
|
2017-06-01 14:49:17 +02:00
|
|
|
description);
|
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-04-23 16:42:37 +02:00
|
|
|
return NULL;
|
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-01-22 15:17:34 +01:00
|
|
|
void DepsgraphRelationBuilder::add_particle_collision_relations(
|
2017-12-05 13:02:36 +01:00
|
|
|
const OperationKey &key,
|
|
|
|
|
Object *object,
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
Collection *collection,
|
2017-12-05 13:02:36 +01:00
|
|
|
const char *name)
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
ListBase *relations = build_collision_relations(graph_, collection, eModifierType_Collision);
|
2018-06-22 14:42:03 +02:00
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (CollisionRelation *, relation, relations) {
|
|
|
|
|
if (relation->ob != object) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey trf_key(&relation->ob->id, NodeType::TRANSFORM);
|
2018-06-22 14:42:03 +02:00
|
|
|
add_relation(trf_key, key, name);
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey coll_key(&relation->ob->id, NodeType::GEOMETRY);
|
2018-06-22 14:42:03 +02:00
|
|
|
add_relation(coll_key, key, name);
|
|
|
|
|
}
|
2017-12-05 13:02:36 +01:00
|
|
|
}
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
|
|
|
}
|
|
|
|
|
|
2019-01-22 15:17:34 +01:00
|
|
|
void DepsgraphRelationBuilder::add_particle_forcefield_relations(
|
2017-12-05 13:02:36 +01:00
|
|
|
const OperationKey &key,
|
|
|
|
|
Object *object,
|
|
|
|
|
ParticleSystem *psys,
|
|
|
|
|
EffectorWeights *eff,
|
|
|
|
|
bool add_absorption,
|
|
|
|
|
const char *name)
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
ListBase *relations = build_effector_relations(graph_, eff->group);
|
2018-06-21 19:45:39 +02:00
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (EffectorRelation *, relation, relations) {
|
|
|
|
|
if (relation->ob != object) {
|
2019-01-22 15:17:34 +01:00
|
|
|
/* Relation to forcefield object, optionally including geometry. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey eff_key(&relation->ob->id, NodeType::TRANSFORM);
|
2018-06-18 09:52:58 +02:00
|
|
|
add_relation(eff_key, key, name);
|
2018-06-21 19:45:39 +02:00
|
|
|
|
2019-01-11 13:13:55 +01:00
|
|
|
if (ELEM(relation->pd->shape, PFIELD_SHAPE_SURFACE, PFIELD_SHAPE_POINTS) ||
|
2019-01-24 09:27:14 +11:00
|
|
|
relation->pd->forcefield == PFIELD_GUIDE)
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey mod_key(&relation->ob->id, NodeType::GEOMETRY);
|
2019-01-22 15:17:34 +01:00
|
|
|
add_relation(mod_key, key, name);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Smoke flow relations. */
|
2018-06-21 19:45:39 +02:00
|
|
|
if (relation->pd->forcefield == PFIELD_SMOKEFLOW && relation->pd->f_source) {
|
|
|
|
|
ComponentKey trf_key(&relation->pd->f_source->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2018-06-21 19:45:39 +02:00
|
|
|
add_relation(trf_key, key, "Smoke Force Domain");
|
|
|
|
|
ComponentKey eff_key(&relation->pd->f_source->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY);
|
2018-06-21 19:45:39 +02:00
|
|
|
add_relation(eff_key, key, "Smoke Force Domain");
|
|
|
|
|
}
|
2019-01-22 15:17:34 +01:00
|
|
|
|
|
|
|
|
/* Absorption forces need collision relation. */
|
2018-06-21 19:45:39 +02:00
|
|
|
if (add_absorption && (relation->pd->flag & PFIELD_VISIBILITY)) {
|
2019-01-22 15:17:34 +01:00
|
|
|
add_particle_collision_relations(key,
|
|
|
|
|
object,
|
|
|
|
|
NULL,
|
|
|
|
|
"Force Absorption");
|
2018-06-21 19:45:39 +02:00
|
|
|
}
|
2018-06-18 09:52:58 +02:00
|
|
|
}
|
2019-01-22 15:17:34 +01:00
|
|
|
|
2018-06-21 19:45:39 +02:00
|
|
|
if (relation->psys) {
|
|
|
|
|
if (relation->ob != object) {
|
2018-12-10 15:09:46 +01:00
|
|
|
ComponentKey eff_key(&relation->ob->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SYSTEM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(eff_key, key, name);
|
2018-06-18 09:52:58 +02:00
|
|
|
/* TODO: remove this when/if EVAL_PARTICLES is sufficient
|
2019-01-31 12:56:40 +01:00
|
|
|
* for up to date particles. */
|
|
|
|
|
ComponentKey mod_key(&relation->ob->id, NodeType::GEOMETRY);
|
2018-06-18 09:52:58 +02:00
|
|
|
add_relation(mod_key, key, name);
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
|
|
|
}
|
2018-06-21 19:45:39 +02:00
|
|
|
else if (relation->psys != psys) {
|
|
|
|
|
OperationKey eff_key(&relation->ob->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SYSTEM,
|
|
|
|
|
OperationCode::PARTICLE_SYSTEM_EVAL,
|
2018-06-21 19:45:39 +02:00
|
|
|
relation->psys->name);
|
2018-06-18 09:52:58 +02:00
|
|
|
add_relation(eff_key, key, name);
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-12 14:41:46 +02:00
|
|
|
Depsgraph *DepsgraphRelationBuilder::getGraph()
|
|
|
|
|
{
|
2017-11-08 17:38:42 +01:00
|
|
|
return graph_;
|
2017-06-12 14:41:46 +02:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* **** Functions to build relations between entities **** */
|
|
|
|
|
|
2017-11-08 17:43:53 +01:00
|
|
|
void DepsgraphRelationBuilder::begin_build()
|
2017-01-25 12:28:27 +01:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-11 07:55:41 +02:00
|
|
|
void DepsgraphRelationBuilder::build_id(ID *id)
|
|
|
|
|
{
|
2018-05-04 14:27:50 +02:00
|
|
|
if (id == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
switch (GS(id->name)) {
|
2018-11-15 12:47:58 +01:00
|
|
|
case ID_AC:
|
|
|
|
|
build_action((bAction *)id);
|
|
|
|
|
break;
|
2018-06-06 12:01:38 +02:00
|
|
|
case ID_AR:
|
|
|
|
|
build_armature((bArmature *)id);
|
|
|
|
|
break;
|
|
|
|
|
case ID_CA:
|
|
|
|
|
build_camera((Camera *)id);
|
|
|
|
|
break;
|
2018-05-04 14:27:50 +02:00
|
|
|
case ID_GR:
|
2018-11-14 16:50:59 +01:00
|
|
|
build_collection(NULL, NULL, (Collection *)id);
|
2018-05-04 14:27:50 +02:00
|
|
|
break;
|
|
|
|
|
case ID_OB:
|
|
|
|
|
build_object(NULL, (Object *)id);
|
|
|
|
|
break;
|
2018-06-06 12:01:38 +02:00
|
|
|
case ID_KE:
|
|
|
|
|
build_shapekeys((Key *)id);
|
|
|
|
|
break;
|
|
|
|
|
case ID_LA:
|
2019-02-27 12:02:02 +11:00
|
|
|
build_light((Light *)id);
|
2018-06-06 12:01:38 +02:00
|
|
|
break;
|
|
|
|
|
case ID_LP:
|
|
|
|
|
build_lightprobe((LightProbe *)id);
|
|
|
|
|
break;
|
2018-05-04 14:27:50 +02:00
|
|
|
case ID_NT:
|
|
|
|
|
build_nodetree((bNodeTree *)id);
|
|
|
|
|
break;
|
|
|
|
|
case ID_MA:
|
|
|
|
|
build_material((Material *)id);
|
|
|
|
|
break;
|
|
|
|
|
case ID_TE:
|
|
|
|
|
build_texture((Tex *)id);
|
|
|
|
|
break;
|
|
|
|
|
case ID_WO:
|
|
|
|
|
build_world((World *)id);
|
|
|
|
|
break;
|
|
|
|
|
case ID_MSK:
|
|
|
|
|
build_mask((Mask *)id);
|
|
|
|
|
break;
|
|
|
|
|
case ID_MC:
|
|
|
|
|
build_movieclip((MovieClip *)id);
|
|
|
|
|
break;
|
2018-06-06 12:01:38 +02:00
|
|
|
case ID_ME:
|
|
|
|
|
case ID_CU:
|
|
|
|
|
case ID_MB:
|
|
|
|
|
case ID_LT:
|
|
|
|
|
build_object_data_geometry_datablock(id);
|
|
|
|
|
break;
|
2018-06-25 11:53:38 +02:00
|
|
|
case ID_SPK:
|
|
|
|
|
build_speaker((Speaker *)id);
|
|
|
|
|
break;
|
2018-09-19 10:30:41 +02:00
|
|
|
case ID_TXT:
|
|
|
|
|
/* Not a part of dependency graph. */
|
|
|
|
|
break;
|
2018-12-03 16:05:17 +01:00
|
|
|
case ID_CF:
|
|
|
|
|
build_cachefile((CacheFile *)id);
|
|
|
|
|
break;
|
2018-05-04 14:27:50 +02:00
|
|
|
default:
|
|
|
|
|
fprintf(stderr, "Unhandled ID %s\n", id->name);
|
2018-06-06 12:01:38 +02:00
|
|
|
BLI_assert(!"Should never happen");
|
|
|
|
|
break;
|
2018-05-04 14:27:50 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-08 11:42:41 +02:00
|
|
|
void DepsgraphRelationBuilder::build_collection(
|
2018-11-14 16:50:59 +01:00
|
|
|
LayerCollection *from_layer_collection,
|
2018-06-08 11:42:41 +02:00
|
|
|
Object *object,
|
|
|
|
|
Collection *collection)
|
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-11-14 16:50:59 +01:00
|
|
|
if (from_layer_collection != NULL) {
|
|
|
|
|
/* If we came from layer collection we don't go deeper, view layer
|
|
|
|
|
* builder takes care of going deeper.
|
|
|
|
|
*
|
|
|
|
|
* NOTE: Do early output before tagging build as done, so possbile
|
|
|
|
|
* subsequent builds from outside of the layer collection properly
|
|
|
|
|
* recurses into all the nested objects and collections. */
|
|
|
|
|
return;
|
|
|
|
|
}
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
const bool group_done = built_map_.checkIsBuiltAndTag(collection);
|
2018-06-21 15:47:55 +02:00
|
|
|
OperationKey object_transform_final_key(object != NULL ? &object->id : NULL,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_FINAL);
|
2018-09-19 15:09:55 +02:00
|
|
|
ComponentKey duplicator_key(object != NULL ? &object->id : NULL,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::DUPLI);
|
2017-12-01 11:24:21 -02:00
|
|
|
if (!group_done) {
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
LISTBASE_FOREACH (CollectionObject *, cob, &collection->gobject) {
|
|
|
|
|
build_object(NULL, cob->ob);
|
|
|
|
|
}
|
|
|
|
|
LISTBASE_FOREACH (CollectionChild *, child, &collection->children) {
|
2018-11-14 16:50:59 +01:00
|
|
|
build_collection(NULL, NULL, child->collection);
|
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
|
|
|
}
|
2017-12-01 11:24:21 -02:00
|
|
|
}
|
2018-02-02 12:21:24 +01:00
|
|
|
if (object != NULL) {
|
2018-06-08 19:26:46 +02:00
|
|
|
FOREACH_COLLECTION_VISIBLE_OBJECT_RECURSIVE_BEGIN(collection, ob, graph_->mode)
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey dupli_transform_key(&ob->id, NodeType::TRANSFORM);
|
2018-09-19 15:09:55 +02:00
|
|
|
add_relation(dupli_transform_key,
|
|
|
|
|
object_transform_final_key,
|
|
|
|
|
"Dupligroup");
|
|
|
|
|
/* Hook to special component, to ensure proper visibility/evaluation
|
2019-01-31 12:56:40 +01:00
|
|
|
* optimizations. */
|
2018-09-19 15:09:55 +02:00
|
|
|
add_relation(dupli_transform_key, duplicator_key, "Dupligroup");
|
2019-01-31 12:56:40 +01:00
|
|
|
const NodeType dupli_geometry_component_type =
|
|
|
|
|
geometry_tag_to_component(&ob->id);
|
|
|
|
|
if (dupli_geometry_component_type != NodeType::UNDEFINED) {
|
2018-09-19 15:09:55 +02:00
|
|
|
ComponentKey dupli_geometry_component_key(
|
|
|
|
|
&ob->id, dupli_geometry_component_type);
|
|
|
|
|
add_relation(dupli_geometry_component_key,
|
|
|
|
|
duplicator_key,
|
|
|
|
|
"Dupligroup");
|
|
|
|
|
}
|
2018-02-02 12:00:25 +01:00
|
|
|
}
|
2018-06-08 19:26:46 +02:00
|
|
|
FOREACH_COLLECTION_VISIBLE_OBJECT_RECURSIVE_END;
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-24 14:25:04 +01:00
|
|
|
void DepsgraphRelationBuilder::build_object(Base *base, Object *object)
|
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-02-22 11:03:39 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(object)) {
|
2017-11-24 14:27:54 +01:00
|
|
|
if (base != NULL) {
|
|
|
|
|
build_object_flags(base, object);
|
|
|
|
|
}
|
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;
|
|
|
|
|
}
|
|
|
|
|
/* Object Transforms */
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationCode base_op = (object->parent) ? OperationCode::TRANSFORM_PARENT
|
2019-02-06 17:04:29 +01:00
|
|
|
: OperationCode::TRANSFORM_LOCAL;
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationKey base_op_key(&object->id, NodeType::TRANSFORM, base_op);
|
2019-02-06 17:04:29 +01:00
|
|
|
OperationKey init_transform_key(
|
|
|
|
|
&object->id, NodeType::TRANSFORM, OperationCode::TRANSFORM_INIT);
|
|
|
|
|
OperationKey local_transform_key(
|
|
|
|
|
&object->id, NodeType::TRANSFORM, OperationCode::TRANSFORM_LOCAL);
|
|
|
|
|
OperationKey parent_transform_key(
|
|
|
|
|
&object->id, NodeType::TRANSFORM, OperationCode::TRANSFORM_PARENT);
|
|
|
|
|
OperationKey final_transform_key(
|
|
|
|
|
&object->id, NodeType::TRANSFORM, OperationCode::TRANSFORM_FINAL);
|
|
|
|
|
OperationKey ob_eval_key(
|
|
|
|
|
&object->id, NodeType::TRANSFORM, OperationCode::TRANSFORM_EVAL);
|
|
|
|
|
add_relation(init_transform_key, local_transform_key, "Transform Init");
|
2017-11-24 10:18:16 +01:00
|
|
|
/* Various flags, flushing from bases/collections. */
|
2017-11-24 14:25:04 +01:00
|
|
|
build_object_flags(base, object);
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Parenting. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->parent != NULL) {
|
2018-04-23 09:33:33 +02:00
|
|
|
/* Make sure parent object's relations are built. */
|
2018-04-23 09:34:50 +02:00
|
|
|
build_object(NULL, object->parent);
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Parent relationship. */
|
2017-11-23 11:39:28 +01:00
|
|
|
build_object_parent(object);
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Local -> parent. */
|
|
|
|
|
add_relation(local_transform_key,
|
|
|
|
|
parent_transform_key,
|
2017-12-04 12:48:16 +01:00
|
|
|
"ObLocal -> ObParent");
|
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
|
|
|
}
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Modifiers. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->modifiers.first != NULL) {
|
2017-05-30 17:42:04 +02:00
|
|
|
BuilderWalkUserData data;
|
|
|
|
|
data.builder = this;
|
2018-04-04 12:55:38 +02:00
|
|
|
modifiers_foreachIDLink(object, modifier_walk, &data);
|
2017-05-30 17:42:04 +02:00
|
|
|
}
|
2018-07-31 10:22:19 +02:00
|
|
|
/* Grease Pencil Modifiers. */
|
|
|
|
|
if (object->greasepencil_modifiers.first != NULL) {
|
|
|
|
|
BuilderWalkUserData data;
|
|
|
|
|
data.builder = this;
|
|
|
|
|
BKE_gpencil_modifiers_foreachIDLink(object, modifier_walk, &data);
|
|
|
|
|
}
|
|
|
|
|
/* Shader FX. */
|
|
|
|
|
if (object->shader_fx.first != NULL) {
|
|
|
|
|
BuilderWalkUserData data;
|
|
|
|
|
data.builder = this;
|
|
|
|
|
BKE_shaderfx_foreachIDLink(object, modifier_walk, &data);
|
|
|
|
|
}
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Constraints. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->constraints.first != NULL) {
|
2017-05-30 17:42:04 +02:00
|
|
|
BuilderWalkUserData data;
|
|
|
|
|
data.builder = this;
|
2017-11-23 11:39:28 +01:00
|
|
|
BKE_constraints_id_loop(&object->constraints, constraint_walk, &data);
|
2017-05-30 17:42:04 +02:00
|
|
|
}
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Object constraints. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->constraints.first != NULL) {
|
|
|
|
|
OperationKey constraint_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_CONSTRAINTS);
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Constraint relations. */
|
2017-11-23 11:39:28 +01:00
|
|
|
build_constraints(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
2017-03-16 15:27:03 +01:00
|
|
|
"",
|
2017-11-23 11:39:28 +01:00
|
|
|
&object->constraints,
|
2017-03-16 15:27:03 +01:00
|
|
|
NULL);
|
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
|
|
|
/* operation order */
|
2017-12-04 12:48:16 +01:00
|
|
|
add_relation(base_op_key, constraint_key, "ObBase-> Constraint Stack");
|
|
|
|
|
add_relation(constraint_key, final_transform_key, "ObConstraints -> Done");
|
2019-02-06 17:04:29 +01:00
|
|
|
add_relation(constraint_key, ob_eval_key, "Eval");
|
|
|
|
|
add_relation(ob_eval_key, final_transform_key, "Eval");
|
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
|
|
|
}
|
|
|
|
|
else {
|
2019-02-12 12:32:03 +01:00
|
|
|
add_relation(base_op_key, ob_eval_key, "Eval");
|
2019-02-06 17:04:29 +01:00
|
|
|
add_relation(ob_eval_key, final_transform_key, "Eval");
|
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
|
|
|
}
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Animation data */
|
2017-11-23 11:39:28 +01:00
|
|
|
build_animdata(&object->id);
|
2017-11-23 12:01:31 +01:00
|
|
|
/* Object data. */
|
|
|
|
|
build_object_data(object);
|
2017-03-16 15:27:03 +01:00
|
|
|
/* Particle systems. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->particlesystem.first != NULL) {
|
2018-12-10 15:09:46 +01:00
|
|
|
build_particle_systems(object);
|
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-05-31 20:51:29 +02:00
|
|
|
/* Proxy object to copy from. */
|
|
|
|
|
if (object->proxy_from != NULL) {
|
|
|
|
|
build_object(NULL, object->proxy_from);
|
2019-02-06 17:04:29 +01:00
|
|
|
ComponentKey ob_transform_key(
|
|
|
|
|
&object->proxy_from->id, NodeType::TRANSFORM);
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey proxy_transform_key(&object->id, NodeType::TRANSFORM);
|
2018-05-28 23:18:47 +02:00
|
|
|
add_relation(ob_transform_key, proxy_transform_key, "Proxy Transform");
|
2017-03-16 15:27:03 +01:00
|
|
|
}
|
2018-06-21 15:56:06 +02:00
|
|
|
if (object->proxy_group != NULL) {
|
2018-06-21 15:41:51 +02:00
|
|
|
build_object(NULL, object->proxy_group);
|
2019-02-06 17:04:29 +01:00
|
|
|
OperationKey proxy_group_eval_key(&object->proxy_group->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_EVAL);
|
|
|
|
|
add_relation(proxy_group_eval_key,
|
|
|
|
|
final_transform_key,
|
|
|
|
|
"Proxy Group Transform");
|
2018-06-21 15:41:51 +02:00
|
|
|
}
|
2017-03-16 15:27:03 +01:00
|
|
|
/* Object dupligroup. */
|
2019-02-17 19:00:54 +11:00
|
|
|
if (object->instance_collection != NULL) {
|
|
|
|
|
build_collection(NULL, object, object->instance_collection);
|
2017-03-16 15:27:03 +01:00
|
|
|
}
|
2018-11-14 11:24:54 +01:00
|
|
|
/* Point caches. */
|
|
|
|
|
build_object_pointcache(object);
|
2018-12-04 16:04:10 +01:00
|
|
|
/* Syncronization back to original object. */
|
|
|
|
|
OperationKey synchronize_key(&object->id,
|
2019-01-31 19:57:47 +01:00
|
|
|
NodeType::SYNCHRONIZATION,
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationCode::SYNCHRONIZE_TO_ORIGINAL);
|
2018-12-04 16:04:10 +01:00
|
|
|
add_relation(
|
|
|
|
|
final_transform_key, synchronize_key, "Synchronize to Original");
|
2019-02-20 11:48:42 +01:00
|
|
|
/* Parameters. */
|
|
|
|
|
build_parameters(&object->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
|
|
|
}
|
|
|
|
|
|
2017-11-24 14:25:04 +01:00
|
|
|
void DepsgraphRelationBuilder::build_object_flags(Base *base, Object *object)
|
2017-11-24 10:18:16 +01:00
|
|
|
{
|
2017-11-24 14:25:04 +01:00
|
|
|
if (base == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2017-11-24 10:18:16 +01:00
|
|
|
OperationKey view_layer_done_key(&scene_->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::LAYER_COLLECTIONS,
|
|
|
|
|
OperationCode::VIEW_LAYER_EVAL);
|
2017-11-24 10:18:16 +01:00
|
|
|
OperationKey object_flags_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::OBJECT_FROM_LAYER,
|
|
|
|
|
OperationCode::OBJECT_BASE_FLAGS);
|
2017-11-24 10:18:16 +01:00
|
|
|
add_relation(view_layer_done_key, object_flags_key, "Base flags flush");
|
2018-12-04 16:04:10 +01:00
|
|
|
/* Syncronization back to original object. */
|
|
|
|
|
OperationKey synchronize_key(&object->id,
|
2019-01-31 19:57:47 +01:00
|
|
|
NodeType::SYNCHRONIZATION,
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationCode::SYNCHRONIZE_TO_ORIGINAL);
|
2018-12-04 16:04:10 +01:00
|
|
|
add_relation(
|
|
|
|
|
object_flags_key, synchronize_key, "Synchronize to Original");
|
2017-11-24 10:18:16 +01:00
|
|
|
}
|
|
|
|
|
|
2017-11-23 12:01:31 +01:00
|
|
|
void DepsgraphRelationBuilder::build_object_data(Object *object)
|
|
|
|
|
{
|
|
|
|
|
if (object->data == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ID *obdata_id = (ID *)object->data;
|
|
|
|
|
/* Object data animation. */
|
2018-05-04 12:49:28 +02:00
|
|
|
if (!built_map_.checkIsBuilt(obdata_id)) {
|
|
|
|
|
build_animdata(obdata_id);
|
|
|
|
|
}
|
2017-11-23 12:01:31 +01:00
|
|
|
/* type-specific data. */
|
|
|
|
|
switch (object->type) {
|
|
|
|
|
case OB_MESH:
|
|
|
|
|
case OB_CURVE:
|
|
|
|
|
case OB_FONT:
|
|
|
|
|
case OB_SURF:
|
|
|
|
|
case OB_MBALL:
|
|
|
|
|
case OB_LATTICE:
|
2018-07-31 10:22:19 +02:00
|
|
|
case OB_GPENCIL:
|
2017-11-23 12:01:31 +01:00
|
|
|
{
|
2018-06-06 11:22:20 +02:00
|
|
|
build_object_data_geometry(object);
|
2018-10-24 12:31:24 +03:00
|
|
|
/* TODO(sergey): Only for until we support granular
|
2019-01-31 12:56:40 +01:00
|
|
|
* update of curves. */
|
2018-10-24 12:31:24 +03:00
|
|
|
if (object->type == OB_FONT) {
|
|
|
|
|
Curve *curve = (Curve *)object->data;
|
|
|
|
|
if (curve->textoncurve) {
|
|
|
|
|
add_special_eval_flag(&curve->textoncurve->id, DAG_EVAL_NEED_CURVE_PATH);
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-11-23 12:01:31 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case OB_ARMATURE:
|
|
|
|
|
if (ID_IS_LINKED(object) && object->proxy_from != NULL) {
|
|
|
|
|
build_proxy_rig(object);
|
|
|
|
|
}
|
|
|
|
|
else {
|
2018-05-04 12:49:28 +02:00
|
|
|
build_rig(object);
|
2017-11-23 12:01:31 +01:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case OB_LAMP:
|
2019-02-27 12:02:02 +11:00
|
|
|
build_object_data_light(object);
|
2017-11-23 12:01:31 +01:00
|
|
|
break;
|
|
|
|
|
case OB_CAMERA:
|
2018-06-06 10:52:50 +02:00
|
|
|
build_object_data_camera(object);
|
2017-11-23 12:01:31 +01:00
|
|
|
break;
|
2017-11-23 12:04:57 +01:00
|
|
|
case OB_LIGHTPROBE:
|
2018-06-06 10:23:45 +02:00
|
|
|
build_object_data_lightprobe(object);
|
2017-11-23 12:04:57 +01:00
|
|
|
break;
|
2018-06-25 11:53:38 +02:00
|
|
|
case OB_SPEAKER:
|
|
|
|
|
build_object_data_speaker(object);
|
|
|
|
|
break;
|
2017-11-23 12:01:31 +01:00
|
|
|
}
|
|
|
|
|
Key *key = BKE_key_from_object(object);
|
|
|
|
|
if (key != NULL) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey geometry_key((ID *)object->data, NodeType::GEOMETRY);
|
|
|
|
|
ComponentKey key_key(&key->id, NodeType::GEOMETRY);
|
2017-11-23 12:01:31 +01:00
|
|
|
add_relation(key_key, geometry_key, "Shapekeys");
|
2018-05-01 12:41:10 +02:00
|
|
|
build_nested_shapekey(&object->id, key);
|
2017-11-23 12:01:31 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-06 10:52:50 +02:00
|
|
|
void DepsgraphRelationBuilder::build_object_data_camera(Object *object)
|
|
|
|
|
{
|
|
|
|
|
Camera *camera = (Camera *)object->data;
|
|
|
|
|
build_camera(camera);
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey object_parameters_key(&object->id, NodeType::PARAMETERS);
|
|
|
|
|
ComponentKey camera_parameters_key(&camera->id, NodeType::PARAMETERS);
|
2018-06-06 10:52:50 +02:00
|
|
|
add_relation(camera_parameters_key, object_parameters_key, "Camera -> Object");
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-27 12:02:02 +11:00
|
|
|
void DepsgraphRelationBuilder::build_object_data_light(Object *object)
|
2018-06-06 10:47:54 +02:00
|
|
|
{
|
2019-02-27 10:46:48 +11:00
|
|
|
Light *lamp = (Light *)object->data;
|
2019-02-27 12:02:02 +11:00
|
|
|
build_light(lamp);
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey lamp_parameters_key(&lamp->id, NodeType::PARAMETERS);
|
2019-02-20 11:48:42 +01:00
|
|
|
ComponentKey object_parameters_key(&object->id, NodeType::PARAMETERS);
|
2018-06-27 14:41:53 +02:00
|
|
|
add_relation(lamp_parameters_key, object_parameters_key, "Light -> Object");
|
2018-06-06 10:47:54 +02:00
|
|
|
}
|
|
|
|
|
|
2018-06-06 10:23:45 +02:00
|
|
|
void DepsgraphRelationBuilder::build_object_data_lightprobe(Object *object)
|
|
|
|
|
{
|
|
|
|
|
LightProbe *probe = (LightProbe *)object->data;
|
|
|
|
|
build_lightprobe(probe);
|
|
|
|
|
OperationKey probe_key(&probe->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::LIGHT_PROBE_EVAL);
|
2018-06-06 10:23:45 +02:00
|
|
|
OperationKey object_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::LIGHT_PROBE_EVAL);
|
2018-06-06 10:23:45 +02:00
|
|
|
add_relation(probe_key, object_key, "LightProbe Update");
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-25 11:53:38 +02:00
|
|
|
void DepsgraphRelationBuilder::build_object_data_speaker(Object *object)
|
|
|
|
|
{
|
|
|
|
|
Speaker *speaker = (Speaker *)object->data;
|
|
|
|
|
build_speaker(speaker);
|
|
|
|
|
OperationKey probe_key(&speaker->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::SPEAKER_EVAL);
|
2018-06-25 11:53:38 +02:00
|
|
|
OperationKey object_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::SPEAKER_EVAL);
|
2018-06-25 11:53:38 +02:00
|
|
|
add_relation(probe_key, object_key, "Speaker Update");
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-23 11:39:28 +01:00
|
|
|
void DepsgraphRelationBuilder::build_object_parent(Object *object)
|
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-02-12 15:58:45 +01:00
|
|
|
Object *parent = object->parent;
|
2019-02-12 15:37:57 +01:00
|
|
|
ID *parent_id = &object->parent->id;
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey ob_key(&object->id, NodeType::TRANSFORM);
|
2019-02-12 15:37:57 +01:00
|
|
|
/* Type-specific links/ */
|
2017-11-23 11:39:28 +01:00
|
|
|
switch (object->partype) {
|
2019-02-12 15:37:57 +01:00
|
|
|
/* Armature Deform (Virtual Modifier) */
|
|
|
|
|
case PARSKEL:
|
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-02-12 15:37:57 +01:00
|
|
|
ComponentKey parent_key(parent_id, NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(parent_key, ob_key, "Armature Deform Parent");
|
2015-05-13 06:10:49 +10:00
|
|
|
break;
|
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-02-12 15:37:57 +01:00
|
|
|
/* Vertex Parent */
|
|
|
|
|
case PARVERT1:
|
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
|
|
|
case PARVERT3:
|
|
|
|
|
{
|
2019-02-12 15:37:57 +01:00
|
|
|
ComponentKey parent_key(parent_id, NodeType::GEOMETRY);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(parent_key, ob_key, "Vertex Parent");
|
2019-02-12 15:37:57 +01:00
|
|
|
/* Original index is used for optimizations of lookups for subdiv
|
|
|
|
|
* only meshes.
|
|
|
|
|
* TODO(sergey): This optimization got lost at 2.8, so either verify
|
|
|
|
|
* we can get rid of this mask here, or bring the optimization
|
|
|
|
|
* back. */
|
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
|
|
|
add_customdata_mask(object->parent,
|
|
|
|
|
DEGCustomDataMeshMasks::MaskVert(CD_MASK_ORIGINDEX) |
|
|
|
|
|
DEGCustomDataMeshMasks::MaskEdge(CD_MASK_ORIGINDEX) |
|
|
|
|
|
DEGCustomDataMeshMasks::MaskFace(CD_MASK_ORIGINDEX) |
|
|
|
|
|
DEGCustomDataMeshMasks::MaskPoly(CD_MASK_ORIGINDEX));
|
2019-02-12 15:37:57 +01:00
|
|
|
ComponentKey transform_key(parent_id, NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(transform_key, ob_key, "Vertex Parent TFM");
|
2015-05-13 06:10:49 +10:00
|
|
|
break;
|
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-02-12 15:37:57 +01:00
|
|
|
/* Bone Parent */
|
|
|
|
|
case PARBONE:
|
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-02-12 15:37:57 +01:00
|
|
|
ComponentKey parent_bone_key(
|
|
|
|
|
parent_id, NodeType::BONE, object->parsubstr);
|
|
|
|
|
OperationKey parent_transform_key(parent_id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_FINAL);
|
2017-06-01 16:20:48 +02:00
|
|
|
add_relation(parent_bone_key, ob_key, "Bone Parent");
|
|
|
|
|
add_relation(parent_transform_key, ob_key, "Armature Parent");
|
2015-05-13 06:10:49 +10:00
|
|
|
break;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
{
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->parent->type == OB_LATTICE) {
|
2019-02-12 15:37:57 +01:00
|
|
|
/* Lattice Deform Parent - Virtual Modifier. */
|
|
|
|
|
ComponentKey parent_key(parent_id, NodeType::TRANSFORM);
|
|
|
|
|
ComponentKey geom_key(parent_id, NodeType::GEOMETRY);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(parent_key, ob_key, "Lattice Deform Parent");
|
|
|
|
|
add_relation(geom_key, ob_key, "Lattice Deform Parent Geom");
|
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
|
|
|
}
|
2017-11-23 11:39:28 +01:00
|
|
|
else if (object->parent->type == OB_CURVE) {
|
|
|
|
|
Curve *cu = (Curve *)object->parent->data;
|
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
|
|
|
|
|
|
|
|
if (cu->flag & CU_PATH) {
|
2019-02-12 15:37:57 +01:00
|
|
|
/* Follow Path. */
|
|
|
|
|
ComponentKey parent_key(parent_id, NodeType::GEOMETRY);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(parent_key, ob_key, "Curve Follow Parent");
|
2019-02-12 15:37:57 +01:00
|
|
|
ComponentKey transform_key(parent_id, NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(transform_key, ob_key, "Curve Follow TFM");
|
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
|
|
|
}
|
|
|
|
|
else {
|
2019-02-12 15:37:57 +01:00
|
|
|
/* Standard Parent. */
|
|
|
|
|
ComponentKey parent_key(parent_id, NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(parent_key, ob_key, "Curve Parent");
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2019-02-12 15:37:57 +01:00
|
|
|
/* Standard Parent. */
|
|
|
|
|
ComponentKey parent_key(parent_id, NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(parent_key, ob_key, "Parent");
|
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
|
|
|
}
|
2015-05-13 06:10:49 +10:00
|
|
|
break;
|
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-02-12 15:58:45 +01:00
|
|
|
/* Metaballs are the odd balls here (no pun intended): they will request
|
|
|
|
|
* instance-list (formerly known as dupli-list) during evaluation. This is
|
|
|
|
|
* their way of interacting with all instanced surfaces, making a nice
|
|
|
|
|
* effect when is used form particle system. */
|
|
|
|
|
if (object->type == OB_MBALL && parent->transflag & OB_DUPLI) {
|
|
|
|
|
ComponentKey parent_geometry_key(parent_id, NodeType::GEOMETRY);
|
|
|
|
|
/* NOTE: Metaballs are evaluating geometry only after their transform,
|
|
|
|
|
* so we onl;y hook up to transform channel here. */
|
|
|
|
|
add_relation(parent_geometry_key, ob_key, "Parent");
|
|
|
|
|
}
|
2018-11-14 11:24:54 +01:00
|
|
|
}
|
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-11-14 11:24:54 +01:00
|
|
|
void DepsgraphRelationBuilder::build_object_pointcache(Object *object)
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey point_cache_key(&object->id, NodeType::POINT_CACHE);
|
2018-11-14 11:24:54 +01:00
|
|
|
/* Different point caches are affecting different aspects of life of the
|
|
|
|
|
* object. We keep track of those aspects and avoid duplicate relations. */
|
|
|
|
|
enum {
|
|
|
|
|
FLAG_TRANSFORM = (1 << 0),
|
|
|
|
|
FLAG_GEOMETRY = (1 << 1),
|
|
|
|
|
FLAG_ALL = (FLAG_TRANSFORM | FLAG_GEOMETRY),
|
|
|
|
|
};
|
|
|
|
|
ListBase ptcache_id_list;
|
|
|
|
|
BKE_ptcache_ids_from_object(&ptcache_id_list, object, scene_, 0);
|
|
|
|
|
int handled_components = 0;
|
|
|
|
|
LISTBASE_FOREACH (PTCacheID *, ptcache_id, &ptcache_id_list) {
|
|
|
|
|
/* Check which components needs the point cache. */
|
2019-02-01 10:22:24 +01:00
|
|
|
int flag = -1;
|
2018-11-14 11:24:54 +01:00
|
|
|
if (ptcache_id->type == PTCACHE_TYPE_RIGIDBODY) {
|
|
|
|
|
flag = FLAG_TRANSFORM;
|
2019-02-06 17:04:29 +01:00
|
|
|
OperationKey transform_key(&object->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_LOCAL);
|
2018-11-14 11:24:54 +01:00
|
|
|
add_relation(point_cache_key,
|
|
|
|
|
transform_key,
|
|
|
|
|
"Point Cache -> Rigid Body");
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
flag = FLAG_GEOMETRY;
|
2019-02-01 14:05:00 +01:00
|
|
|
OperationKey geometry_key(&object->id,
|
|
|
|
|
NodeType::GEOMETRY,
|
|
|
|
|
OperationCode::GEOMETRY_EVAL);
|
2019-02-01 10:22:24 +01:00
|
|
|
add_relation(
|
|
|
|
|
point_cache_key, geometry_key, "Point Cache -> Geometry");
|
2018-11-14 11:24:54 +01:00
|
|
|
}
|
2019-02-01 10:22:24 +01:00
|
|
|
BLI_assert(flag != -1);
|
2018-11-14 11:24:54 +01:00
|
|
|
/* Tag that we did handle that component. */
|
|
|
|
|
handled_components |= flag;
|
|
|
|
|
if (handled_components == FLAG_ALL) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
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-02-01 14:05:00 +01:00
|
|
|
/* Manual edits to any dependency (or self) should reset the point cache. */
|
|
|
|
|
if (!BLI_listbase_is_empty(&ptcache_id_list)) {
|
2019-02-06 17:04:29 +01:00
|
|
|
OperationKey transform_init_key(&object->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_INIT);
|
2019-02-01 14:05:00 +01:00
|
|
|
OperationKey geometry_init_key(&object->id,
|
|
|
|
|
NodeType::GEOMETRY,
|
|
|
|
|
OperationCode::GEOMETRY_EVAL_INIT);
|
2019-02-06 17:04:29 +01:00
|
|
|
add_relation(transform_init_key,
|
2019-02-01 14:05:00 +01:00
|
|
|
point_cache_key,
|
|
|
|
|
"Transform Local -> Point Cache",
|
|
|
|
|
RELATION_FLAG_FLUSH_USER_EDIT_ONLY);
|
|
|
|
|
add_relation(geometry_init_key,
|
|
|
|
|
point_cache_key,
|
|
|
|
|
"Geometry Init -> Point Cache",
|
|
|
|
|
RELATION_FLAG_FLUSH_USER_EDIT_ONLY);
|
|
|
|
|
}
|
2018-11-14 11:24:54 +01:00
|
|
|
BLI_freelistN(&ptcache_id_list);
|
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
|
|
|
}
|
|
|
|
|
|
2017-11-09 09:17:47 +01:00
|
|
|
void DepsgraphRelationBuilder::build_constraints(ID *id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType component_type,
|
2017-08-22 16:24:58 +02:00
|
|
|
const char *component_subdata,
|
|
|
|
|
ListBase *constraints,
|
|
|
|
|
RootPChanMap *root_map)
|
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
|
|
|
{
|
2017-08-22 16:24:58 +02:00
|
|
|
OperationKey constraint_op_key(
|
|
|
|
|
id,
|
|
|
|
|
component_type,
|
|
|
|
|
component_subdata,
|
2019-01-31 12:56:40 +01:00
|
|
|
(component_type == NodeType::BONE)
|
|
|
|
|
? OperationCode::BONE_CONSTRAINTS
|
|
|
|
|
: OperationCode::TRANSFORM_CONSTRAINTS);
|
2017-08-22 16:24:58 +02:00
|
|
|
/* Add dependencies for each constraint in turn. */
|
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
|
|
|
for (bConstraint *con = (bConstraint *)constraints->first; con; con = con->next) {
|
|
|
|
|
const bConstraintTypeInfo *cti = BKE_constraint_typeinfo_get(con);
|
2017-08-22 16:24:58 +02:00
|
|
|
/* Invalid constraint type. */
|
|
|
|
|
if (cti == NULL) {
|
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
|
|
|
continue;
|
2017-08-22 16:24:58 +02:00
|
|
|
}
|
|
|
|
|
/* Special case for camera tracking -- it doesn't use targets to
|
2019-01-31 12:56:40 +01:00
|
|
|
* define relations. */
|
2017-08-22 16:24:58 +02:00
|
|
|
/* TODO: we can now represent dependencies in a much richer manner,
|
2019-01-31 12:56:40 +01:00
|
|
|
* so review how this is done. */
|
2017-08-22 16:24:58 +02:00
|
|
|
if (ELEM(cti->type,
|
|
|
|
|
CONSTRAINT_TYPE_FOLLOWTRACK,
|
|
|
|
|
CONSTRAINT_TYPE_CAMERASOLVER,
|
|
|
|
|
CONSTRAINT_TYPE_OBJECTSOLVER))
|
|
|
|
|
{
|
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
|
|
|
bool depends_on_camera = false;
|
|
|
|
|
if (cti->type == CONSTRAINT_TYPE_FOLLOWTRACK) {
|
|
|
|
|
bFollowTrackConstraint *data = (bFollowTrackConstraint *)con->data;
|
2017-08-22 16:24:58 +02:00
|
|
|
if (((data->clip) ||
|
|
|
|
|
(data->flag & FOLLOWTRACK_ACTIVECLIP)) && data->track[0])
|
|
|
|
|
{
|
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
|
|
|
depends_on_camera = true;
|
2017-08-22 16:24:58 +02:00
|
|
|
}
|
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
|
|
|
if (data->depth_ob) {
|
2017-09-14 12:31:54 +05:00
|
|
|
ComponentKey depth_transform_key(&data->depth_ob->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2017-09-14 12:31:54 +05:00
|
|
|
ComponentKey depth_geometry_key(&data->depth_ob->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY);
|
2017-09-14 12:31:54 +05:00
|
|
|
add_relation(depth_transform_key, constraint_op_key, cti->name);
|
|
|
|
|
add_relation(depth_geometry_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (cti->type == CONSTRAINT_TYPE_OBJECTSOLVER) {
|
|
|
|
|
depends_on_camera = true;
|
|
|
|
|
}
|
2017-11-09 09:17:47 +01:00
|
|
|
if (depends_on_camera && scene_->camera != NULL) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey camera_key(&scene_->camera->id, NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(camera_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
2017-08-22 16:24:58 +02:00
|
|
|
/* TODO(sergey): This is more a TimeSource -> MovieClip ->
|
2019-01-31 12:56:40 +01:00
|
|
|
* Constraint dependency chain. */
|
2015-11-24 14:44:38 +05:00
|
|
|
TimeSourceKey time_src_key;
|
2017-12-04 12:48:16 +01:00
|
|
|
add_relation(time_src_key, constraint_op_key, "TimeSrc -> Animation");
|
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
|
|
|
}
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
else if (cti->type == CONSTRAINT_TYPE_TRANSFORM_CACHE) {
|
2017-08-22 16:24:58 +02:00
|
|
|
/* TODO(kevin): This is more a TimeSource -> CacheFile -> Constraint
|
2019-01-31 12:56:40 +01:00
|
|
|
* dependency chain. */
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
TimeSourceKey time_src_key;
|
2017-12-04 12:48:16 +01:00
|
|
|
add_relation(time_src_key, constraint_op_key, "TimeSrc -> Animation");
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
bTransformCacheConstraint *data = (bTransformCacheConstraint *)con->data;
|
|
|
|
|
if (data->cache_file) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey cache_key(&data->cache_file->id, NodeType::CACHE);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(cache_key, constraint_op_key, cti->name);
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
else if (cti->get_constraint_targets) {
|
|
|
|
|
ListBase targets = {NULL, NULL};
|
|
|
|
|
cti->get_constraint_targets(con, &targets);
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (bConstraintTarget *, ct, &targets) {
|
2016-11-17 15:11:55 +01:00
|
|
|
if (ct->tar == NULL) {
|
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
|
|
|
continue;
|
2016-11-17 15:11:55 +01:00
|
|
|
}
|
2017-08-22 16:24:58 +02:00
|
|
|
if (ELEM(con->type,
|
|
|
|
|
CONSTRAINT_TYPE_KINEMATIC,
|
|
|
|
|
CONSTRAINT_TYPE_SPLINEIK))
|
|
|
|
|
{
|
|
|
|
|
/* Ignore IK constraints - these are handled separately
|
2019-01-31 12:56:40 +01:00
|
|
|
* (on pose level). */
|
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
|
|
|
}
|
2017-08-22 16:24:58 +02:00
|
|
|
else if (ELEM(con->type,
|
|
|
|
|
CONSTRAINT_TYPE_FOLLOWPATH,
|
|
|
|
|
CONSTRAINT_TYPE_CLAMPTO))
|
|
|
|
|
{
|
|
|
|
|
/* These constraints require path geometry data. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey target_key(&ct->tar->id, NodeType::GEOMETRY);
|
2017-08-22 16:24:58 +02:00
|
|
|
add_relation(target_key, constraint_op_key, cti->name);
|
2017-08-22 16:27:33 +02:00
|
|
|
ComponentKey target_transform_key(&ct->tar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2017-08-22 16:27:33 +02:00
|
|
|
add_relation(target_transform_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
|
|
|
|
else if ((ct->tar->type == OB_ARMATURE) && (ct->subtarget[0])) {
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationCode opcode;
|
2018-08-09 17:17:40 +03:00
|
|
|
/* relation to bone */
|
|
|
|
|
opcode = bone_target_opcode(&ct->tar->id, ct->subtarget,
|
|
|
|
|
id, component_subdata, root_map);
|
2018-11-22 13:38:03 +03:00
|
|
|
/* Armature constraint always wants the final position and chan_mat. */
|
|
|
|
|
if (ELEM(con->type, CONSTRAINT_TYPE_ARMATURE)) {
|
2019-01-31 12:56:40 +01:00
|
|
|
opcode = OperationCode::BONE_DONE;
|
2018-11-22 13:38:03 +03:00
|
|
|
}
|
|
|
|
|
/* if needs bbone shape, reference the segment computation */
|
|
|
|
|
if (BKE_constraint_target_uses_bbone(con, ct) &&
|
2018-11-27 08:00:49 +11:00
|
|
|
bone_has_segments(ct->tar, ct->subtarget))
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
opcode = OperationCode::BONE_SEGMENTS;
|
2018-11-22 13:38:03 +03:00
|
|
|
}
|
2018-08-09 17:17:40 +03:00
|
|
|
OperationKey target_key(&ct->tar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::BONE,
|
2018-08-09 17:17:40 +03:00
|
|
|
ct->subtarget,
|
|
|
|
|
opcode);
|
|
|
|
|
add_relation(target_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
2017-08-22 16:24:58 +02:00
|
|
|
else if (ELEM(ct->tar->type, OB_MESH, OB_LATTICE) &&
|
|
|
|
|
(ct->subtarget[0]))
|
|
|
|
|
{
|
|
|
|
|
/* Vertex group. */
|
2019-01-31 17:57:01 +01:00
|
|
|
/* NOTE: Vertex group is likely to be used to get vertices
|
|
|
|
|
* in a world space. This requires to know both geometry
|
|
|
|
|
* and transformation of the target object. */
|
|
|
|
|
ComponentKey target_transform_key(
|
|
|
|
|
&ct->tar->id, NodeType::TRANSFORM);
|
|
|
|
|
ComponentKey target_geometry_key(
|
|
|
|
|
&ct->tar->id, NodeType::GEOMETRY);
|
|
|
|
|
add_relation(
|
|
|
|
|
target_transform_key, constraint_op_key, cti->name);
|
|
|
|
|
add_relation(
|
|
|
|
|
target_geometry_key, constraint_op_key, cti->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
|
|
|
add_customdata_mask(ct->tar, DEGCustomDataMeshMasks::MaskVert(CD_MASK_MDEFORMVERT));
|
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
|
|
|
}
|
|
|
|
|
else if (con->type == CONSTRAINT_TYPE_SHRINKWRAP) {
|
2018-10-03 19:09:43 +03:00
|
|
|
bShrinkwrapConstraint *scon = (bShrinkwrapConstraint *) con->data;
|
|
|
|
|
|
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
|
|
|
/* Constraints which requires the target object surface. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey target_key(&ct->tar->id, NodeType::GEOMETRY);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(target_key, constraint_op_key, cti->name);
|
2018-10-03 19:09:43 +03:00
|
|
|
|
|
|
|
|
/* Add dependency on normal layers if necessary. */
|
|
|
|
|
if (ct->tar->type == OB_MESH && scon->shrinkType != MOD_SHRINKWRAP_NEAREST_VERTEX) {
|
|
|
|
|
bool track = (scon->flag & CON_SHRINKWRAP_TRACK_NORMAL) != 0;
|
|
|
|
|
if (track || BKE_shrinkwrap_needs_normals(scon->shrinkType, scon->shrinkMode)) {
|
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
|
|
|
add_customdata_mask(ct->tar,
|
|
|
|
|
DEGCustomDataMeshMasks::MaskVert(CD_MASK_NORMAL) |
|
|
|
|
|
DEGCustomDataMeshMasks::MaskLoop(CD_MASK_CUSTOMLOOPNORMAL));
|
2018-10-03 19:09:43 +03:00
|
|
|
}
|
Shrinkwrap: new mode that projects along the target normal.
The Nearest Surface Point shrink method, while fast, is neither
smooth nor continuous: as the source point moves, the projected
point can both stop and jump. This causes distortions in the
deformation of the shrinkwrap modifier, and the motion of an
animated object with a shrinkwrap constraint.
This patch implements a new mode, which, instead of using the simple
nearest point search, iteratively solves an equation for each triangle
to find a point which has its interpolated normal point to or from the
original vertex. Non-manifold boundary edges are treated as infinitely
thin cylinders that cast normals in all perpendicular directions.
Since this is useful for the constraint, and having multiple
objects with constraints targeting the same guide mesh is a quite
reasonable use case, rather than calculating the mesh boundary edge
data over and over again, it is precomputed and cached in the mesh.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D3836
2018-11-06 21:04:53 +03:00
|
|
|
if (scon->shrinkType == MOD_SHRINKWRAP_TARGET_PROJECT) {
|
|
|
|
|
add_special_eval_flag(&ct->tar->id, DAG_EVAL_NEED_SHRINKWRAP_BOUNDARY);
|
|
|
|
|
}
|
2018-10-03 19:09:43 +03:00
|
|
|
}
|
|
|
|
|
|
2017-08-22 16:24:58 +02:00
|
|
|
/* NOTE: obdata eval now doesn't necessarily depend on the
|
2019-01-31 12:56:40 +01:00
|
|
|
* object's transform. */
|
2017-08-22 16:24:58 +02:00
|
|
|
ComponentKey target_transform_key(&ct->tar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(target_transform_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
|
|
|
|
else {
|
2017-08-22 16:24:58 +02:00
|
|
|
/* Standard object relation. */
|
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: loc vs rot vs scale?
|
|
|
|
|
if (&ct->tar->id == id) {
|
2018-09-24 17:27:41 +02:00
|
|
|
/* Constraint targeting own object:
|
2017-08-22 16:24:58 +02:00
|
|
|
* - This case is fine IFF we're dealing with a bone
|
|
|
|
|
* constraint pointing to its own armature. In that
|
|
|
|
|
* case, it's just transform -> bone.
|
2018-09-24 17:27:41 +02:00
|
|
|
* - If however it is a real self targeting case, just
|
2017-08-22 16:24:58 +02:00
|
|
|
* make it depend on the previous constraint (or the
|
2019-01-31 12:56:40 +01:00
|
|
|
* pre-constraint state). */
|
2017-08-22 16:24:58 +02:00
|
|
|
if ((ct->tar->type == OB_ARMATURE) &&
|
2019-01-31 12:56:40 +01:00
|
|
|
(component_type == NodeType::BONE))
|
2017-08-22 16:24:58 +02:00
|
|
|
{
|
|
|
|
|
OperationKey target_key(&ct->tar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_FINAL);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(target_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
|
|
|
|
else {
|
2017-08-22 16:24:58 +02:00
|
|
|
OperationKey target_key(&ct->tar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_LOCAL);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(target_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2017-08-22 16:24:58 +02:00
|
|
|
/* Normal object dependency. */
|
|
|
|
|
OperationKey target_key(&ct->tar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_FINAL);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(target_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* Constraints which needs world's matrix for transform.
|
2019-01-31 12:56:40 +01:00
|
|
|
* TODO(sergey): More constraints here? */
|
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
|
|
|
if (ELEM(con->type,
|
|
|
|
|
CONSTRAINT_TYPE_ROTLIKE,
|
|
|
|
|
CONSTRAINT_TYPE_SIZELIKE,
|
|
|
|
|
CONSTRAINT_TYPE_LOCLIKE,
|
|
|
|
|
CONSTRAINT_TYPE_TRANSLIKE))
|
|
|
|
|
{
|
|
|
|
|
/* TODO(sergey): Add used space check. */
|
2017-08-22 16:24:58 +02:00
|
|
|
ComponentKey target_transform_key(&ct->tar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(target_transform_key, constraint_op_key, cti->name);
|
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
|
|
|
}
|
|
|
|
|
}
|
2017-08-22 16:24:58 +02:00
|
|
|
if (cti->flush_constraint_targets) {
|
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
|
|
|
cti->flush_constraint_targets(con, &targets, 1);
|
2017-08-22 16:24:58 +02:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_animdata(ID *id)
|
|
|
|
|
{
|
2019-02-18 13:23:49 +01:00
|
|
|
/* Images. */
|
|
|
|
|
build_animation_images(id);
|
2017-12-04 18:34:27 +01:00
|
|
|
/* Animation curves and NLA. */
|
|
|
|
|
build_animdata_curves(id);
|
|
|
|
|
/* Drivers. */
|
2017-12-23 23:54:05 +13:00
|
|
|
build_animdata_drivers(id);
|
2017-12-04 18:34:27 +01:00
|
|
|
}
|
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
|
|
|
|
2017-12-04 18:34:27 +01:00
|
|
|
void DepsgraphRelationBuilder::build_animdata_curves(ID *id)
|
|
|
|
|
{
|
|
|
|
|
AnimData *adt = BKE_animdata_from_id(id);
|
|
|
|
|
if (adt == NULL) {
|
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;
|
2017-12-04 18:34:27 +01:00
|
|
|
}
|
2018-06-27 14:36:37 +02:00
|
|
|
if (adt->action != NULL) {
|
|
|
|
|
build_action(adt->action);
|
|
|
|
|
}
|
2019-02-20 11:32:22 +01:00
|
|
|
if (adt->action == NULL && BLI_listbase_is_empty(&adt->nla_tracks)) {
|
2017-12-04 18:34:27 +01:00
|
|
|
return;
|
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-02-20 11:32:22 +01:00
|
|
|
/* Ensure evaluation order from entry to exit. */
|
|
|
|
|
OperationKey animation_entry_key(
|
|
|
|
|
id, NodeType::ANIMATION, OperationCode::ANIMATION_ENTRY);
|
|
|
|
|
OperationKey animation_eval_key(
|
|
|
|
|
id, NodeType::ANIMATION, OperationCode::ANIMATION_EVAL);
|
|
|
|
|
OperationKey animation_exit_key(
|
|
|
|
|
id, NodeType::ANIMATION, OperationCode::ANIMATION_EXIT);
|
|
|
|
|
add_relation(animation_entry_key, animation_eval_key, "Init -> Eval");
|
|
|
|
|
add_relation(animation_eval_key, animation_exit_key, "Eval -> Exit");
|
|
|
|
|
/* Wire up dependency from action. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey adt_key(id, NodeType::ANIMATION);
|
2018-05-01 17:46:51 +02:00
|
|
|
/* Relation from action itself. */
|
2018-06-27 14:36:37 +02:00
|
|
|
if (adt->action != NULL) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey action_key(&adt->action->id, NodeType::ANIMATION);
|
2018-05-01 17:46:51 +02:00
|
|
|
add_relation(action_key, adt_key, "Action -> Animation");
|
|
|
|
|
}
|
2018-01-29 19:01:44 +13:00
|
|
|
/* Get source operations. */
|
2019-01-31 12:56:40 +01:00
|
|
|
Node *node_from = get_node(adt_key);
|
2017-12-05 16:09:03 +01:00
|
|
|
BLI_assert(node_from != NULL);
|
|
|
|
|
if (node_from == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationNode *operation_from = node_from->get_exit_operation();
|
2017-12-05 16:09:03 +01:00
|
|
|
BLI_assert(operation_from != NULL);
|
2018-01-29 19:01:44 +13:00
|
|
|
/* Build relations from animation operation to properties it changes. */
|
|
|
|
|
if (adt->action != NULL) {
|
2019-02-20 11:15:19 +01:00
|
|
|
build_animdata_curves_targets(
|
|
|
|
|
id, adt_key, operation_from, &adt->action->curves);
|
2018-01-29 19:01:44 +13:00
|
|
|
}
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH(NlaTrack *, nlt, &adt->nla_tracks) {
|
2019-02-20 11:15:19 +01:00
|
|
|
build_animdata_nlastrip_targets(
|
|
|
|
|
id, adt_key, operation_from, &nlt->strips);
|
2018-01-29 19:01:44 +13:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_animdata_curves_targets(
|
|
|
|
|
ID *id, ComponentKey &adt_key,
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationNode *operation_from,
|
2018-01-29 19:01:44 +13:00
|
|
|
ListBase *curves)
|
|
|
|
|
{
|
2017-12-05 16:09:03 +01:00
|
|
|
/* Iterate over all curves and build relations. */
|
|
|
|
|
PointerRNA id_ptr;
|
|
|
|
|
RNA_id_pointer_create(id, &id_ptr);
|
2019-02-01 10:24:12 +01:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, curves) {
|
2017-12-05 16:09:03 +01:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
int index;
|
2019-02-20 11:15:19 +01:00
|
|
|
if (!RNA_path_resolve_full(
|
|
|
|
|
&id_ptr, fcu->rna_path, &ptr, &prop, &index))
|
2017-12-05 16:09:03 +01:00
|
|
|
{
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2019-02-15 12:45:56 +01:00
|
|
|
Node *node_to = rna_node_query_.find_node(
|
2019-01-31 10:18:39 +01:00
|
|
|
&ptr, prop, RNAPointerSource::ENTRY);
|
2017-12-05 16:09:03 +01:00
|
|
|
if (node_to == NULL) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationNode *operation_to = node_to->get_entry_operation();
|
2017-12-05 16:09:03 +01:00
|
|
|
/* NOTE: Special case for bones, avoid relation from animation to
|
|
|
|
|
* each of the bones. Bone evaluation could only start from pose
|
2019-01-31 12:56:40 +01:00
|
|
|
* init anyway. */
|
|
|
|
|
if (operation_to->opcode == OperationCode::BONE_LOCAL) {
|
2019-02-20 11:15:19 +01:00
|
|
|
OperationKey pose_init_key(
|
|
|
|
|
id, NodeType::EVAL_POSE, OperationCode::POSE_INIT);
|
2019-01-31 12:56:40 +01:00
|
|
|
add_relation(adt_key,
|
|
|
|
|
pose_init_key,
|
|
|
|
|
"Animation -> Prop",
|
|
|
|
|
RELATION_CHECK_BEFORE_ADD);
|
2017-12-05 16:09:03 +01:00
|
|
|
continue;
|
2017-12-05 10:14:12 +01:00
|
|
|
}
|
2017-12-05 16:09:03 +01:00
|
|
|
graph_->add_new_relation(operation_from, operation_to,
|
|
|
|
|
"Animation -> Prop",
|
2019-01-31 12:56:40 +01:00
|
|
|
RELATION_CHECK_BEFORE_ADD);
|
2018-01-24 11:00:37 +01:00
|
|
|
/* It is possible that animation is writing to a nested ID datablock,
|
2019-01-31 12:56:40 +01:00
|
|
|
* need to make sure animation is evaluated after target ID is copied. */
|
|
|
|
|
const IDNode *id_node_from = operation_from->owner->owner;
|
|
|
|
|
const IDNode *id_node_to = operation_to->owner->owner;
|
2018-05-31 13:42:55 +02:00
|
|
|
if (id_node_from != id_node_to) {
|
2019-02-20 11:15:19 +01:00
|
|
|
ComponentKey cow_key(id_node_to->id_orig, NodeType::COPY_ON_WRITE);
|
2019-01-31 12:56:40 +01:00
|
|
|
add_relation(cow_key,
|
|
|
|
|
adt_key,
|
|
|
|
|
"Animated CoW -> Animation",
|
|
|
|
|
RELATION_CHECK_BEFORE_ADD);
|
2018-01-24 11:00:37 +01:00
|
|
|
}
|
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
|
|
|
}
|
2017-12-04 18:34:27 +01:00
|
|
|
}
|
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-01-29 19:01:44 +13:00
|
|
|
void DepsgraphRelationBuilder::build_animdata_nlastrip_targets(
|
|
|
|
|
ID *id, ComponentKey &adt_key,
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationNode *operation_from,
|
2018-01-29 19:01:44 +13:00
|
|
|
ListBase *strips)
|
|
|
|
|
{
|
2019-02-01 10:24:12 +01:00
|
|
|
LISTBASE_FOREACH (NlaStrip *, strip, strips) {
|
2018-01-29 19:01:44 +13:00
|
|
|
if (strip->act != NULL) {
|
2018-11-07 18:14:00 +03:00
|
|
|
build_action(strip->act);
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey action_key(&strip->act->id, NodeType::ANIMATION);
|
2018-11-07 18:14:00 +03:00
|
|
|
add_relation(action_key, adt_key, "Action -> Animation");
|
|
|
|
|
|
2019-02-20 11:15:19 +01:00
|
|
|
build_animdata_curves_targets(
|
|
|
|
|
id, adt_key, operation_from, &strip->act->curves);
|
2018-01-29 19:01:44 +13:00
|
|
|
}
|
|
|
|
|
else if (strip->strips.first != NULL) {
|
2019-02-20 11:15:19 +01:00
|
|
|
build_animdata_nlastrip_targets(
|
|
|
|
|
id, adt_key, operation_from, &strip->strips);
|
2018-01-29 19:01:44 +13:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-23 23:54:05 +13:00
|
|
|
void DepsgraphRelationBuilder::build_animdata_drivers(ID *id)
|
2017-12-04 18:34:27 +01:00
|
|
|
{
|
|
|
|
|
AnimData *adt = BKE_animdata_from_id(id);
|
|
|
|
|
if (adt == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey adt_key(id, NodeType::ANIMATION);
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, &adt->drivers) {
|
2016-11-03 14:31:27 +01:00
|
|
|
OperationKey driver_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::DRIVER,
|
2017-05-11 16:28:21 +02:00
|
|
|
fcu->rna_path ? fcu->rna_path : "",
|
2016-11-03 14:31:27 +01:00
|
|
|
fcu->array_index);
|
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
|
|
|
|
|
|
|
|
/* create the driver's relations to targets */
|
|
|
|
|
build_driver(id, fcu);
|
2016-11-02 18:05:38 +01:00
|
|
|
/* Special case for array drivers: we can not multithread them because
|
|
|
|
|
* of the way how they work internally: animation system will write the
|
|
|
|
|
* whole array back to RNA even when changing individual array value.
|
|
|
|
|
*
|
|
|
|
|
* Some tricky things here:
|
|
|
|
|
* - array_index is -1 for single channel drivers, meaning we only have
|
|
|
|
|
* to do some magic when array_index is not -1.
|
|
|
|
|
* - We do relation from next array index to a previous one, so we don't
|
|
|
|
|
* have to deal with array index 0.
|
|
|
|
|
*
|
2019-01-31 12:56:40 +01:00
|
|
|
* TODO(sergey): Avoid liner lookup somehow. */
|
2016-11-02 18:05:38 +01:00
|
|
|
if (fcu->array_index > 0) {
|
|
|
|
|
FCurve *fcu_prev = NULL;
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu_candidate, &adt->drivers) {
|
2016-11-02 18:05:38 +01:00
|
|
|
/* Writing to different RNA paths is */
|
2017-05-11 16:28:21 +02:00
|
|
|
const char *rna_path = fcu->rna_path ? fcu->rna_path : "";
|
|
|
|
|
if (!STREQ(fcu_candidate->rna_path, rna_path)) {
|
2016-11-02 18:05:38 +01:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
/* We only do relation from previous fcurve to previous one. */
|
|
|
|
|
if (fcu_candidate->array_index >= fcu->array_index) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
/* Choose fcurve with highest possible array index. */
|
|
|
|
|
if (fcu_prev == NULL ||
|
|
|
|
|
fcu_candidate->array_index > fcu_prev->array_index)
|
|
|
|
|
{
|
|
|
|
|
fcu_prev = fcu_candidate;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (fcu_prev != NULL) {
|
|
|
|
|
OperationKey prev_driver_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::DRIVER,
|
2017-05-11 16:28:21 +02:00
|
|
|
fcu_prev->rna_path ? fcu_prev->rna_path : "",
|
2016-11-03 14:31:27 +01:00
|
|
|
fcu_prev->array_index);
|
2016-11-02 18:05:38 +01:00
|
|
|
OperationKey driver_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::DRIVER,
|
2017-05-11 16:28:21 +02:00
|
|
|
fcu->rna_path ? fcu->rna_path : "",
|
2016-11-03 14:31:27 +01:00
|
|
|
fcu->array_index);
|
2017-12-04 12:48:16 +01:00
|
|
|
add_relation(prev_driver_key, driver_key, "Driver Order");
|
2016-11-02 18:05:38 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* prevent driver from occurring before own animation... */
|
|
|
|
|
if (adt->action || adt->nla_tracks.first) {
|
2017-12-04 12:48:16 +01:00
|
|
|
add_relation(adt_key, driver_key, "AnimData Before Drivers");
|
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-02-18 13:23:49 +01:00
|
|
|
void DepsgraphRelationBuilder::build_animation_images(ID *id)
|
|
|
|
|
{
|
|
|
|
|
/* TODO: can we check for existance of node for performance? */
|
|
|
|
|
if (BKE_image_user_id_has_animation(id)) {
|
|
|
|
|
OperationKey image_animation_key(id,
|
|
|
|
|
NodeType::ANIMATION,
|
|
|
|
|
OperationCode::IMAGE_ANIMATION);
|
|
|
|
|
TimeSourceKey time_src_key;
|
|
|
|
|
add_relation(time_src_key, image_animation_key, "TimeSrc -> Image Animation");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-27 14:36:37 +02:00
|
|
|
void DepsgraphRelationBuilder::build_action(bAction *action)
|
|
|
|
|
{
|
|
|
|
|
if (built_map_.checkIsBuiltAndTag(action)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2018-06-27 16:10:37 +02:00
|
|
|
TimeSourceKey time_src_key;
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey animation_key(&action->id, NodeType::ANIMATION);
|
2018-06-27 16:10:37 +02:00
|
|
|
add_relation(time_src_key, animation_key, "TimeSrc -> Animation");
|
2018-06-27 14:36:37 +02:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
void DepsgraphRelationBuilder::build_driver(ID *id, FCurve *fcu)
|
|
|
|
|
{
|
|
|
|
|
ChannelDriver *driver = fcu->driver;
|
2016-11-03 14:31:27 +01:00
|
|
|
OperationKey driver_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::DRIVER,
|
2017-05-11 16:28:21 +02:00
|
|
|
fcu->rna_path ? fcu->rna_path : "",
|
2016-11-03 14:31:27 +01:00
|
|
|
fcu->array_index);
|
2017-08-08 15:24:35 +02:00
|
|
|
/* Driver -> data components (for interleaved evaluation
|
2019-01-31 12:56:40 +01:00
|
|
|
* bones/constraints/modifiers). */
|
2017-12-04 18:11:43 +01:00
|
|
|
build_driver_data(id, fcu);
|
|
|
|
|
/* Loop over variables to get the target relationships. */
|
|
|
|
|
build_driver_variables(id, fcu);
|
|
|
|
|
/* It's quite tricky to detect if the driver actually depends on time or
|
|
|
|
|
* not, so for now we'll be quite conservative here about optimization and
|
2019-01-31 12:56:40 +01:00
|
|
|
* consider all python drivers to be depending on time. */
|
2017-12-04 18:11:43 +01:00
|
|
|
if ((driver->type == DRIVER_TYPE_PYTHON) &&
|
|
|
|
|
python_driver_depends_on_time(driver))
|
|
|
|
|
{
|
|
|
|
|
TimeSourceKey time_src_key;
|
|
|
|
|
add_relation(time_src_key, driver_key, "TimeSrc -> Driver");
|
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
|
|
|
}
|
2017-12-04 18:11:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_driver_data(ID *id, FCurve *fcu)
|
|
|
|
|
{
|
|
|
|
|
OperationKey driver_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::DRIVER,
|
2017-12-04 18:11:43 +01:00
|
|
|
fcu->rna_path ? fcu->rna_path : "",
|
|
|
|
|
fcu->array_index);
|
|
|
|
|
const char *rna_path = fcu->rna_path ? fcu->rna_path : "";
|
2017-12-04 18:08:29 +01:00
|
|
|
if (GS(id->name) == ID_AR && strstr(rna_path, "bones[")) {
|
2017-07-27 11:50:14 +02:00
|
|
|
/* Drivers on armature-level bone settings (i.e. bbone stuff),
|
2019-01-31 12:56:40 +01:00
|
|
|
* which will affect the evaluation of corresponding pose bones. */
|
|
|
|
|
IDNode *arm_node = graph_->find_id_node(id);
|
2017-05-11 16:28:21 +02:00
|
|
|
char *bone_name = BLI_str_quoted_substrN(rna_path, "bones[");
|
2017-07-27 11:50:14 +02:00
|
|
|
if (arm_node != NULL && bone_name != NULL) {
|
|
|
|
|
/* Find objects which use this, and make their eval callbacks
|
2019-01-31 12:56:40 +01:00
|
|
|
* depend on this. */
|
|
|
|
|
for (Relation *rel : arm_node->outlinks) {
|
|
|
|
|
IDNode *to_node = (IDNode *)rel->to;
|
2017-07-27 11:50:14 +02:00
|
|
|
/* We only care about objects with pose data which use this. */
|
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
|
|
|
if (GS(to_node->id_orig->name) == ID_OB) {
|
2017-11-23 11:42:06 +01:00
|
|
|
Object *object = (Object *)to_node->id_orig;
|
|
|
|
|
// NOTE: object->pose may be NULL
|
|
|
|
|
bPoseChannel *pchan = BKE_pose_channel_find_name(object->pose,
|
2017-07-27 11:50:14 +02:00
|
|
|
bone_name);
|
|
|
|
|
if (pchan != NULL) {
|
2017-11-23 11:39:28 +01:00
|
|
|
OperationKey bone_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::BONE,
|
2017-07-27 11:50:14 +02:00
|
|
|
pchan->name,
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationCode::BONE_LOCAL);
|
2017-07-27 11:50:14 +02:00
|
|
|
add_relation(driver_key,
|
|
|
|
|
bone_key,
|
2017-12-04 12:48:16 +01:00
|
|
|
"Arm Bone -> Driver -> Bone");
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-08-08 15:24:35 +02:00
|
|
|
/* Free temp data. */
|
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
|
|
|
MEM_freeN(bone_name);
|
|
|
|
|
bone_name = NULL;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
fprintf(stderr,
|
|
|
|
|
"Couldn't find armature bone name for driver path - '%s'\n",
|
2017-05-11 16:28:21 +02:00
|
|
|
rna_path);
|
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-11-15 12:12:08 +01:00
|
|
|
else if (rna_path != NULL && rna_path[0] != '\0') {
|
2019-01-31 10:18:39 +01:00
|
|
|
RNAPathKey property_entry_key(id, rna_path, RNAPointerSource::ENTRY);
|
|
|
|
|
if (RNA_pointer_is_null(&property_entry_key.ptr)) {
|
2018-11-15 12:12:08 +01:00
|
|
|
/* TODO(sergey): This would only mean that driver is broken.
|
|
|
|
|
* so we can't create relation anyway. However, we need to avoid
|
|
|
|
|
* adding drivers which are known to be buggy to a dependency
|
2019-01-31 10:18:39 +01:00
|
|
|
* graph, in order to save computational power. */
|
2018-11-15 12:12:08 +01:00
|
|
|
return;
|
|
|
|
|
}
|
2019-01-31 10:18:39 +01:00
|
|
|
add_relation(
|
|
|
|
|
driver_key, property_entry_key, "Driver -> Driven Property");
|
2018-01-24 11:00:37 +01:00
|
|
|
/* Similar to the case with f-curves, driver might drive a nested
|
|
|
|
|
* datablock, which means driver execution should wait for that
|
2019-01-31 10:18:39 +01:00
|
|
|
* datablock to be copied. */
|
2018-05-31 13:42:55 +02:00
|
|
|
{
|
2018-01-24 11:00:37 +01:00
|
|
|
PointerRNA id_ptr;
|
|
|
|
|
PointerRNA ptr;
|
|
|
|
|
RNA_id_pointer_create(id, &id_ptr);
|
|
|
|
|
if (RNA_path_resolve_full(&id_ptr, fcu->rna_path, &ptr, NULL, NULL)) {
|
|
|
|
|
if (id_ptr.id.data != ptr.id.data) {
|
|
|
|
|
ComponentKey cow_key((ID *)ptr.id.data,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::COPY_ON_WRITE);
|
2018-01-24 11:00:37 +01:00
|
|
|
add_relation(cow_key,
|
|
|
|
|
driver_key,
|
2019-01-30 13:31:44 +01:00
|
|
|
"Driven CoW -> Driver",
|
2019-01-31 12:56:40 +01:00
|
|
|
RELATION_CHECK_BEFORE_ADD);
|
2018-01-24 11:00:37 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-01-31 10:18:39 +01:00
|
|
|
if (property_entry_key.prop != NULL &&
|
|
|
|
|
RNA_property_is_idprop(property_entry_key.prop))
|
2018-11-15 12:12:08 +01:00
|
|
|
{
|
2019-01-31 10:18:39 +01:00
|
|
|
RNAPathKey property_exit_key(id, rna_path, RNAPointerSource::EXIT);
|
2018-11-15 12:12:08 +01:00
|
|
|
OperationKey parameters_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::PARAMETERS_EVAL);
|
2019-01-31 10:18:39 +01:00
|
|
|
add_relation(property_exit_key,
|
2018-11-15 12:12:08 +01:00
|
|
|
parameters_key,
|
2019-01-30 13:31:44 +01:00
|
|
|
"Driven Property -> Properties");
|
2018-03-02 15:50:28 +01:00
|
|
|
}
|
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
|
|
|
}
|
2017-12-04 17:01:02 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_driver_variables(ID *id, FCurve *fcu)
|
|
|
|
|
{
|
|
|
|
|
ChannelDriver *driver = fcu->driver;
|
|
|
|
|
OperationKey driver_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::DRIVER,
|
2017-12-04 17:01:02 +01:00
|
|
|
fcu->rna_path ? fcu->rna_path : "",
|
|
|
|
|
fcu->array_index);
|
|
|
|
|
const char *rna_path = fcu->rna_path ? fcu->rna_path : "";
|
2019-01-31 10:18:39 +01:00
|
|
|
const RNAPathKey self_key(id, rna_path, RNAPointerSource::ENTRY);
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (DriverVar *, dvar, &driver->variables) {
|
2017-08-08 15:24:35 +02:00
|
|
|
/* Only used targets. */
|
2018-11-30 15:08:47 +11:00
|
|
|
DRIVER_TARGETS_USED_LOOPER_BEGIN(dvar)
|
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
|
|
|
{
|
2017-08-08 15:24:35 +02:00
|
|
|
if (dtar->id == NULL) {
|
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
|
|
|
continue;
|
2017-08-08 15:24:35 +02:00
|
|
|
}
|
2018-05-04 14:27:50 +02:00
|
|
|
build_id(dtar->id);
|
2019-02-26 11:41:22 +01:00
|
|
|
build_driver_id_property(dtar->id, dtar->rna_path);
|
2018-07-20 15:13:48 +02:00
|
|
|
/* Initialize relations coming to proxy_from. */
|
|
|
|
|
Object *proxy_from = NULL;
|
|
|
|
|
if ((GS(dtar->id->name) == ID_OB) &&
|
|
|
|
|
(((Object *)dtar->id)->proxy_from != NULL))
|
|
|
|
|
{
|
|
|
|
|
proxy_from = ((Object *)dtar->id)->proxy_from;
|
|
|
|
|
build_id(&proxy_from->id);
|
|
|
|
|
}
|
2017-08-08 15:24:35 +02:00
|
|
|
/* Special handling for directly-named bones. */
|
2017-12-04 17:37:21 +01:00
|
|
|
if ((dtar->flag & DTAR_FLAG_STRUCT_REF) &&
|
|
|
|
|
(((Object *)dtar->id)->type == OB_ARMATURE) &&
|
|
|
|
|
(dtar->pchan_name[0]))
|
|
|
|
|
{
|
2017-11-23 11:39:28 +01:00
|
|
|
Object *object = (Object *)dtar->id;
|
2017-08-08 15:24:35 +02:00
|
|
|
bPoseChannel *target_pchan =
|
2017-12-04 16:51:29 +01:00
|
|
|
BKE_pose_channel_find_name(object->pose,
|
|
|
|
|
dtar->pchan_name);
|
|
|
|
|
if (target_pchan == NULL) {
|
|
|
|
|
continue;
|
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
|
|
|
}
|
2017-12-04 16:51:29 +01:00
|
|
|
OperationKey variable_key(dtar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::BONE,
|
2018-01-16 11:40:02 +01:00
|
|
|
target_pchan->name,
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationCode::BONE_DONE);
|
2017-12-04 16:51:29 +01:00
|
|
|
if (is_same_bone_dependency(variable_key, self_key)) {
|
|
|
|
|
continue;
|
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
|
|
|
}
|
2017-12-04 16:51:29 +01:00
|
|
|
add_relation(variable_key, driver_key, "Bone Target -> Driver");
|
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
|
|
|
}
|
|
|
|
|
else if (dtar->flag & DTAR_FLAG_STRUCT_REF) {
|
2017-08-08 15:24:35 +02:00
|
|
|
/* Get node associated with the object's transforms. */
|
2017-08-08 15:27:11 +02:00
|
|
|
if (dtar->id == id) {
|
|
|
|
|
/* Ignore input dependency if we're driving properties of
|
|
|
|
|
* the same ID, otherwise we'll be ending up in a cyclic
|
2019-01-31 12:56:40 +01:00
|
|
|
* dependency here. */
|
2017-08-08 15:27:11 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
2017-08-08 15:24:35 +02:00
|
|
|
OperationKey target_key(dtar->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_FINAL);
|
2017-12-04 12:48:16 +01:00
|
|
|
add_relation(target_key, driver_key, "Target -> Driver");
|
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-11-15 12:12:08 +01:00
|
|
|
else if (dtar->rna_path != NULL && dtar->rna_path[0] != '\0') {
|
2019-01-31 10:18:39 +01:00
|
|
|
RNAPathKey variable_exit_key(
|
|
|
|
|
dtar->id, dtar->rna_path, RNAPointerSource::EXIT);
|
|
|
|
|
if (RNA_pointer_is_null(&variable_exit_key.ptr)) {
|
2017-12-04 16:44:07 +01:00
|
|
|
continue;
|
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-01-31 10:18:39 +01:00
|
|
|
if (is_same_bone_dependency(variable_exit_key, self_key) ||
|
2019-01-31 10:40:38 +01:00
|
|
|
is_same_nodetree_node_dependency(variable_exit_key, self_key))
|
2018-01-16 11:53:34 +01:00
|
|
|
{
|
2017-12-04 16:44:07 +01:00
|
|
|
continue;
|
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-01-31 10:18:39 +01:00
|
|
|
add_relation(variable_exit_key,
|
|
|
|
|
driver_key,
|
|
|
|
|
"RNA Target -> Driver");
|
2018-07-20 15:13:48 +02:00
|
|
|
if (proxy_from != NULL) {
|
|
|
|
|
RNAPathKey proxy_from_variable_key(&proxy_from->id,
|
2019-01-31 10:18:39 +01:00
|
|
|
dtar->rna_path,
|
|
|
|
|
RNAPointerSource::EXIT);
|
|
|
|
|
RNAPathKey variable_entry_key(
|
|
|
|
|
dtar->id, dtar->rna_path, RNAPointerSource::ENTRY);
|
2018-07-20 15:13:48 +02:00
|
|
|
add_relation(proxy_from_variable_key,
|
2019-01-31 10:18:39 +01:00
|
|
|
variable_entry_key,
|
2018-07-20 15:13:48 +02:00
|
|
|
"Proxy From -> Variable");
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
else {
|
2018-11-14 20:16:55 +03:00
|
|
|
/* If rna_path is NULL, and DTAR_FLAG_STRUCT_REF isn't set, this
|
|
|
|
|
* is an incomplete target reference, so nothing to do here. */
|
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-11-30 15:08:47 +11:00
|
|
|
DRIVER_TARGETS_LOOPER_END;
|
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-02-26 11:41:22 +01:00
|
|
|
void DepsgraphRelationBuilder::build_driver_id_property(ID *id,
|
|
|
|
|
const char *rna_path)
|
|
|
|
|
{
|
|
|
|
|
if (id == NULL || rna_path == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
PointerRNA id_ptr, ptr;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
RNA_id_pointer_create(id, &id_ptr);
|
|
|
|
|
if (!RNA_path_resolve_full(&id_ptr, rna_path, &ptr, &prop, NULL)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (prop == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (!RNA_property_is_idprop(prop)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
const char *prop_identifier = RNA_property_identifier((PropertyRNA *)prop);
|
|
|
|
|
OperationKey id_property_key(id,
|
|
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::ID_PROPERTY,
|
|
|
|
|
prop_identifier);
|
|
|
|
|
OperationKey parameters_exit_key(id,
|
|
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::PARAMETERS_EXIT);
|
|
|
|
|
add_relation(id_property_key,
|
|
|
|
|
parameters_exit_key,
|
|
|
|
|
"ID Property -> Done",
|
|
|
|
|
RELATION_CHECK_BEFORE_ADD);
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-20 11:48:42 +01:00
|
|
|
void DepsgraphRelationBuilder::build_parameters(ID *id)
|
|
|
|
|
{
|
|
|
|
|
OperationKey parameters_entry_key(
|
|
|
|
|
id, NodeType::PARAMETERS, OperationCode::PARAMETERS_ENTRY);
|
|
|
|
|
OperationKey parameters_eval_key(
|
|
|
|
|
id, NodeType::PARAMETERS, OperationCode::PARAMETERS_EVAL);
|
|
|
|
|
OperationKey parameters_exit_key(
|
|
|
|
|
id, NodeType::PARAMETERS, OperationCode::PARAMETERS_EXIT);
|
|
|
|
|
add_relation(
|
|
|
|
|
parameters_entry_key, parameters_eval_key, "Entry -> Eval");
|
|
|
|
|
add_relation(
|
|
|
|
|
parameters_eval_key, parameters_exit_key, "Entry -> Exit");
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
void DepsgraphRelationBuilder::build_world(World *world)
|
|
|
|
|
{
|
2018-02-22 11:03:39 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(world)) {
|
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;
|
|
|
|
|
}
|
2018-11-08 15:56:56 +01:00
|
|
|
/* animation */
|
2018-02-22 11:03:39 +01:00
|
|
|
build_animdata(&world->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
|
|
|
/* world's nodetree */
|
2017-05-10 10:31:33 +02:00
|
|
|
if (world->nodetree != NULL) {
|
|
|
|
|
build_nodetree(world->nodetree);
|
2018-11-08 15:56:56 +01:00
|
|
|
OperationKey ntree_key(&world->nodetree->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::MATERIAL_UPDATE);
|
2018-11-08 15:56:56 +01:00
|
|
|
OperationKey world_key(&world->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::WORLD_UPDATE);
|
2018-11-08 15:56:56 +01:00
|
|
|
add_relation(ntree_key, world_key, "World's NTree");
|
2018-05-01 12:41:10 +02:00
|
|
|
build_nested_nodetree(&world->id, world->nodetree);
|
2017-05-10 10:31:33 +02:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_rigidbody(Scene *scene)
|
|
|
|
|
{
|
|
|
|
|
RigidBodyWorld *rbw = scene->rigidbody_world;
|
2019-02-12 12:32:03 +01:00
|
|
|
OperationKey rb_init_key(&scene->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::RIGIDBODY_REBUILD);
|
|
|
|
|
OperationKey rb_simulate_key(&scene->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::RIGIDBODY_SIM);
|
|
|
|
|
/* Simulation depends on time. */
|
|
|
|
|
TimeSourceKey time_src_key;
|
|
|
|
|
add_relation(time_src_key, rb_init_key, "TimeSrc -> Rigidbody Init");
|
|
|
|
|
/* Simulation should always be run after initialization. */
|
|
|
|
|
/* NOTE: It is possible in theory to have dependency cycle which involves
|
|
|
|
|
* this relation. We never want it to be killed. */
|
|
|
|
|
add_relation(rb_init_key,
|
|
|
|
|
rb_simulate_key,
|
|
|
|
|
"Rigidbody [Init -> SimStep]",
|
|
|
|
|
RELATION_FLAG_GODMODE);
|
|
|
|
|
/* Effectors should be evaluated at the time simulation is being
|
|
|
|
|
* initialized.
|
|
|
|
|
* TODO(sergey): Verify that it indeed goes to initialization and not to a
|
|
|
|
|
* simulation. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ListBase *relations = build_effector_relations(graph_, rbw->effector_weights->group);
|
2018-12-13 11:54:18 +01:00
|
|
|
LISTBASE_FOREACH (EffectorRelation *, relation, relations) {
|
2019-02-12 12:32:03 +01:00
|
|
|
ComponentKey effector_transform_key(
|
|
|
|
|
&relation->ob->id, NodeType::TRANSFORM);
|
|
|
|
|
add_relation(effector_transform_key, rb_init_key, "RigidBody Field");
|
2018-12-13 11:54:18 +01:00
|
|
|
}
|
2019-02-12 12:32:03 +01:00
|
|
|
/* Objects. */
|
2019-01-28 16:38:12 +01:00
|
|
|
if (rbw->group != NULL) {
|
2018-11-14 16:50:59 +01:00
|
|
|
build_collection(NULL, NULL, rbw->group);
|
2018-06-08 19:26:46 +02:00
|
|
|
FOREACH_COLLECTION_OBJECT_RECURSIVE_BEGIN(rbw->group, object)
|
|
|
|
|
{
|
|
|
|
|
if (object->type != OB_MESH) {
|
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
|
|
|
continue;
|
2016-11-17 15:11:55 +01:00
|
|
|
}
|
2019-02-12 12:32:03 +01:00
|
|
|
OperationKey rb_transform_copy_key(
|
|
|
|
|
&object->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::RIGIDBODY_TRANSFORM_COPY);
|
|
|
|
|
/* Rigid body synchronization depends on the actual simulation. */
|
|
|
|
|
add_relation(rb_simulate_key,
|
|
|
|
|
rb_transform_copy_key,
|
|
|
|
|
"Rigidbody Sim Eval -> RBO Sync");
|
|
|
|
|
/* Simulation uses object transformation after parenting and solving
|
|
|
|
|
* contraints. */
|
|
|
|
|
OperationKey object_transform_eval_key(
|
|
|
|
|
&object->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_EVAL);
|
|
|
|
|
add_relation(object_transform_eval_key,
|
|
|
|
|
rb_simulate_key,
|
|
|
|
|
"Object Transform -> Rigidbody Sim Eval");
|
|
|
|
|
/* Geometry must be known to create the rigid body. RBO_MESH_BASE
|
|
|
|
|
* uses the non-evaluated mesh, so then the evaluation is
|
|
|
|
|
* unnecessary. */
|
|
|
|
|
if (object->rigidbody_object != NULL &&
|
|
|
|
|
object->rigidbody_object->mesh_source != RBO_MESH_BASE)
|
|
|
|
|
{
|
|
|
|
|
/* NOTE: We prefer this relation to be never killed, to avoid
|
|
|
|
|
* access partially evaluated mesh from solver. */
|
|
|
|
|
ComponentKey object_geometry_key(
|
|
|
|
|
&object->id, NodeType::GEOMETRY);
|
|
|
|
|
add_relation(object_geometry_key,
|
|
|
|
|
rb_simulate_key,
|
|
|
|
|
"Object Geom Eval -> Rigidbody Rebuild",
|
|
|
|
|
RELATION_FLAG_GODMODE);
|
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-02-12 12:32:03 +01:00
|
|
|
/* Final transform is whetever solver gave to us. */
|
|
|
|
|
OperationKey object_transform_final_key(
|
|
|
|
|
&object->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::TRANSFORM_FINAL);
|
|
|
|
|
add_relation(rb_transform_copy_key,
|
|
|
|
|
object_transform_final_key,
|
|
|
|
|
"Rigidbody Sync -> Transform Final");
|
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-06-08 19:26:46 +02:00
|
|
|
FOREACH_COLLECTION_OBJECT_RECURSIVE_END;
|
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-01-28 16:38:12 +01:00
|
|
|
/* Constraints. */
|
|
|
|
|
if (rbw->constraints != NULL) {
|
2018-06-08 19:26:46 +02:00
|
|
|
FOREACH_COLLECTION_OBJECT_RECURSIVE_BEGIN(rbw->constraints, object)
|
|
|
|
|
{
|
2018-06-28 14:04:51 +02:00
|
|
|
RigidBodyCon *rbc = object->rigidbody_constraint;
|
|
|
|
|
if (rbc == NULL || rbc->ob1 == NULL || rbc->ob2 == NULL) {
|
2019-02-12 12:32:03 +01:00
|
|
|
/* When either ob1 or ob2 is NULL, the constraint doesn't
|
|
|
|
|
* work. */
|
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
|
|
|
continue;
|
2016-11-17 15:11:55 +01:00
|
|
|
}
|
2019-01-28 16:38:12 +01:00
|
|
|
/* Make sure indirectly linked objects are fully built. */
|
|
|
|
|
build_object(NULL, object);
|
|
|
|
|
build_object(NULL, rbc->ob1);
|
|
|
|
|
build_object(NULL, rbc->ob2);
|
|
|
|
|
/* final result of the constraint object's transform controls how
|
|
|
|
|
* the constraint affects the physics sim for these objects. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey trans_key(&object->id, NodeType::TRANSFORM);
|
2019-02-12 12:32:03 +01:00
|
|
|
OperationKey ob1_key(&rbc->ob1->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::RIGIDBODY_TRANSFORM_COPY);
|
|
|
|
|
OperationKey ob2_key(&rbc->ob2->id,
|
|
|
|
|
NodeType::TRANSFORM,
|
|
|
|
|
OperationCode::RIGIDBODY_TRANSFORM_COPY);
|
2019-01-28 16:38:12 +01:00
|
|
|
/* Constrained-objects sync depends on the constraint-holder. */
|
2019-02-12 12:32:03 +01:00
|
|
|
add_relation(
|
|
|
|
|
trans_key, ob1_key, "RigidBodyConstraint -> RBC.Object_1");
|
|
|
|
|
add_relation(
|
|
|
|
|
trans_key, ob2_key, "RigidBodyConstraint -> RBC.Object_2");
|
2019-01-28 16:38:12 +01:00
|
|
|
/* Ensure that sim depends on this constraint's transform. */
|
2019-02-12 12:32:03 +01:00
|
|
|
add_relation(trans_key,
|
|
|
|
|
rb_simulate_key,
|
|
|
|
|
"RigidBodyConstraint Transform -> RB Simulation");
|
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-06-08 19:26:46 +02:00
|
|
|
FOREACH_COLLECTION_OBJECT_RECURSIVE_END;
|
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-12-10 15:09:46 +01:00
|
|
|
void DepsgraphRelationBuilder::build_particle_systems(Object *object)
|
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
|
|
|
{
|
2015-05-27 19:22:23 +05:00
|
|
|
TimeSourceKey time_src_key;
|
2017-11-23 11:39:28 +01:00
|
|
|
OperationKey obdata_ubereval_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY,
|
2019-02-01 10:30:04 +01:00
|
|
|
OperationCode::GEOMETRY_EVAL);
|
2017-11-23 11:39:28 +01:00
|
|
|
OperationKey eval_init_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SYSTEM,
|
|
|
|
|
OperationCode::PARTICLE_SYSTEM_INIT);
|
2018-12-10 15:09:46 +01:00
|
|
|
OperationKey eval_done_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SYSTEM,
|
|
|
|
|
OperationCode::PARTICLE_SYSTEM_DONE);
|
|
|
|
|
ComponentKey eval_key(&object->id, NodeType::PARTICLE_SYSTEM);
|
2018-12-19 15:36:09 +01:00
|
|
|
if (BKE_ptcache_object_has(scene_, object, 0)) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey point_cache_key(&object->id, NodeType::POINT_CACHE);
|
2019-01-31 16:53:19 +01:00
|
|
|
add_relation(eval_key,
|
|
|
|
|
point_cache_key,
|
|
|
|
|
"Particle Point Cache",
|
|
|
|
|
RELATION_FLAG_FLUSH_USER_EDIT_ONLY);
|
2018-12-19 15:36:09 +01:00
|
|
|
}
|
2018-02-02 12:00:25 +01:00
|
|
|
/* Particle systems. */
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (ParticleSystem *, psys, &object->particlesystem) {
|
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
|
|
|
ParticleSettings *part = psys->part;
|
2017-07-18 12:12:15 +02:00
|
|
|
/* Build particle settings relations.
|
2019-01-29 10:16:16 +01:00
|
|
|
* NOTE: The call itself ensures settings are only build once. */
|
2017-07-18 12:12:15 +02:00
|
|
|
build_particle_settings(part);
|
|
|
|
|
/* This particle system. */
|
2017-11-23 11:42:06 +01:00
|
|
|
OperationKey psys_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SYSTEM,
|
|
|
|
|
OperationCode::PARTICLE_SYSTEM_EVAL,
|
2017-07-18 12:12:15 +02:00
|
|
|
psys->name);
|
|
|
|
|
/* Update particle system when settings changes. */
|
|
|
|
|
OperationKey particle_settings_key(&part->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SETTINGS,
|
|
|
|
|
OperationCode::PARTICLE_SETTINGS_EVAL);
|
2019-01-29 10:16:16 +01:00
|
|
|
add_relation(particle_settings_key,
|
|
|
|
|
eval_init_key,
|
|
|
|
|
"Particle Settings Change");
|
2017-07-21 11:12:34 +02:00
|
|
|
add_relation(eval_init_key, psys_key, "Init -> PSys");
|
2018-12-10 15:09:46 +01:00
|
|
|
add_relation(psys_key, eval_done_key, "PSys -> Done");
|
2015-05-27 19:22:23 +05:00
|
|
|
/* TODO(sergey): Currently particle update is just a placeholder,
|
|
|
|
|
* hook it to the ubereval node so particle system is getting updated
|
2019-01-29 10:16:16 +01:00
|
|
|
* on playback. */
|
2017-06-01 16:20:48 +02:00
|
|
|
add_relation(psys_key, obdata_ubereval_key, "PSys -> UberEval");
|
2019-01-29 10:16:16 +01:00
|
|
|
/* Collisions. */
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
|
|
|
if (part->type != PART_HAIR) {
|
2019-01-22 15:17:34 +01:00
|
|
|
add_particle_collision_relations(psys_key,
|
|
|
|
|
object,
|
|
|
|
|
part->collision_group,
|
|
|
|
|
"Particle Collision");
|
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
|
|
|
}
|
2017-07-20 15:38:48 +02:00
|
|
|
else if ((psys->flag & PSYS_HAIR_DYNAMICS) &&
|
2019-01-29 10:16:16 +01:00
|
|
|
psys->clmd != NULL &&
|
|
|
|
|
psys->clmd->coll_parms != NULL)
|
2017-10-07 15:57:14 +11:00
|
|
|
{
|
2019-01-22 15:17:34 +01:00
|
|
|
add_particle_collision_relations(psys_key,
|
|
|
|
|
object,
|
|
|
|
|
psys->clmd->coll_parms->group,
|
|
|
|
|
"Hair Collision");
|
2016-12-05 13:35:24 +03:00
|
|
|
}
|
2018-02-02 12:00:25 +01:00
|
|
|
/* Effectors. */
|
2019-01-22 15:17:34 +01:00
|
|
|
add_particle_forcefield_relations(psys_key,
|
|
|
|
|
object,
|
|
|
|
|
psys,
|
|
|
|
|
part->effector_weights,
|
|
|
|
|
part->type == PART_HAIR,
|
|
|
|
|
"Particle Field");
|
2018-02-02 12:21:24 +01:00
|
|
|
/* Boids .*/
|
2019-01-29 10:16:16 +01:00
|
|
|
if (part->boids != NULL) {
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (BoidState *, state, &part->boids->states) {
|
|
|
|
|
LISTBASE_FOREACH (BoidRule *, rule, &state->rules) {
|
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
|
|
|
Object *ruleob = NULL;
|
2018-02-02 12:00:25 +01:00
|
|
|
if (rule->type == eBoidRuleType_Avoid) {
|
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
|
|
|
ruleob = ((BoidRuleGoalAvoid *)rule)->ob;
|
2018-02-02 12:00:25 +01:00
|
|
|
}
|
|
|
|
|
else if (rule->type == eBoidRuleType_FollowLeader) {
|
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
|
|
|
ruleob = ((BoidRuleFollowLeader *)rule)->ob;
|
2018-02-02 12:00:25 +01:00
|
|
|
}
|
2019-01-29 10:16:16 +01:00
|
|
|
if (ruleob != NULL) {
|
2018-02-02 12:00:25 +01:00
|
|
|
ComponentKey ruleob_key(&ruleob->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(ruleob_key, psys_key, "Boid Rule");
|
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-01-29 10:16:16 +01:00
|
|
|
/* Keyed particle targets. */
|
|
|
|
|
if (part->phystype == PART_PHYS_KEYED) {
|
|
|
|
|
LISTBASE_FOREACH (ParticleTarget *, particle_target, &psys->targets) {
|
|
|
|
|
if (particle_target->ob == NULL ||
|
|
|
|
|
particle_target->ob == object)
|
|
|
|
|
{
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
/* Make sure target object is pulled into the graph. */
|
|
|
|
|
build_object(NULL, particle_target->ob);
|
|
|
|
|
/* Use geometry component, since that's where particles are
|
|
|
|
|
* actually evaluated. */
|
|
|
|
|
ComponentKey target_key(&particle_target->ob->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY);
|
2019-01-29 10:16:16 +01:00
|
|
|
add_relation(target_key, psys_key, "Keyed Target");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* Visualization. */
|
2018-02-02 12:00:25 +01:00
|
|
|
switch (part->ren_as) {
|
|
|
|
|
case PART_DRAW_OB:
|
2019-02-17 19:00:54 +11:00
|
|
|
if (part->instance_object != NULL) {
|
2018-02-02 12:00:25 +01:00
|
|
|
/* Make sure object's relations are all built. */
|
2019-02-17 19:00:54 +11:00
|
|
|
build_object(NULL, part->instance_object);
|
2018-02-02 12:00:25 +01:00
|
|
|
/* Build relation for the particle visualization. */
|
2018-12-10 15:09:46 +01:00
|
|
|
build_particle_system_visualization_object(
|
2019-02-17 19:00:54 +11:00
|
|
|
object, psys, part->instance_object);
|
2018-02-02 12:00:25 +01:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case PART_DRAW_GR:
|
2019-02-17 19:00:54 +11:00
|
|
|
if (part->instance_collection != NULL) {
|
|
|
|
|
build_collection(NULL, NULL, part->instance_collection);
|
|
|
|
|
LISTBASE_FOREACH (CollectionObject *, go, &part->instance_collection->gobject) {
|
2018-12-10 15:09:46 +01:00
|
|
|
build_particle_system_visualization_object(
|
|
|
|
|
object, psys, go->ob);
|
2018-02-02 12:00:25 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
2016-02-02 15:43:20 +01:00
|
|
|
}
|
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
|
|
|
}
|
2016-02-02 15:43:20 +01:00
|
|
|
/* Particle depends on the object transform, so that channel is to be ready
|
|
|
|
|
* first.
|
|
|
|
|
*
|
|
|
|
|
* TODO(sergey): This relation should be altered once real granular update
|
2019-01-29 10:16:16 +01:00
|
|
|
* is implemented. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey transform_key(&object->id, NodeType::TRANSFORM);
|
2018-12-10 15:09:46 +01:00
|
|
|
add_relation(transform_key, obdata_ubereval_key, "Particle Eval");
|
2017-07-18 12:12:15 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_particle_settings(ParticleSettings *part)
|
|
|
|
|
{
|
2018-02-22 11:20:28 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(part)) {
|
2017-07-18 12:12:15 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
/* Animation data relations. */
|
|
|
|
|
build_animdata(&part->id);
|
2018-12-10 15:09:46 +01:00
|
|
|
OperationKey particle_settings_init_key(&part->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SETTINGS,
|
|
|
|
|
OperationCode::PARTICLE_SETTINGS_INIT);
|
2018-12-10 15:09:46 +01:00
|
|
|
OperationKey particle_settings_eval_key(&part->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SETTINGS,
|
|
|
|
|
OperationCode::PARTICLE_SETTINGS_EVAL);
|
2018-12-10 15:09:46 +01:00
|
|
|
OperationKey particle_settings_reset_key(
|
|
|
|
|
&part->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SETTINGS,
|
|
|
|
|
OperationCode::PARTICLE_SETTINGS_RESET);
|
2018-12-10 15:09:46 +01:00
|
|
|
add_relation(particle_settings_init_key,
|
|
|
|
|
particle_settings_eval_key,
|
|
|
|
|
"Particle Settings Init Order");
|
|
|
|
|
add_relation(particle_settings_reset_key,
|
|
|
|
|
particle_settings_eval_key,
|
|
|
|
|
"Particle Settings Reset");
|
|
|
|
|
/* Texture slots. */
|
|
|
|
|
for (int mtex_index = 0; mtex_index < MAX_MTEX; ++mtex_index) {
|
|
|
|
|
MTex *mtex = part->mtex[mtex_index];
|
|
|
|
|
if (mtex == NULL || mtex->tex == NULL) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
build_texture(mtex->tex);
|
|
|
|
|
ComponentKey texture_key(&mtex->tex->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GENERIC_DATABLOCK);
|
2018-12-10 15:09:46 +01:00
|
|
|
add_relation(texture_key,
|
|
|
|
|
particle_settings_reset_key,
|
|
|
|
|
"Particle Texture",
|
2019-01-31 12:56:40 +01:00
|
|
|
RELATION_FLAG_FLUSH_USER_EDIT_ONLY);
|
2019-01-28 12:17:54 +01:00
|
|
|
/* TODO(sergey): Consider moving texture space handling to an own
|
|
|
|
|
* function. */
|
|
|
|
|
if (mtex->texco == TEXCO_OBJECT && mtex->object != NULL) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey object_key(&mtex->object->id, NodeType::TRANSFORM);
|
2019-01-28 12:17:54 +01:00
|
|
|
add_relation(object_key,
|
|
|
|
|
particle_settings_eval_key,
|
|
|
|
|
"Particle Texture Space");
|
|
|
|
|
}
|
2018-12-10 15:09:46 +01:00
|
|
|
}
|
2018-12-10 17:37:30 +01:00
|
|
|
if (check_id_has_anim_component(&part->id)) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey animation_key(&part->id, NodeType::ANIMATION);
|
2018-12-10 17:37:30 +01:00
|
|
|
add_relation(animation_key,
|
|
|
|
|
particle_settings_eval_key,
|
|
|
|
|
"Particle Settings Animation");
|
|
|
|
|
}
|
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-12-10 15:09:46 +01:00
|
|
|
void DepsgraphRelationBuilder::build_particle_system_visualization_object(
|
2018-02-02 12:00:25 +01:00
|
|
|
Object *object,
|
|
|
|
|
ParticleSystem *psys,
|
|
|
|
|
Object *draw_object)
|
|
|
|
|
{
|
|
|
|
|
OperationKey psys_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARTICLE_SYSTEM,
|
|
|
|
|
OperationCode::PARTICLE_SYSTEM_EVAL,
|
2018-02-02 12:00:25 +01:00
|
|
|
psys->name);
|
|
|
|
|
OperationKey obdata_ubereval_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY,
|
2019-02-01 10:30:04 +01:00
|
|
|
OperationCode::GEOMETRY_EVAL);
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey dup_ob_key(&draw_object->id, NodeType::TRANSFORM);
|
2018-02-02 12:00:25 +01:00
|
|
|
add_relation(dup_ob_key, psys_key, "Particle Object Visualization");
|
|
|
|
|
if (draw_object->type == OB_MBALL) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey dup_geometry_key(&draw_object->id, NodeType::GEOMETRY);
|
2018-02-02 12:00:25 +01:00
|
|
|
add_relation(obdata_ubereval_key,
|
|
|
|
|
dup_geometry_key,
|
|
|
|
|
"Particle MBall Visualization");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* Shapekeys */
|
2018-06-06 11:53:04 +02:00
|
|
|
void DepsgraphRelationBuilder::build_shapekeys(Key *key)
|
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-06-06 11:53:04 +02:00
|
|
|
if (built_map_.checkIsBuiltAndTag(key)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2019-01-31 10:40:38 +01:00
|
|
|
/* Attach animdata to geometry. */
|
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
|
|
|
build_animdata(&key->id);
|
2019-01-31 10:40:38 +01:00
|
|
|
/* Connect all blocks properties to the final result evaluation. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey geometry_key(&key->id, NodeType::GEOMETRY);
|
2019-01-31 10:40:38 +01:00
|
|
|
LISTBASE_FOREACH (KeyBlock *, key_block, &key->block) {
|
|
|
|
|
OperationKey key_block_key(&key->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::PARAMETERS,
|
|
|
|
|
OperationCode::PARAMETERS_EVAL,
|
2019-01-31 10:40:38 +01:00
|
|
|
key_block->name);
|
|
|
|
|
add_relation(key_block_key, geometry_key, "Key Block Properties");
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ObData Geometry Evaluation
|
|
|
|
|
* ==========================
|
|
|
|
|
*
|
|
|
|
|
* The evaluation of geometry on objects is as follows:
|
2018-09-27 15:54:10 +02:00
|
|
|
* - The actual evaluated of the derived geometry (e.g. Mesh, DispList)
|
2018-06-06 11:22:20 +02:00
|
|
|
* occurs in the Geometry component of the object which references this.
|
|
|
|
|
* This includes modifiers, and the temporary "ubereval" for geometry.
|
|
|
|
|
* Therefore, each user of a piece of shared geometry data ends up evaluating
|
|
|
|
|
* its own version of the stuff, complete with whatever modifiers it may use.
|
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-06-06 11:22:20 +02:00
|
|
|
* - The datablocks for the geometry data - "obdata" (e.g. ID_ME, ID_CU, ID_LT.)
|
|
|
|
|
* are used for
|
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
|
|
|
* 1) calculating the bounding boxes of the geometry data,
|
2018-06-06 11:22:20 +02:00
|
|
|
* 2) aggregating inward links from other objects (e.g. for text on curve)
|
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
|
|
|
* and also for the links coming from the shapekey datablocks
|
2018-06-06 11:22:20 +02:00
|
|
|
* - Animation/Drivers affecting the parameters of the geometry are made to
|
|
|
|
|
* trigger updates on the obdata geometry component, which then trigger
|
2019-02-01 10:37:14 +01:00
|
|
|
* downstream re-evaluation of the individual instances of this geometry. */
|
2018-06-06 11:22:20 +02:00
|
|
|
void DepsgraphRelationBuilder::build_object_data_geometry(Object *object)
|
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
|
|
|
{
|
2017-11-23 11:39:28 +01:00
|
|
|
ID *obdata = (ID *)object->data;
|
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
|
|
|
/* Init operation of object-level geometry evaluation. */
|
2018-06-06 11:22:20 +02:00
|
|
|
OperationKey geom_init_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY,
|
2019-02-01 10:37:14 +01:00
|
|
|
OperationCode::GEOMETRY_EVAL_INIT);
|
2018-06-06 11:22:20 +02:00
|
|
|
/* Get nodes for result of obdata's evaluation, and geometry evaluation
|
2019-01-31 12:56:40 +01:00
|
|
|
* on object. */
|
|
|
|
|
ComponentKey obdata_geom_key(obdata, NodeType::GEOMETRY);
|
|
|
|
|
ComponentKey geom_key(&object->id, NodeType::GEOMETRY);
|
2018-06-06 11:22:20 +02:00
|
|
|
/* Link components to each other. */
|
2017-06-01 14:49:17 +02:00
|
|
|
add_relation(obdata_geom_key, geom_key, "Object Geometry Base Data");
|
2017-11-23 11:42:06 +01:00
|
|
|
OperationKey obdata_ubereval_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY,
|
2019-02-01 10:30:04 +01:00
|
|
|
OperationCode::GEOMETRY_EVAL);
|
2018-06-06 11:22:20 +02:00
|
|
|
/* Special case: modifiers evaluation queries scene for various things like
|
|
|
|
|
* data mask to be used. We add relation here to ensure object is never
|
2019-01-31 12:56:40 +01:00
|
|
|
* evaluated prior to Scene's CoW is ready. */
|
2017-11-09 10:59:15 +01:00
|
|
|
OperationKey scene_key(&scene_->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::LAYER_COLLECTIONS,
|
|
|
|
|
OperationCode::VIEW_LAYER_EVAL);
|
|
|
|
|
Relation *rel = add_relation(scene_key, obdata_ubereval_key, "CoW Relation");
|
|
|
|
|
rel->flag |= RELATION_FLAG_NO_FLUSH;
|
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
|
|
|
/* Modifiers */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->modifiers.first != NULL) {
|
2018-02-22 12:54:06 +01:00
|
|
|
ModifierUpdateDepsgraphContext ctx = {};
|
|
|
|
|
ctx.scene = scene_;
|
|
|
|
|
ctx.object = object;
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (ModifierData *, md, &object->modifiers) {
|
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
|
|
|
const ModifierTypeInfo *mti = modifierType_getInfo((ModifierType)md->type);
|
|
|
|
|
if (mti->updateDepsgraph) {
|
2017-06-07 14:08:11 +02:00
|
|
|
DepsNodeHandle handle = create_node_handle(obdata_ubereval_key);
|
2018-02-22 12:54:06 +01:00
|
|
|
ctx.node = reinterpret_cast< ::DepsNodeHandle* >(&handle);
|
|
|
|
|
mti->updateDepsgraph(md, &ctx);
|
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
|
|
|
}
|
2017-11-23 11:39:28 +01:00
|
|
|
if (BKE_object_modifier_use_time(object, md)) {
|
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
|
|
|
TimeSourceKey time_src_key;
|
2017-06-07 14:08:11 +02:00
|
|
|
add_relation(time_src_key, obdata_ubereval_key, "Time Source");
|
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-02-01 10:37:14 +01:00
|
|
|
/* Grease Pencil Modifiers. */
|
2018-07-31 10:22:19 +02:00
|
|
|
if (object->greasepencil_modifiers.first != NULL) {
|
|
|
|
|
ModifierUpdateDepsgraphContext ctx = {};
|
|
|
|
|
ctx.scene = scene_;
|
|
|
|
|
ctx.object = object;
|
2019-02-01 10:24:12 +01:00
|
|
|
LISTBASE_FOREACH (GpencilModifierData *, md, &object->greasepencil_modifiers) {
|
2018-07-31 10:22:19 +02:00
|
|
|
const GpencilModifierTypeInfo *mti = BKE_gpencil_modifierType_getInfo((GpencilModifierType)md->type);
|
|
|
|
|
if (mti->updateDepsgraph) {
|
|
|
|
|
DepsNodeHandle handle = create_node_handle(obdata_ubereval_key);
|
|
|
|
|
ctx.node = reinterpret_cast< ::DepsNodeHandle* >(&handle);
|
|
|
|
|
mti->updateDepsgraph(md, &ctx);
|
|
|
|
|
}
|
|
|
|
|
if (BKE_object_modifier_gpencil_use_time(object, md)) {
|
|
|
|
|
TimeSourceKey time_src_key;
|
|
|
|
|
add_relation(time_src_key, obdata_ubereval_key, "Time Source");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-02-01 10:37:14 +01:00
|
|
|
/* Shader FX. */
|
2018-07-31 10:22:19 +02:00
|
|
|
if (object->shader_fx.first != NULL) {
|
|
|
|
|
ModifierUpdateDepsgraphContext ctx = {};
|
|
|
|
|
ctx.scene = scene_;
|
|
|
|
|
ctx.object = object;
|
2019-02-01 10:24:12 +01:00
|
|
|
LISTBASE_FOREACH (ShaderFxData *, fx, &object->shader_fx) {
|
2018-07-31 10:22:19 +02:00
|
|
|
const ShaderFxTypeInfo *fxi = BKE_shaderfxType_getInfo((ShaderFxType)fx->type);
|
|
|
|
|
if (fxi->updateDepsgraph) {
|
|
|
|
|
DepsNodeHandle handle = create_node_handle(obdata_ubereval_key);
|
|
|
|
|
ctx.node = reinterpret_cast< ::DepsNodeHandle* >(&handle);
|
|
|
|
|
fxi->updateDepsgraph(fx, &ctx);
|
|
|
|
|
}
|
|
|
|
|
if (BKE_object_shaderfx_use_time(object, fx)) {
|
|
|
|
|
TimeSourceKey time_src_key;
|
|
|
|
|
add_relation(time_src_key, obdata_ubereval_key, "Time Source");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-06-06 11:22:20 +02:00
|
|
|
/* Materials. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->totcol) {
|
|
|
|
|
for (int a = 1; a <= object->totcol; a++) {
|
|
|
|
|
Material *ma = give_current_material(object, a);
|
2017-01-26 16:35:23 +01:00
|
|
|
if (ma != NULL) {
|
|
|
|
|
build_material(ma);
|
2017-07-10 14:43:57 +02:00
|
|
|
|
2017-11-23 11:42:06 +01:00
|
|
|
if (object->type == OB_MESH) {
|
2017-07-10 14:43:57 +02:00
|
|
|
OperationKey material_key(&ma->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::MATERIAL_UPDATE);
|
2018-06-06 11:22:20 +02:00
|
|
|
OperationKey shading_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::SHADING);
|
2017-07-10 14:43:57 +02:00
|
|
|
add_relation(material_key, shading_key, "Material Update");
|
|
|
|
|
}
|
2017-01-26 16:35:23 +01:00
|
|
|
}
|
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-06-06 11:22:20 +02:00
|
|
|
/* Geometry collision. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (ELEM(object->type, OB_MESH, OB_CURVE, OB_LATTICE)) {
|
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
|
|
|
// add geometry collider relations
|
|
|
|
|
}
|
2019-02-01 10:37:14 +01:00
|
|
|
/* Make sure uber update is the last in the dependencies. */
|
2017-11-23 11:39:28 +01:00
|
|
|
if (object->type != OB_ARMATURE) {
|
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
|
|
|
/* Armatures does no longer require uber node. */
|
2018-06-06 11:22:20 +02:00
|
|
|
OperationKey obdata_ubereval_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY,
|
2019-02-01 10:30:04 +01:00
|
|
|
OperationCode::GEOMETRY_EVAL);
|
2018-06-06 11:22:20 +02:00
|
|
|
add_relation(geom_init_key,
|
|
|
|
|
obdata_ubereval_key,
|
|
|
|
|
"Object Geometry UberEval");
|
2018-09-19 18:03:15 +02:00
|
|
|
if (object->totcol != 0 && object->type == OB_MESH) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey object_shading_key(&object->id, NodeType::SHADING);
|
|
|
|
|
Relation *rel = add_relation(obdata_ubereval_key,
|
|
|
|
|
object_shading_key,
|
|
|
|
|
"Object Geometry batch Update");
|
|
|
|
|
rel->flag |= RELATION_FLAG_NO_FLUSH;
|
2018-09-19 17:49:08 +02:00
|
|
|
}
|
2018-06-06 11:22:20 +02:00
|
|
|
}
|
|
|
|
|
if (object->type == OB_MBALL) {
|
2018-06-06 22:17:06 +02:00
|
|
|
Object *mom = BKE_mball_basis_find(scene_, object);
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey mom_geom_key(&mom->id, NodeType::GEOMETRY);
|
2018-06-06 22:17:06 +02:00
|
|
|
/* motherball - mom depends on children! */
|
|
|
|
|
if (mom == object) {
|
|
|
|
|
ComponentKey mom_transform_key(&mom->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2018-06-06 22:17:06 +02:00
|
|
|
add_relation(mom_transform_key,
|
|
|
|
|
mom_geom_key,
|
|
|
|
|
"Metaball Motherball Transform -> Geometry");
|
|
|
|
|
}
|
|
|
|
|
else {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey transform_key(&object->id, NodeType::TRANSFORM);
|
2018-06-06 22:17:06 +02:00
|
|
|
add_relation(geom_key, mom_geom_key, "Metaball Motherball");
|
|
|
|
|
add_relation(transform_key, mom_geom_key, "Metaball Motherball");
|
|
|
|
|
}
|
2018-06-06 11:22:20 +02:00
|
|
|
}
|
|
|
|
|
/* NOTE: This is compatibility code to support particle systems
|
|
|
|
|
*
|
|
|
|
|
* for viewport being properly rendered in final render mode.
|
|
|
|
|
* This relation is similar to what dag_object_time_update_flags()
|
|
|
|
|
* was doing for mesh objects with particle system.
|
|
|
|
|
*
|
2019-01-31 12:56:40 +01:00
|
|
|
* Ideally we need to get rid of this relation. */
|
2018-06-06 11:22:20 +02:00
|
|
|
if (object_particles_depends_on_time(object)) {
|
|
|
|
|
TimeSourceKey time_key;
|
|
|
|
|
OperationKey obdata_ubereval_key(&object->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY,
|
2019-02-01 10:30:04 +01:00
|
|
|
OperationCode::GEOMETRY_EVAL);
|
2018-06-06 11:22:20 +02:00
|
|
|
add_relation(time_key, obdata_ubereval_key, "Legacy particle time");
|
|
|
|
|
}
|
|
|
|
|
/* Object data datablock. */
|
|
|
|
|
build_object_data_geometry_datablock((ID *)object->data);
|
2018-06-06 11:53:04 +02:00
|
|
|
Key *key = BKE_key_from_object(object);
|
|
|
|
|
if (key != NULL) {
|
|
|
|
|
if (key->adt != NULL) {
|
|
|
|
|
if (key->adt->action || key->adt->nla_tracks.first) {
|
|
|
|
|
ComponentKey obdata_key((ID *)object->data,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY);
|
|
|
|
|
ComponentKey adt_key(&key->id, NodeType::ANIMATION);
|
2018-06-06 11:53:04 +02:00
|
|
|
add_relation(adt_key, obdata_key, "Animation");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-12-04 16:04:10 +01:00
|
|
|
/* Syncronization back to original object. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey final_geometry_jey(&object->id, NodeType::GEOMETRY);
|
2018-12-04 16:04:10 +01:00
|
|
|
OperationKey synchronize_key(&object->id,
|
2019-01-31 19:57:47 +01:00
|
|
|
NodeType::SYNCHRONIZATION,
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationCode::SYNCHRONIZE_TO_ORIGINAL);
|
2018-12-04 16:04:10 +01:00
|
|
|
add_relation(
|
|
|
|
|
final_geometry_jey, synchronize_key, "Synchronize to Original");
|
2018-06-06 11:22:20 +02:00
|
|
|
}
|
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-06-06 11:22:20 +02:00
|
|
|
void DepsgraphRelationBuilder::build_object_data_geometry_datablock(ID *obdata)
|
|
|
|
|
{
|
|
|
|
|
if (built_map_.checkIsBuiltAndTag(obdata)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
/* Animation. */
|
|
|
|
|
build_animdata(obdata);
|
|
|
|
|
/* ShapeKeys. */
|
|
|
|
|
Key *key = BKE_key_from_id(obdata);
|
|
|
|
|
if (key != NULL) {
|
2018-06-06 11:53:04 +02:00
|
|
|
build_shapekeys(key);
|
2018-06-06 11:22:20 +02:00
|
|
|
}
|
|
|
|
|
/* Link object data evaluation node to exit operation. */
|
2019-02-01 10:39:10 +01:00
|
|
|
OperationKey obdata_geom_eval_key(
|
2019-02-01 10:42:50 +01:00
|
|
|
obdata, NodeType::GEOMETRY, OperationCode::GEOMETRY_EVAL);
|
2018-06-06 11:22:20 +02:00
|
|
|
OperationKey obdata_geom_done_key(obdata,
|
2019-02-01 10:42:50 +01:00
|
|
|
NodeType::GEOMETRY,
|
|
|
|
|
OperationCode::GEOMETRY_EVAL_DONE);
|
2018-06-06 11:22:20 +02:00
|
|
|
add_relation(obdata_geom_eval_key,
|
|
|
|
|
obdata_geom_done_key,
|
2018-06-06 22:17:06 +02:00
|
|
|
"ObData Geom Eval Done");
|
2018-06-06 11:22:20 +02:00
|
|
|
/* Type-specific links. */
|
|
|
|
|
const ID_Type id_type = GS(obdata->name);
|
|
|
|
|
switch (id_type) {
|
|
|
|
|
case ID_ME:
|
|
|
|
|
break;
|
|
|
|
|
case ID_MB:
|
|
|
|
|
break;
|
|
|
|
|
case ID_CU:
|
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
|
|
|
{
|
|
|
|
|
Curve *cu = (Curve *)obdata;
|
2018-06-06 11:22:20 +02:00
|
|
|
if (cu->bevobj != NULL) {
|
|
|
|
|
ComponentKey bevob_geom_key(&cu->bevobj->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY);
|
2018-06-06 11:22:20 +02:00
|
|
|
add_relation(bevob_geom_key,
|
2018-07-31 10:22:19 +02:00
|
|
|
obdata_geom_eval_key,
|
|
|
|
|
"Curve Bevel Geometry");
|
2018-06-06 11:22:20 +02:00
|
|
|
ComponentKey bevob_key(&cu->bevobj->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::TRANSFORM);
|
2018-06-06 11:22:20 +02:00
|
|
|
add_relation(bevob_key,
|
2018-07-31 10:22:19 +02:00
|
|
|
obdata_geom_eval_key,
|
|
|
|
|
"Curve Bevel Transform");
|
2017-11-24 14:25:04 +01:00
|
|
|
build_object(NULL, cu->bevobj);
|
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-06-06 11:22:20 +02:00
|
|
|
if (cu->taperobj != NULL) {
|
|
|
|
|
ComponentKey taperob_key(&cu->taperobj->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY);
|
2018-06-06 11:22:20 +02:00
|
|
|
add_relation(taperob_key, obdata_geom_eval_key, "Curve Taper");
|
2017-11-24 14:25:04 +01:00
|
|
|
build_object(NULL, cu->taperobj);
|
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-06-06 11:22:20 +02:00
|
|
|
if (cu->textoncurve != NULL) {
|
|
|
|
|
ComponentKey textoncurve_key(&cu->textoncurve->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GEOMETRY);
|
2018-06-06 11:22:20 +02:00
|
|
|
add_relation(textoncurve_key,
|
2018-07-31 10:22:19 +02:00
|
|
|
obdata_geom_eval_key,
|
|
|
|
|
"Text on Curve");
|
2018-06-06 11:22:20 +02:00
|
|
|
build_object(NULL, cu->textoncurve);
|
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
|
|
|
}
|
2015-05-13 06:10:49 +10:00
|
|
|
break;
|
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-06-06 11:22:20 +02:00
|
|
|
case ID_LT:
|
2015-05-13 06:10:49 +10:00
|
|
|
break;
|
2018-07-31 10:22:19 +02:00
|
|
|
case ID_GD: /* Grease Pencil */
|
|
|
|
|
{
|
|
|
|
|
bGPdata *gpd = (bGPdata *)obdata;
|
|
|
|
|
|
|
|
|
|
/* Geometry cache needs to be recalculated on frame change
|
2018-09-02 18:28:27 +10:00
|
|
|
* (e.g. to fix crashes after scrubbing the timeline when
|
|
|
|
|
* onion skinning is enabled, since the ghosts need to be
|
2019-01-31 12:56:40 +01:00
|
|
|
* re-added to the cache once scrubbing ends). */
|
2018-07-31 10:22:19 +02:00
|
|
|
TimeSourceKey time_key;
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey geometry_key(obdata, NodeType::GEOMETRY);
|
2018-07-31 10:22:19 +02:00
|
|
|
add_relation(time_key,
|
2018-07-31 20:11:55 +10:00
|
|
|
geometry_key,
|
|
|
|
|
"GP Frame Change");
|
2018-07-31 10:22:19 +02:00
|
|
|
|
|
|
|
|
/* Geometry cache also needs to be recalculated when Material
|
2018-07-31 20:11:55 +10:00
|
|
|
* settings change (e.g. when fill.opacity changes on/off,
|
2019-01-31 12:56:40 +01:00
|
|
|
* we need to rebuild the bGPDstroke->triangles caches). */
|
2018-07-31 10:22:19 +02:00
|
|
|
for (int i = 0; i < gpd->totcol; i++) {
|
|
|
|
|
Material *ma = gpd->mat[i];
|
|
|
|
|
if ((ma != NULL) && (ma->gp_style != NULL)) {
|
|
|
|
|
OperationKey material_key(&ma->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::MATERIAL_UPDATE);
|
2018-07-31 10:22:19 +02:00
|
|
|
add_relation(material_key,
|
2018-07-31 20:11:55 +10:00
|
|
|
geometry_key,
|
|
|
|
|
"Material -> GP Data");
|
2018-07-31 10:22:19 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2018-06-06 11:22:20 +02:00
|
|
|
default:
|
|
|
|
|
BLI_assert(!"Should not happen");
|
2015-05-13 06:10:49 +10:00
|
|
|
break;
|
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-06-06 11:41:56 +02:00
|
|
|
void DepsgraphRelationBuilder::build_armature(bArmature *armature)
|
|
|
|
|
{
|
|
|
|
|
if (built_map_.checkIsBuiltAndTag(armature)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
build_animdata(&armature->id);
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-06 10:52:50 +02:00
|
|
|
void DepsgraphRelationBuilder::build_camera(Camera *camera)
|
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-02-22 11:03:39 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(camera)) {
|
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;
|
|
|
|
|
}
|
2018-02-22 11:20:28 +01:00
|
|
|
if (camera->dof_ob != NULL) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey camera_parameters_key(&camera->id, NodeType::PARAMETERS);
|
|
|
|
|
ComponentKey dof_ob_key(&camera->dof_ob->id, NodeType::TRANSFORM);
|
2018-06-06 10:52:50 +02:00
|
|
|
add_relation(dof_ob_key, camera_parameters_key, "Camera DOF");
|
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-02-27 12:02:02 +11:00
|
|
|
/* Lights */
|
|
|
|
|
void DepsgraphRelationBuilder::build_light(Light *lamp)
|
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-02-22 11:03:39 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(lamp)) {
|
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;
|
|
|
|
|
}
|
2019-02-27 12:02:02 +11:00
|
|
|
/* light's nodetree */
|
2018-02-22 11:03:39 +01:00
|
|
|
if (lamp->nodetree != NULL) {
|
|
|
|
|
build_nodetree(lamp->nodetree);
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey lamp_parameters_key(&lamp->id, NodeType::PARAMETERS);
|
|
|
|
|
ComponentKey nodetree_key(&lamp->nodetree->id, NodeType::SHADING);
|
2018-06-27 14:41:53 +02:00
|
|
|
add_relation(nodetree_key, lamp_parameters_key, "NTree->Light Parameters");
|
2018-05-01 12:41:10 +02:00
|
|
|
build_nested_nodetree(&lamp->id, lamp->nodetree);
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-26 16:35:23 +01:00
|
|
|
void DepsgraphRelationBuilder::build_nodetree(bNodeTree *ntree)
|
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
|
|
|
{
|
2017-08-29 17:03:07 +02:00
|
|
|
if (ntree == NULL) {
|
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;
|
2017-08-29 17:03:07 +02:00
|
|
|
}
|
2018-02-22 11:03:39 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(ntree)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
build_animdata(&ntree->id);
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey shading_key(&ntree->id, NodeType::SHADING);
|
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
|
|
|
/* nodetree's nodes... */
|
2018-02-15 12:38:21 +01:00
|
|
|
LISTBASE_FOREACH (bNode *, bnode, &ntree->nodes) {
|
2017-11-08 17:32:03 +01:00
|
|
|
ID *id = bnode->id;
|
|
|
|
|
if (id == NULL) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2017-11-08 17:33:46 +01:00
|
|
|
ID_Type id_type = GS(id->name);
|
|
|
|
|
if (id_type == ID_MA) {
|
2017-11-08 17:32:03 +01:00
|
|
|
build_material((Material *)bnode->id);
|
|
|
|
|
}
|
2017-11-08 17:33:46 +01:00
|
|
|
else if (id_type == ID_TE) {
|
2017-11-08 17:32:03 +01:00
|
|
|
build_texture((Tex *)bnode->id);
|
|
|
|
|
}
|
2017-11-08 17:34:19 +01:00
|
|
|
else if (id_type == ID_IM) {
|
|
|
|
|
/* nothing for now. */
|
|
|
|
|
}
|
2017-11-09 09:46:50 +01:00
|
|
|
else if (id_type == ID_OB) {
|
2017-11-24 14:25:04 +01:00
|
|
|
build_object(NULL, (Object *)id);
|
2017-11-09 09:46:50 +01:00
|
|
|
}
|
|
|
|
|
else if (id_type == ID_SCE) {
|
|
|
|
|
/* Scenes are used by compositor trees, and handled by render
|
2019-01-31 12:56:40 +01:00
|
|
|
* pipeline. No need to build dependencies for them here. */
|
2017-11-09 09:46:50 +01:00
|
|
|
}
|
2017-12-06 11:57:57 +01:00
|
|
|
else if (id_type == ID_TXT) {
|
|
|
|
|
/* Ignore script nodes. */
|
|
|
|
|
}
|
2018-10-26 10:32:57 +02:00
|
|
|
else if (id_type == ID_MSK) {
|
|
|
|
|
build_mask((Mask *)id);
|
|
|
|
|
}
|
2018-08-13 10:11:21 -03:00
|
|
|
else if (id_type == ID_MC) {
|
|
|
|
|
build_movieclip((MovieClip *)id);
|
|
|
|
|
}
|
2017-11-08 17:32:03 +01:00
|
|
|
else if (bnode->type == NODE_GROUP) {
|
|
|
|
|
bNodeTree *group_ntree = (bNodeTree *)id;
|
2018-02-22 11:03:39 +01:00
|
|
|
build_nodetree(group_ntree);
|
2017-11-09 10:59:15 +01:00
|
|
|
ComponentKey group_shading_key(&group_ntree->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING);
|
2017-11-09 10:59:15 +01:00
|
|
|
add_relation(group_shading_key, shading_key, "Group Node");
|
2017-11-08 17:32:03 +01:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BLI_assert(!"Unknown ID type used for node");
|
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-02-22 11:20:28 +01:00
|
|
|
OperationKey shading_update_key(&ntree->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::MATERIAL_UPDATE);
|
2018-02-22 11:20:28 +01:00
|
|
|
OperationKey shading_parameters_key(&ntree->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING_PARAMETERS,
|
|
|
|
|
OperationCode::MATERIAL_UPDATE);
|
2017-08-29 12:51:56 +02:00
|
|
|
add_relation(shading_parameters_key, shading_update_key, "NTree Shading Parameters");
|
2018-05-03 12:41:03 +02:00
|
|
|
|
|
|
|
|
if (check_id_has_anim_component(&ntree->id)) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey animation_key(&ntree->id, NodeType::ANIMATION);
|
2018-06-05 15:10:09 +02:00
|
|
|
add_relation(animation_key, shading_parameters_key, "NTree Shading Parameters");
|
2018-05-03 12:41:03 +02:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Recursively build graph for material */
|
2018-02-22 11:03:39 +01:00
|
|
|
void DepsgraphRelationBuilder::build_material(Material *material)
|
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-02-22 11:03:39 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(material)) {
|
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;
|
|
|
|
|
}
|
|
|
|
|
/* animation */
|
2018-02-22 11:03:39 +01:00
|
|
|
build_animdata(&material->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
|
|
|
/* material's nodetree */
|
2018-02-22 11:03:39 +01:00
|
|
|
if (material->nodetree != NULL) {
|
|
|
|
|
build_nodetree(material->nodetree);
|
|
|
|
|
OperationKey ntree_key(&material->nodetree->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::MATERIAL_UPDATE);
|
2018-02-22 11:03:39 +01:00
|
|
|
OperationKey material_key(&material->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::SHADING,
|
|
|
|
|
OperationCode::MATERIAL_UPDATE);
|
2017-06-01 16:20:48 +02:00
|
|
|
add_relation(ntree_key, material_key, "Material's NTree");
|
2018-05-01 12:41:10 +02:00
|
|
|
build_nested_nodetree(&material->id, material->nodetree);
|
2017-01-26 16:49:24 +01:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Recursively build graph for texture */
|
2018-02-22 11:03:39 +01:00
|
|
|
void DepsgraphRelationBuilder::build_texture(Tex *texture)
|
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-02-22 11:03:39 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(texture)) {
|
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;
|
|
|
|
|
}
|
|
|
|
|
/* texture itself */
|
2018-02-22 11:03:39 +01:00
|
|
|
build_animdata(&texture->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
|
|
|
/* texture's nodetree */
|
2018-02-22 11:03:39 +01:00
|
|
|
build_nodetree(texture->nodetree);
|
2018-05-01 12:41:10 +02:00
|
|
|
build_nested_nodetree(&texture->id, texture->nodetree);
|
2018-12-10 15:09:46 +01:00
|
|
|
if (check_id_has_anim_component(&texture->id)) {
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey animation_key(&texture->id, NodeType::ANIMATION);
|
2018-12-10 15:09:46 +01:00
|
|
|
ComponentKey datablock_key(&texture->id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::GENERIC_DATABLOCK);
|
2018-12-10 15:09:46 +01:00
|
|
|
add_relation(animation_key, datablock_key, "Datablock Animation");
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_compositor(Scene *scene)
|
|
|
|
|
{
|
|
|
|
|
/* For now, just a plain wrapper? */
|
2017-01-26 16:35:23 +01:00
|
|
|
build_nodetree(scene->nodetree);
|
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
|
|
|
}
|
|
|
|
|
|
2017-01-26 16:35:23 +01:00
|
|
|
void DepsgraphRelationBuilder::build_gpencil(bGPdata *gpd)
|
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-05-04 16:36:27 +02:00
|
|
|
if (built_map_.checkIsBuiltAndTag(gpd)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
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
|
|
|
/* animation */
|
|
|
|
|
build_animdata(&gpd->id);
|
|
|
|
|
|
|
|
|
|
// TODO: parent object (when that feature is implemented)
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-23 23:54:05 +13:00
|
|
|
void DepsgraphRelationBuilder::build_cachefile(CacheFile *cache_file)
|
|
|
|
|
{
|
2018-05-04 16:36:27 +02:00
|
|
|
if (built_map_.checkIsBuiltAndTag(cache_file)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-11-17 15:29:22 +01:00
|
|
|
/* Animation. */
|
|
|
|
|
build_animdata(&cache_file->id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_mask(Mask *mask)
|
|
|
|
|
{
|
2018-05-04 16:36:27 +02:00
|
|
|
if (built_map_.checkIsBuiltAndTag(mask)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2017-09-14 16:12:01 +05:00
|
|
|
ID *mask_id = &mask->id;
|
|
|
|
|
/* F-Curve animation. */
|
|
|
|
|
build_animdata(mask_id);
|
|
|
|
|
/* Own mask animation. */
|
|
|
|
|
OperationKey mask_animation_key(mask_id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::ANIMATION,
|
|
|
|
|
OperationCode::MASK_ANIMATION);
|
2017-09-14 16:12:01 +05:00
|
|
|
TimeSourceKey time_src_key;
|
|
|
|
|
add_relation(time_src_key, mask_animation_key, "TimeSrc -> Mask Animation");
|
|
|
|
|
/* Final mask evaluation. */
|
2019-01-31 12:56:40 +01:00
|
|
|
ComponentKey parameters_key(mask_id, NodeType::PARAMETERS);
|
2017-09-14 16:12:01 +05:00
|
|
|
add_relation(mask_animation_key, parameters_key, "Mask Animation -> Mask Eval");
|
2016-11-17 15:29:22 +01:00
|
|
|
}
|
|
|
|
|
|
2016-11-17 16:37:25 +01:00
|
|
|
void DepsgraphRelationBuilder::build_movieclip(MovieClip *clip)
|
|
|
|
|
{
|
2018-05-04 16:36:27 +02:00
|
|
|
if (built_map_.checkIsBuiltAndTag(clip)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-11-17 16:37:25 +01:00
|
|
|
/* Animation. */
|
|
|
|
|
build_animdata(&clip->id);
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-06 10:23:45 +02:00
|
|
|
void DepsgraphRelationBuilder::build_lightprobe(LightProbe *probe)
|
2017-06-09 18:04:05 +02:00
|
|
|
{
|
2018-02-22 11:20:28 +01:00
|
|
|
if (built_map_.checkIsBuiltAndTag(probe)) {
|
2017-06-09 18:04:05 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
build_animdata(&probe->id);
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-25 11:53:38 +02:00
|
|
|
void DepsgraphRelationBuilder::build_speaker(Speaker *speaker)
|
|
|
|
|
{
|
|
|
|
|
if (built_map_.checkIsBuiltAndTag(speaker)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
build_animdata(&speaker->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
|
|
|
void DepsgraphRelationBuilder::build_copy_on_write_relations()
|
|
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
for (IDNode *id_node : graph_->id_nodes) {
|
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
|
|
|
build_copy_on_write_relations(id_node);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-01 12:41:10 +02:00
|
|
|
/* Nested datablocks (node trees, shape keys) requires special relation to
|
|
|
|
|
* ensure owner's datablock remapping happens after node tree itself is ready.
|
|
|
|
|
*
|
|
|
|
|
* This is similar to what happens in ntree_hack_remap_pointers().
|
|
|
|
|
*/
|
2018-05-11 07:55:41 +02:00
|
|
|
void DepsgraphRelationBuilder::build_nested_datablock(ID *owner, ID *id)
|
|
|
|
|
{
|
2018-05-01 12:41:10 +02:00
|
|
|
OperationKey owner_copy_on_write_key(owner,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::COPY_ON_WRITE,
|
|
|
|
|
OperationCode::COPY_ON_WRITE);
|
2018-05-01 12:41:10 +02:00
|
|
|
OperationKey id_copy_on_write_key(id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::COPY_ON_WRITE,
|
|
|
|
|
OperationCode::COPY_ON_WRITE);
|
2018-05-01 12:41:10 +02:00
|
|
|
add_relation(id_copy_on_write_key,
|
|
|
|
|
owner_copy_on_write_key,
|
|
|
|
|
"Eval Order");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_nested_nodetree(ID *owner,
|
|
|
|
|
bNodeTree *ntree)
|
|
|
|
|
{
|
|
|
|
|
if (ntree == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
build_nested_datablock(owner, &ntree->id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::build_nested_shapekey(ID *owner, Key *key)
|
|
|
|
|
{
|
|
|
|
|
if (key == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
build_nested_datablock(owner, &key->id);
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-31 12:56:40 +01:00
|
|
|
void DepsgraphRelationBuilder::build_copy_on_write_relations(IDNode *id_node)
|
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
|
|
|
{
|
|
|
|
|
ID *id_orig = id_node->id_orig;
|
2018-07-09 14:17:36 +02:00
|
|
|
const ID_Type id_type = GS(id_orig->name);
|
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
|
|
|
TimeSourceKey time_source_key;
|
|
|
|
|
OperationKey copy_on_write_key(id_orig,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::COPY_ON_WRITE,
|
|
|
|
|
OperationCode::COPY_ON_WRITE);
|
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
|
|
|
/* XXX: This is a quick hack to make Alt-A to work. */
|
2017-07-28 12:27:34 +02:00
|
|
|
// add_relation(time_source_key, copy_on_write_key, "Fluxgate capacitor hack");
|
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
|
|
|
/* Resat of code is using rather low level trickery, so need to get some
|
2018-11-16 16:11:24 +01:00
|
|
|
* explicit pointers. */
|
2019-01-31 12:56:40 +01:00
|
|
|
Node *node_cow = find_node(copy_on_write_key);
|
|
|
|
|
OperationNode *op_cow = node_cow->get_exit_operation();
|
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
|
|
|
/* Plug any other components to this one. */
|
2019-01-31 12:56:40 +01:00
|
|
|
GHASH_FOREACH_BEGIN(ComponentNode *, comp_node, id_node->components)
|
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
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
if (comp_node->type == NodeType::COPY_ON_WRITE) {
|
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
|
|
|
/* Copy-on-write component never depends on itself. */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2017-08-29 12:51:56 +02:00
|
|
|
if (!comp_node->depends_on_cow()) {
|
|
|
|
|
/* Component explicitly requests to not add relation. */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2019-01-31 12:56:40 +01:00
|
|
|
int rel_flag = (RELATION_FLAG_NO_FLUSH | RELATION_FLAG_GODMODE);
|
|
|
|
|
if (id_type == ID_ME && comp_node->type == NodeType::GEOMETRY) {
|
|
|
|
|
rel_flag &= ~RELATION_FLAG_NO_FLUSH;
|
2018-07-09 14:17:36 +02:00
|
|
|
}
|
2018-07-31 10:22:19 +02:00
|
|
|
/* materials need update grease pencil objects */
|
|
|
|
|
if (id_type == ID_MA) {
|
2019-01-31 12:56:40 +01:00
|
|
|
rel_flag &= ~RELATION_FLAG_NO_FLUSH;
|
2018-07-31 10:22:19 +02:00
|
|
|
}
|
2018-07-11 12:55:03 +02:00
|
|
|
/* Notes on exceptions:
|
|
|
|
|
* - Parameters component is where drivers are living. Changing any
|
|
|
|
|
* of the (custom) properties in the original datablock (even the
|
|
|
|
|
* ones which do not imply other component update) need to make
|
|
|
|
|
* sure drivers are properly updated.
|
|
|
|
|
* This way, for example, changing ID property will properly poke
|
|
|
|
|
* all drivers to be updated.
|
|
|
|
|
*
|
|
|
|
|
* - View layers have cached array of bases in them, which is not
|
|
|
|
|
* copied by copy-on-write, and not preserved. PROBABLY it is better
|
|
|
|
|
* to preserve that cache in copy-on-write, but for the time being
|
|
|
|
|
* we allow flush to layer collections component which will ensure
|
|
|
|
|
* that cached array fo bases exists and is up-to-date.
|
2018-11-21 16:29:22 +01:00
|
|
|
*
|
|
|
|
|
* - Action is allowed to flush as well, this way it's possible to
|
|
|
|
|
* keep current tagging in animation editors (which tags action for
|
|
|
|
|
* CoW update when it's changed) but yet guarantee evaluation order
|
2019-01-31 12:56:40 +01:00
|
|
|
* with objects which are using that action. */
|
|
|
|
|
if (comp_node->type == NodeType::PARAMETERS ||
|
2019-02-08 12:13:02 +01:00
|
|
|
comp_node->type == NodeType::LAYER_COLLECTIONS)
|
2018-07-11 12:55:03 +02:00
|
|
|
{
|
2019-01-31 12:56:40 +01:00
|
|
|
rel_flag &= ~RELATION_FLAG_NO_FLUSH;
|
2018-07-09 17:41:04 +02:00
|
|
|
}
|
2019-02-08 12:13:02 +01:00
|
|
|
if (comp_node->type == NodeType::ANIMATION && id_type == ID_AC) {
|
|
|
|
|
rel_flag &= ~RELATION_FLAG_NO_FLUSH;
|
|
|
|
|
/* NOTE: We only allow flush on user edits. If the action block is
|
|
|
|
|
* just brought into the dependency graph it is either due to
|
|
|
|
|
* initial graph construction or due to some property got animated.
|
|
|
|
|
* In first case all the related datablocks will be tagged for an
|
|
|
|
|
* update as well. In the second case it is up to the editing
|
|
|
|
|
* function to tag changed datablock.
|
|
|
|
|
*
|
|
|
|
|
* This logic allows to preserve unkeyed changes on file load and on
|
|
|
|
|
* undo. */
|
|
|
|
|
rel_flag |= RELATION_FLAG_FLUSH_USER_EDIT_ONLY;
|
|
|
|
|
}
|
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
|
|
|
/* All entry operations of each component should wait for a proper
|
2019-01-31 12:56:40 +01:00
|
|
|
* copy of ID. */
|
|
|
|
|
OperationNode *op_entry = comp_node->get_entry_operation();
|
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
|
|
|
if (op_entry != NULL) {
|
2019-01-31 12:56:40 +01:00
|
|
|
Relation *rel = graph_->add_new_relation(
|
2018-05-31 12:54:42 +02:00
|
|
|
op_cow, op_entry, "CoW Dependency");
|
|
|
|
|
rel->flag |= rel_flag;
|
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
|
|
|
}
|
|
|
|
|
/* All dangling operations should also be executed after copy-on-write. */
|
2019-01-31 12:56:40 +01:00
|
|
|
GHASH_FOREACH_BEGIN(OperationNode *, op_node, comp_node->operations_map)
|
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-04-23 12:18:11 +02:00
|
|
|
if (op_node == op_entry) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
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
|
|
|
if (op_node->inlinks.size() == 0) {
|
2019-01-31 12:56:40 +01:00
|
|
|
Relation *rel = graph_->add_new_relation(
|
2018-05-31 12:54:42 +02:00
|
|
|
op_cow, op_node, "CoW Dependency");
|
|
|
|
|
rel->flag |= rel_flag;
|
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-02-07 12:26:30 +01:00
|
|
|
else {
|
2018-04-04 17:28:23 +02:00
|
|
|
bool has_same_comp_dependency = false;
|
2019-01-31 12:56:40 +01:00
|
|
|
for (Relation *rel_current : op_node->inlinks) {
|
|
|
|
|
if (rel_current->from->type != NodeType::OPERATION) {
|
2018-02-07 12:26:30 +01:00
|
|
|
continue;
|
|
|
|
|
}
|
2019-01-31 12:56:40 +01:00
|
|
|
OperationNode *op_node_from =
|
|
|
|
|
(OperationNode *)rel_current->from;
|
2018-04-04 17:28:23 +02:00
|
|
|
if (op_node_from->owner == op_node->owner) {
|
|
|
|
|
has_same_comp_dependency = true;
|
2018-02-07 12:26:30 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-04-04 17:28:23 +02:00
|
|
|
if (!has_same_comp_dependency) {
|
2019-01-31 12:56:40 +01:00
|
|
|
Relation *rel = graph_->add_new_relation(
|
2018-05-31 12:54:42 +02:00
|
|
|
op_cow, op_node, "CoW Dependency");
|
|
|
|
|
rel->flag |= rel_flag;
|
2018-02-07 12:26:30 +01:00
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
GHASH_FOREACH_END();
|
|
|
|
|
/* NOTE: We currently ignore implicit relations to an external
|
|
|
|
|
* datablocks for copy-on-write operations. This means, for example,
|
|
|
|
|
* copy-on-write component of Object will not wait for copy-on-write
|
|
|
|
|
* component of it's Mesh. This is because pointers are all known
|
|
|
|
|
* already so remapping will happen all correct. And then If some object
|
|
|
|
|
* evaluation step needs geometry, it will have transitive dependency
|
2019-01-31 12:56:40 +01:00
|
|
|
* to Mesh copy-on-write already. */
|
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
|
|
|
}
|
|
|
|
|
GHASH_FOREACH_END();
|
2017-11-21 15:34:13 +01:00
|
|
|
/* TODO(sergey): This solves crash for now, but causes too many
|
2019-01-31 12:56:40 +01:00
|
|
|
* updates potentially. */
|
2017-11-21 15:34:13 +01:00
|
|
|
if (GS(id_orig->name) == ID_OB) {
|
|
|
|
|
Object *object = (Object *)id_orig;
|
|
|
|
|
ID *object_data_id = (ID *)object->data;
|
2017-11-21 15:47:47 +01:00
|
|
|
if (object_data_id != NULL) {
|
2018-11-19 12:04:02 +01:00
|
|
|
if (deg_copy_on_write_is_needed(object_data_id)) {
|
|
|
|
|
OperationKey data_copy_on_write_key(object_data_id,
|
2019-01-31 12:56:40 +01:00
|
|
|
NodeType::COPY_ON_WRITE,
|
|
|
|
|
OperationCode::COPY_ON_WRITE);
|
2018-11-22 14:54:08 +01:00
|
|
|
add_relation(data_copy_on_write_key,
|
|
|
|
|
copy_on_write_key,
|
|
|
|
|
"Eval Order",
|
2019-01-31 12:56:40 +01:00
|
|
|
RELATION_FLAG_GODMODE);
|
2018-11-19 12:04:02 +01:00
|
|
|
}
|
2017-11-21 15:47:47 +01:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BLI_assert(object->type == OB_EMPTY);
|
|
|
|
|
}
|
2017-11-21 15:34:13 +01:00
|
|
|
}
|
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-04-10 11:56:20 +02:00
|
|
|
/* **** ID traversal callbacks functions **** */
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::modifier_walk(void *user_data,
|
|
|
|
|
struct Object * /*object*/,
|
|
|
|
|
struct ID **idpoin,
|
|
|
|
|
int /*cb_flag*/)
|
|
|
|
|
{
|
|
|
|
|
BuilderWalkUserData *data = (BuilderWalkUserData *)user_data;
|
|
|
|
|
ID *id = *idpoin;
|
|
|
|
|
if (id == NULL) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2018-11-15 12:47:58 +01:00
|
|
|
data->builder->build_id(id);
|
2018-04-10 11:56:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DepsgraphRelationBuilder::constraint_walk(bConstraint * /*con*/,
|
|
|
|
|
ID **idpoin,
|
|
|
|
|
bool /*is_reference*/,
|
|
|
|
|
void *user_data)
|
|
|
|
|
{
|
|
|
|
|
BuilderWalkUserData *data = (BuilderWalkUserData *)user_data;
|
2018-11-15 12:47:58 +01:00
|
|
|
ID *id = *idpoin;
|
|
|
|
|
if (id == NULL) {
|
|
|
|
|
return;
|
2018-04-10 11:56:20 +02:00
|
|
|
}
|
2018-11-15 12:47:58 +01:00
|
|
|
data->builder->build_id(id);
|
2018-04-10 11:56:20 +02:00
|
|
|
}
|
|
|
|
|
|
Depsgraph: Cleanup and code simplification
This is mainly a maintenance commit which was aimed to make work with
this module more pleasant and solve such issues as:
- Annoyance with looong files, which had craftload in them
- Usage of STL for the data structures we've got in BLI
- Possible symbol conflicts
- Not real clear layout of what is located where
So in this commit the following changes are done:
- STL is prohibited, it's not really predictable on various compilers,
with our BLI algorithms we can predict things much better.
There are still few usages of std::vector, but that we'll be
solving later once we've got similar thing in BLI.
- Simplify foreach loops, avoid using const_iterator all over the place.
- New directory layout, which is hopefully easier to follow.
- Some files were split, some of them will be split soon.
The idea of this is to split huge functions into own files with
good documentation and everything.
- Removed stuff which was planned for use in the future but was never
finished, tested or anything.
Let's wipe it out for now, and bring back once we really start using
it, so it'll be more clear if it solves our needs.
- All the internal routines were moved to DEG namespace to separate
them better from rest of blender.
Some places now annoyingly using DEG::foo, but that we can olve by
moving some utility functions inside of the namespace.
While working on this we've found some hotspot in updates flush, so
now playback of blenrig is few percent faster (something like 96fps
with previous master and around 99-100fps after this change).
Not saying it's something final, there is still room for cleanup and
API simplification, but those might happen as a regular development
now without doing any global changes.
2016-05-27 18:01:18 +02:00
|
|
|
} // namespace DEG
|