archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
822c67364e85f1092c25cdd5ab9d68c515deb09d
blender-archive/source/blender/depsgraph/DEG_depsgraph_build.h

177 lines
6.4 KiB
C++
Raw Normal View History

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.
doxygen: corrections/updates Also add depsgraph & physics
2015-05-20 12:54:45 +10:00
*/
doxygen: add newline after \file While \file doesn't need an argument, it can't have another doxy command after it.
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
*
* Public API for Depsgraph
*/
#ifndef __DEG_DEPSGRAPH_BUILD_H__
#define __DEG_DEPSGRAPH_BUILD_H__
/* ************************************************* */
/* Dependency Graph */
struct Depsgraph;
/* ------------------------------------------------ */
Cleanup: Get rid of legacy depsgraph header file
2017-04-05 15:50:45 +02:00
struct CacheFile;
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
struct Collection;
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
struct CustomData_MeshMasks;
Cleanup: sort forward declarations of enum & struct Done using: source/tools/utils_maintenance/c_sort_blocks.py
2019-01-28 21:08:24 +11:00
struct EffectorWeights;
Fix T58679: Missing modifiers update on changes to texture
2018-12-05 17:35:13 +01:00
struct 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
struct Main;
Cleanup: Get rid of legacy depsgraph header file
2017-04-05 15:50:45 +02:00
struct ModifierData;
struct 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
struct Scene;
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
struct ViewLayer;
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
#ifdef __cplusplus
extern "C" {
#endif
Depsgraph: Add proper API functions for CustomDataMask dependencies. There were a few copies of the same few lines in depsgraph build code, so it seems to be logical to introduce a function for it, and make it accessible from C code for completeness. As an example, register the mask needs of the Data Transfer modifier.
2018-10-14 19:59:27 +03:00
#include "BLI_sys_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
/* Graph Building -------------------------------- */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
/* Build depsgraph for the given scene, and dump results in given
* graph container.
*/
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
void DEG_graph_build_from_view_layer(struct Depsgraph *graph,
Depsgraph: Make dependency graph to be built from scene layer This is a final step of having proper ownership. Now selecting different layers in the "top bar" will actually do what this is expected to do. Surely, there are still things to be done under the hood, that will happen in a less intrusive way.
2017-11-09 11:20:17 +01:00
struct Main *bmain,
struct Scene *scene,
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
struct ViewLayer *view_layer);
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
/* Tag relations from the given graph for update. */
void DEG_graph_tag_relations_update(struct Depsgraph *graph);
Depsgraph: Add function to update relations within a given graph
2017-10-25 12:27:37 +02:00
/* Create or update relations in the specified graph. */
void DEG_graph_relations_update(struct Depsgraph *graph,
struct Main *bmain,
Depsgraph: Make dependency graph to be built from scene layer This is a final step of having proper ownership. Now selecting different layers in the "top bar" will actually do what this is expected to do. Surely, there are still things to be done under the hood, that will happen in a less intrusive way.
2017-11-09 11:20:17 +01:00
struct Scene *scene,
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
struct ViewLayer *view_layer);
Depsgraph: Add function to update relations within a given graph
2017-10-25 12:27: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
/* Tag all relations in the database for update.*/
void DEG_relations_tag_update(struct Main *bmain);
/* Add Dependencies ----------------------------- */
/* Handle for components to define their dependencies from callbacks.
* This is generated by the depsgraph and passed to dependency callbacks
* as a symbolic reference to the current DepsNode.
* All relations will be defined in reference to that node.
*/
struct DepsNodeHandle;
typedef enum eDepsSceneComponentType {
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
/* Parameters Component - Default when nothing else fits
Depsgraph: Comb code to a better state all over Some summary of changes: - Don't use DEG prefix for types and enumerator values: the code is already inside DEG namespace. - Put code where it locally belongs to: avoid having one single header file with all sort of definitions in it. - Take advantage of modern C++11 enabled by default.
2019-01-31 12:56:40 +01:00
* (i.e. just SDNA property setting). */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
DEG_SCENE_COMP_PARAMETERS,
/* Animation Component
Depsgraph: Comb code to a better state all over Some summary of changes: - Don't use DEG prefix for types and enumerator values: the code is already inside DEG namespace. - Put code where it locally belongs to: avoid having one single header file with all sort of definitions in it. - Take advantage of modern C++11 enabled by default.
2019-01-31 12:56:40 +01:00
* TODO(sergey): merge in with parameters? */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
DEG_SCENE_COMP_ANIMATION,
/* Sequencer Component (Scene Only). */
DEG_SCENE_COMP_SEQUENCER,
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
} eDepsSceneComponentType;
typedef enum eDepsObjectComponentType {
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
/* Parameters Component - Default when nothing else fits
Depsgraph: Comb code to a better state all over Some summary of changes: - Don't use DEG prefix for types and enumerator values: the code is already inside DEG namespace. - Put code where it locally belongs to: avoid having one single header file with all sort of definitions in it. - Take advantage of modern C++11 enabled by default.
2019-01-31 12:56:40 +01:00
* (i.e. just SDNA property setting). */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
DEG_OB_COMP_PARAMETERS,
/* Generic "Proxy-Inherit" Component.
Depsgraph: Comb code to a better state all over Some summary of changes: - Don't use DEG prefix for types and enumerator values: the code is already inside DEG namespace. - Put code where it locally belongs to: avoid having one single header file with all sort of definitions in it. - Take advantage of modern C++11 enabled by default.
2019-01-31 12:56:40 +01:00
* TODO(sergey): Also for instancing of subgraphs? */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
DEG_OB_COMP_PROXY,
/* Animation Component.
*
Depsgraph: Comb code to a better state all over Some summary of changes: - Don't use DEG prefix for types and enumerator values: the code is already inside DEG namespace. - Put code where it locally belongs to: avoid having one single header file with all sort of definitions in it. - Take advantage of modern C++11 enabled by default.
2019-01-31 12:56:40 +01:00
* TODO(sergey): merge in with parameters? */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
DEG_OB_COMP_ANIMATION,
/* Transform Component (Parenting/Constraints) */
DEG_OB_COMP_TRANSFORM,
Cleanup: remove unused DerivedMesh code. Differential Revision: https://developer.blender.org/D3736
2018-09-27 15:54:10 +02:00
/* Geometry Component (Mesh/Displist) */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
DEG_OB_COMP_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
/* Evaluation-Related Outer Types (with Subdata) */
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
/* Pose Component - Owner/Container of Bones Eval */
DEG_OB_COMP_EVAL_POSE,
/* Bone Component - Child/Subcomponent of Pose */
DEG_OB_COMP_BONE,
/* Material Shading Component */
DEG_OB_COMP_SHADING,
/* Cache Component */
DEG_OB_COMP_CACHE,
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
} eDepsObjectComponentType;
Depsgraph: Fix missing point cache reset when physics changes Among all the lines moved around, the general idea is quite simple. Actually, there are two ideas implemented there. First one, is when object itself is tagged for update, we tag its point cache component for evaluation, which makes it so point cache is properly reset. We do it implicitly because otherwise we'll need to go everywhere and add explicit tag in almost all the properties. Second thing is, we link all collider and force fields to a point cache component using special type of link. This type of link only allows flush if change is caused by a user update. This way reset does not happen when change is caused due to animation, but will properly happen when user causes indirect change to the objects which are part of physics simulation.
2018-11-14 11:24:54 +01:00
void DEG_add_scene_relation(struct DepsNodeHandle *node_handle,
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
struct Scene *scene,
eDepsSceneComponentType component,
const char *description);
Depsgraph: Fix missing point cache reset when physics changes Among all the lines moved around, the general idea is quite simple. Actually, there are two ideas implemented there. First one, is when object itself is tagged for update, we tag its point cache component for evaluation, which makes it so point cache is properly reset. We do it implicitly because otherwise we'll need to go everywhere and add explicit tag in almost all the properties. Second thing is, we link all collider and force fields to a point cache component using special type of link. This type of link only allows flush if change is caused by a user update. This way reset does not happen when change is caused due to animation, but will properly happen when user causes indirect change to the objects which are part of physics simulation.
2018-11-14 11:24:54 +01:00
void DEG_add_object_relation(struct DepsNodeHandle *node_handle,
Depsgraph: Cleanup, always call full `object`
2017-11-23 11:39:28 +01:00
struct Object *object,
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
eDepsObjectComponentType component,
const char *description);
void DEG_add_bone_relation(struct DepsNodeHandle *handle,
Depsgraph: Cleanup, always call full `object`
2017-11-23 11:39:28 +01:00
struct Object *object,
Depsgraph: cleanup, no functional changes
2016-11-11 13:52:22 +01:00
const char *bone_name,
eDepsObjectComponentType component,
const char *description);
void DEG_add_object_cache_relation(struct DepsNodeHandle *handle,
struct CacheFile *cache_file,
eDepsObjectComponentType component,
const char *description);
Fix T58679: Missing modifiers update on changes to texture
2018-12-05 17:35:13 +01:00
/* Adds relation from DEG_OPCODE_GENERIC_DATABLOCK_UPDATE of a given ID.
* Is used for such entities as textures and images. */
void DEG_add_generic_id_relation(struct DepsNodeHandle *node_handle,
struct ID *id,
const char *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
Depsgraph: Add utility function for transform dependency This is what modifiers are to use to indicate that they depend on a transformation of the object itself. Currently should be no functional changes, but in the future this will allow to easily change transform operation depending on whether there is a simulation associated with the object.
2019-02-12 12:01:17 +01:00
/* Special function which is used from modifiers' updateDepsgraph() callback
* to indicate that the modifietr needs to know transformation of the object
* which that modifier belongs to.
* This function will take care of checking which operation is required to
* have transformation for the modifier, taking into account possible simulation
* solvers. */
void DEG_add_modifier_to_transform_relation(
struct DepsNodeHandle *node_handle,
const char *description);
Depsgraph: Fix missing point cache reset when physics changes Among all the lines moved around, the general idea is quite simple. Actually, there are two ideas implemented there. First one, is when object itself is tagged for update, we tag its point cache component for evaluation, which makes it so point cache is properly reset. We do it implicitly because otherwise we'll need to go everywhere and add explicit tag in almost all the properties. Second thing is, we link all collider and force fields to a point cache component using special type of link. This type of link only allows flush if change is caused by a user update. This way reset does not happen when change is caused due to animation, but will properly happen when user causes indirect change to the objects which are part of physics simulation.
2018-11-14 11:24:54 +01:00
/* Adds relations from the given component of a given object to the given node
Depsgraph: Add utility function for transform dependency This is what modifiers are to use to indicate that they depend on a transformation of the object itself. Currently should be no functional changes, but in the future this will allow to easily change transform operation depending on whether there is a simulation associated with the object.
2019-02-12 12:01:17 +01:00
* handle AND the component to the point cache component of the node's ID. */
Depsgraph: Fix missing point cache reset when physics changes Among all the lines moved around, the general idea is quite simple. Actually, there are two ideas implemented there. First one, is when object itself is tagged for update, we tag its point cache component for evaluation, which makes it so point cache is properly reset. We do it implicitly because otherwise we'll need to go everywhere and add explicit tag in almost all the properties. Second thing is, we link all collider and force fields to a point cache component using special type of link. This type of link only allows flush if change is caused by a user update. This way reset does not happen when change is caused due to animation, but will properly happen when user causes indirect change to the objects which are part of physics simulation.
2018-11-14 11:24:54 +01:00
void DEG_add_object_pointcache_relation(struct DepsNodeHandle *node_handle,
struct Object *object,
eDepsObjectComponentType component,
const char *description);
Depsgraph: fixes for the eval_flags API behavior. - Use the original ID pointer for lookup in DEG_get_eval_flags_for_id. - When the flags change after a DEG rebuild, tag the object for update. - Instead of mixing int and short in different places, use uint32_t. This fixes text not updating when a Follow Curve reference is set.
2018-10-24 19:38:50 +03:00
void DEG_add_special_eval_flag(struct DepsNodeHandle *handle, struct ID *id, uint32_t flag);
Refactor CDData masks, to have one mask per mesh elem type. We already have different storages for cddata of verts, edges etc., 'simply' do the same for the mask flags we use all around Blender code to request some data, or limit some operation to some layers, etc. Reason we need this is that some cddata types (like Normals) are actually shared between verts/polys/loops, and we don’t want to generate clnors everytime we request vnors! As a side note, this also does final fix to T59338, which was the trigger for this patch (need to request computed loop normals for another mesh than evaluated one). Reviewers: brecht, campbellbarton, sergey Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
void DEG_add_customdata_mask(struct DepsNodeHandle *handle, struct Object *object, const struct CustomData_MeshMasks *masks);
Depsgraph: Add utility function to get depsgraph from node handle The idea is to use this function for modifiers' updateDepsgraph functions instead of doing direct scene->depsgraph access.
2017-06-12 14:41:46 +02:00
Depsgraph: Fix missing point cache reset when physics changes Among all the lines moved around, the general idea is quite simple. Actually, there are two ideas implemented there. First one, is when object itself is tagged for update, we tag its point cache component for evaluation, which makes it so point cache is properly reset. We do it implicitly because otherwise we'll need to go everywhere and add explicit tag in almost all the properties. Second thing is, we link all collider and force fields to a point cache component using special type of link. This type of link only allows flush if change is caused by a user update. This way reset does not happen when change is caused due to animation, but will properly happen when user causes indirect change to the objects which are part of physics simulation.
2018-11-14 11:24:54 +01:00
struct ID *DEG_get_id_from_handle(struct DepsNodeHandle *node_handle);
struct Depsgraph *DEG_get_graph_from_handle(struct DepsNodeHandle *node_handle);
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
/* ************************************************ */
#ifdef __cplusplus
} /* extern "C" */
#endif
#endif /* __DEG_DEPSGRAPH_BUILD_H__ */
Copy Permalink