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
blender-archive/source/blender/depsgraph/DEG_depsgraph_query.h

245 lines
8.8 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.
*/
/** \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 Querying and Filtering 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
*/
#ifndef __DEG_DEPSGRAPH_QUERY_H__
#define __DEG_DEPSGRAPH_QUERY_H__
#include "DEG_depsgraph.h"
#include "DEG_depsgraph_build.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
struct ID;
2017-05-18 16:16:23 +02:00
struct BLI_Iterator;
struct Base;
struct CustomData_MeshMasks;
struct Depsgraph;
struct DupliObject;
struct ListBase;
struct Scene;
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
/* *********************** DEG input data ********************* */
/* Get scene that depsgraph was built for. */
struct Scene *DEG_get_input_scene(const Depsgraph *graph);
/* Get view layer that depsgraph was built for. */
struct ViewLayer *DEG_get_input_view_layer(const Depsgraph *graph);
/* Get evaluation mode that depsgraph was built for. */
eEvaluationMode DEG_get_mode(const Depsgraph *graph);
/* Get time that depsgraph is being evaluated or was last evaluated at. */
float DEG_get_ctime(const Depsgraph *graph);
/* ********************* DEG evaluated 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
/* Check if given ID type was tagged for update. */
bool DEG_id_type_updated(const struct Depsgraph *depsgraph, short id_type);
bool DEG_id_type_any_updated(const struct Depsgraph *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
/* Get additional evaluation flags for the given ID. */
uint32_t DEG_get_eval_flags_for_id(const struct Depsgraph *graph, struct ID *id);
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
/* Get additional mesh CustomData_MeshMasks flags for the given object. */
void DEG_get_customdata_mask_for_object(const struct Depsgraph *graph,
struct Object *object,
struct CustomData_MeshMasks *r_mask);
/* Get scene the despgraph is created for. */
2018-01-17 12:26:43 +01:00
struct Scene *DEG_get_evaluated_scene(const struct Depsgraph *graph);
/* Get scene layer the despgraph is created for. */
2018-01-17 12:26:43 +01:00
struct ViewLayer *DEG_get_evaluated_view_layer(const struct Depsgraph *graph);
/* Get evaluated version of object for given original one. */
2018-01-17 12:26:43 +01:00
struct Object *DEG_get_evaluated_object(const struct Depsgraph *depsgraph,
struct Object *object);
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
/* Get evaluated version of given ID datablock. */
2018-01-17 12:26:43 +01:00
struct ID *DEG_get_evaluated_id(const struct Depsgraph *depsgraph,
struct ID *id);
Depsgraph: Initial groundwork for copy-on-write support < Dependency graph Copy-on-Write > -------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || This is an initial commit of Copy-on-write support added to dependency graph. Main priority for now: get playback (Alt-A) and all operators (selection, transform etc) to work with the new concept of clear separation between evaluated data coming from dependency graph and original data coming from .blend file (and stored in bmain). = How does this work? = The idea is to support Copy-on-Write on the ID level. This means, we duplicate the whole ID before we cann it's evaluaiton function. This is currently done in the following way: - At the depsgraph construction time we create "shallow" copy of the ID datablock, just so we know it's pointer in memory and can use for function bindings. - At the evaluaiton time, the copy of ID get's "expanded" (needs a better name internally, so it does not conflict with expanding datablocks during library linking), which means the content of the datablock is being copied over and all IDs are getting remapped to the copied ones. Currently we do the whole copy, in the future we will support some tricks here to prevent duplicating geometry arrays (verts, edges, loops, faces and polys) when we don't need that. - Evaluation functions are operating on copied datablocks and never touching original datablock. - There are some cases when we need to know non-ID pointers for function bindings. This mainly applies to scene collections and armatures. The idea of dealing with this is to "expand" copy-on-write datablock at the dependency graph build time. This might introduce some slowdown to the dependency graph construction time, but allows us to have minimal changes in the code and avoid any hash look-up from evaluation function (one of the ideas to avoid using pointers as function bindings is to pass name of layer or a bone to the evaluation function and look up actual data based on that name). Currently there is a special function in depsgraph which does such a synchronization, in the future we might want to make it more generic. At some point we need to synchronize copy-on-write version of datablock with the original version. This happens, i.e., when we change active object or change selection. We don't want any actual evaluation of update flush happening for such thins, so now we have a special update tag: DEG_id_tag_update((id, DEG_TAG_COPY_ON_WRITE) - For the render engines we now have special call for the dependency graph to give evaluated datablock for the given original one. This isn't fully ideal but allows to have Cycles viewport render. This is definitely a subject for further investigation / improvement. This call will tag copy-on-write component tagged for update without causing updates to be flushed to any other objects, causing chain reaction of updates. This tag is handy when selection in the scene changes. This basically summarizes ideas underneath this commit. The code should be reasonably documented. Here is a demo of dependency graph with all copy-on-write stuff in it: https://developer.blender.org/F635468 = What to expect to (not) work? = - Only meshes are properly-ish aware of copy-on-write currently, Non-mesh geometry will probably crash or will not work at all. - Armatures will need similar depsgraph built-time expansion of the copied datablock. - There are some extra tags / relations added, to keep things demo-able but which are slowing things down for evaluation. - Edit mode works for until click selection is used (due to the selection code using EditDerivedMesh created ad-hoc). - Lots of tools will lack tagging synchronization of copied datablock for sync with original ID. = How to move forward? = There is some tedious work related on going over all the tools, checking whether they need to work with original or final evaluated object and make the required changes. Additionally, there need synchronization tag done in fair amount of tools and operators as well. For example, currently it's not possible to change render engine without re-opening the file or forcing dependency graph for re-build via python console. There is also now some thoughts required about copying evaluated properties between objects or from collection to a new object. Perhaps easiest way would be to move base flag flush to Object ID node and tag new objects for update instead of doing manual copy. here is some WIP patch which moves such evaluaiton / flush: https://developer.blender.org/F635479 Lots of TODOs in the code, with possible optimization. = How to test? = This is a feature under heavy development, so obviously it is disabled by default. The only reason it goes to 2.8 branch is to avoid possible merge hell. In order to enable this feature use WITH_DEPSGRAPH_COPY_ON_WRITE CMake configuration option.
2017-06-14 10:26:24 +02:00
/* Get evaluated version of data pointed to by RNA pointer */
void DEG_get_evaluated_rna_pointer(const struct Depsgraph *depsgraph,
struct PointerRNA *ptr,
struct PointerRNA *r_ptr_eval);
/* Get original version of object for given evaluated one. */
struct Object *DEG_get_original_object(struct Object *object);
/* Get original version of given evaluated ID datablock. */
struct ID *DEG_get_original_id(struct ID *id);
/* ************************ DEG object iterators ********************* */
2017-04-21 11:42:59 +02:00
enum {
DEG_ITER_OBJECT_FLAG_LINKED_DIRECTLY = (1 << 0),
DEG_ITER_OBJECT_FLAG_LINKED_INDIRECTLY = (1 << 1),
DEG_ITER_OBJECT_FLAG_LINKED_VIA_SET = (1 << 2),
DEG_ITER_OBJECT_FLAG_VISIBLE = (1 << 3),
DEG_ITER_OBJECT_FLAG_DUPLI = (1 << 4),
};
typedef struct DEGObjectIterData {
struct Depsgraph *graph;
int flag;
struct Scene *scene;
Cycles: Support rendering objects from dupli-list This commit extends the work from Dalai made around scene iterators to support iterating into objects from dupli-lists. Changes can be summarized as: - Depsgraph iterator will hold pointer to an object which created current duplilist. It is available via `dupli_parent` field of the iterator. It is only set when duplilist is not NULL and guaranteed to be NULL for all other cases. - Introduced new depsgraph.duplis collection which gives a more extended information about depsgraph iterator. It is basically a collection on top of DEGObjectsIteratorData. It is used to provide access to such data as persistent ID, generated space and so on. Things which still needs to be done/finished/clarified: - Need to introduce some sort of `is_instance` boolean property which will indicate Python and C++ RNA that we are inside of dupli-list. - Introduce a way to skip dupli-list for particular objects. So, for example, if we are culling object due to distance we can skip all objects it was duplicating. - Introduce a way to skip particular duplicators. So we can skip iterating into particle system. - Introduce some cleaner API for C side of operators to access all data such as persistent ID and friends. This way we wouldn't need de-reference iterator and could keep access to such data really abstract. Who knows how we'll be storing internal state of the operator in the future. While there is still stuff to do, current state works and moves us in the proper direction.
2017-06-06 13:58:40 +02:00
eEvaluationMode eval_mode;
Cycles: Support rendering objects from dupli-list This commit extends the work from Dalai made around scene iterators to support iterating into objects from dupli-lists. Changes can be summarized as: - Depsgraph iterator will hold pointer to an object which created current duplilist. It is available via `dupli_parent` field of the iterator. It is only set when duplilist is not NULL and guaranteed to be NULL for all other cases. - Introduced new depsgraph.duplis collection which gives a more extended information about depsgraph iterator. It is basically a collection on top of DEGObjectsIteratorData. It is used to provide access to such data as persistent ID, generated space and so on. Things which still needs to be done/finished/clarified: - Need to introduce some sort of `is_instance` boolean property which will indicate Python and C++ RNA that we are inside of dupli-list. - Introduce a way to skip dupli-list for particular objects. So, for example, if we are culling object due to distance we can skip all objects it was duplicating. - Introduce a way to skip particular duplicators. So we can skip iterating into particle system. - Introduce some cleaner API for C side of operators to access all data such as persistent ID and friends. This way we wouldn't need de-reference iterator and could keep access to such data really abstract. Who knows how we'll be storing internal state of the operator in the future. While there is still stuff to do, current state works and moves us in the proper direction.
2017-06-06 13:58:40 +02:00
/* **** Iteration over dupli-list. *** */
/* Object which created the dupli-list. */
struct Object *dupli_parent;
/* List of duplicated objects. */
struct ListBase *dupli_list;
Cycles: Support rendering objects from dupli-list This commit extends the work from Dalai made around scene iterators to support iterating into objects from dupli-lists. Changes can be summarized as: - Depsgraph iterator will hold pointer to an object which created current duplilist. It is available via `dupli_parent` field of the iterator. It is only set when duplilist is not NULL and guaranteed to be NULL for all other cases. - Introduced new depsgraph.duplis collection which gives a more extended information about depsgraph iterator. It is basically a collection on top of DEGObjectsIteratorData. It is used to provide access to such data as persistent ID, generated space and so on. Things which still needs to be done/finished/clarified: - Need to introduce some sort of `is_instance` boolean property which will indicate Python and C++ RNA that we are inside of dupli-list. - Introduce a way to skip dupli-list for particular objects. So, for example, if we are culling object due to distance we can skip all objects it was duplicating. - Introduce a way to skip particular duplicators. So we can skip iterating into particle system. - Introduce some cleaner API for C side of operators to access all data such as persistent ID and friends. This way we wouldn't need de-reference iterator and could keep access to such data really abstract. Who knows how we'll be storing internal state of the operator in the future. While there is still stuff to do, current state works and moves us in the proper direction.
2017-06-06 13:58:40 +02:00
/* Next duplicated object to step into. */
struct DupliObject *dupli_object_next;
/* Corresponds to current object: current iterator object is evaluated from
* this duplicated object. */
Cycles: Support rendering objects from dupli-list This commit extends the work from Dalai made around scene iterators to support iterating into objects from dupli-lists. Changes can be summarized as: - Depsgraph iterator will hold pointer to an object which created current duplilist. It is available via `dupli_parent` field of the iterator. It is only set when duplilist is not NULL and guaranteed to be NULL for all other cases. - Introduced new depsgraph.duplis collection which gives a more extended information about depsgraph iterator. It is basically a collection on top of DEGObjectsIteratorData. It is used to provide access to such data as persistent ID, generated space and so on. Things which still needs to be done/finished/clarified: - Need to introduce some sort of `is_instance` boolean property which will indicate Python and C++ RNA that we are inside of dupli-list. - Introduce a way to skip dupli-list for particular objects. So, for example, if we are culling object due to distance we can skip all objects it was duplicating. - Introduce a way to skip particular duplicators. So we can skip iterating into particle system. - Introduce some cleaner API for C side of operators to access all data such as persistent ID and friends. This way we wouldn't need de-reference iterator and could keep access to such data really abstract. Who knows how we'll be storing internal state of the operator in the future. While there is still stuff to do, current state works and moves us in the proper direction.
2017-06-06 13:58:40 +02:00
struct DupliObject *dupli_object_current;
/* Temporary storage to report fully populated DNA to the render engine or
* other users of the iterator. */
struct Object temp_dupli_object;
2018-09-21 10:07:57 +02:00
/* **** Iteration over ID nodes **** */
size_t id_node_index;
size_t num_id_nodes;
} DEGObjectIterData;
void DEG_iterator_objects_begin(struct BLI_Iterator *iter, DEGObjectIterData *data);
void DEG_iterator_objects_next(struct BLI_Iterator *iter);
void DEG_iterator_objects_end(struct BLI_Iterator *iter);
2017-04-21 11:42:59 +02:00
/**
* Note: Be careful with DEG_ITER_OBJECT_FLAG_LINKED_INDIRECTLY objects.
* Although they are available they have no overrides (collection_properties)
* and will crash if you try to access it.
*/
#define DEG_OBJECT_ITER_BEGIN(graph_, instance_, flag_) \
{ \
DEGObjectIterData data_ = { \
graph_, \
flag_, \
}; \
\
ITER_BEGIN(DEG_iterator_objects_begin, \
DEG_iterator_objects_next, \
DEG_iterator_objects_end, \
&data_, Object *, instance_)
#define DEG_OBJECT_ITER_END \
ITER_END; \
}
2017-04-21 11:42:59 +02:00
/**
2019-03-19 15:17:46 +11:00
* Depsgraph objects iterator for draw manager and final render
*/
#define DEG_OBJECT_ITER_FOR_RENDER_ENGINE_BEGIN(graph_, instance_) \
DEG_OBJECT_ITER_BEGIN(graph_, instance_, \
DEG_ITER_OBJECT_FLAG_LINKED_DIRECTLY | \
DEG_ITER_OBJECT_FLAG_LINKED_VIA_SET | \
DEG_ITER_OBJECT_FLAG_VISIBLE | \
DEG_ITER_OBJECT_FLAG_DUPLI)
#define DEG_OBJECT_ITER_FOR_RENDER_ENGINE_END \
DEG_OBJECT_ITER_END
/* ************************ DEG ID iterators ********************* */
typedef struct DEGIDIterData {
struct Depsgraph *graph;
bool only_updated;
size_t id_node_index;
size_t num_id_nodes;
} DEGIDIterData;
void DEG_iterator_ids_begin(struct BLI_Iterator *iter, DEGIDIterData *data);
void DEG_iterator_ids_next(struct BLI_Iterator *iter);
void DEG_iterator_ids_end(struct BLI_Iterator *iter);
/* ************************ DEG traversal ********************* */
typedef void (*DEGForeachIDCallback)(ID *id, void *user_data);
/* NOTE: Modifies runtime flags in depsgraph nodes, so can not be used in
* parallel. Keep an eye on that!
*/
void DEG_foreach_ancestor_ID(const Depsgraph *depsgraph,
const ID *id,
DEGForeachIDCallback callback, void *user_data);
void DEG_foreach_dependent_ID(const Depsgraph *depsgraph,
const ID *id,
DEGForeachIDCallback callback, void *user_data);
void DEG_foreach_ID(const Depsgraph *depsgraph,
DEGForeachIDCallback callback, void *user_data);
/* ********************* DEG graph filtering ****************** */
/* ComponentKey for nodes we want to be able to evaluate in the filtered graph */
typedef struct DEG_FilterTarget {
struct DEG_FilterTarget *next, *prev;
struct ID *id;
/* TODO: component identifiers - Component Type, Subdata/Component Name */
} DEG_FilterTarget;
typedef enum eDEG_FilterQuery_Granularity {
DEG_FILTER_NODES_ALL = 0,
DEG_FILTER_NODES_NO_OPS = 1,
DEG_FILTER_NODES_ID_ONLY = 2,
} eDEG_FilterQuery_Granularity;
typedef struct DEG_FilterQuery {
/* List of DEG_FilterTarget's */
struct ListBase targets;
/* Level of detail in the resulting graph */
eDEG_FilterQuery_Granularity detail_level;
} DEG_FilterQuery;
/* Obtain a new graph instance that only contains the subset of desired nodes
* WARNING: Do NOT pass an already filtered depsgraph through this function again,
* as we are currently unable to accurately recreate it.
*/
Depsgraph *DEG_graph_filter(const Depsgraph *depsgraph, struct Main *bmain, DEG_FilterQuery *query);
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_QUERY_H__ */