Those were only shallow wrappers around `BKE_id_copy`, barely used (even
fully unused in some cases), and we want to get rid of those ID-specific
helpers for the common ID management tasks. Also prevents weird custom
behaviors (like `BKE_object_copy`, who was the only basic ID copy
function to reset user count of the new copy to zero).
Part of 71219.
Besides the NodeTree case (which remains unchanged), the localize code
is only used in one place (to generate previews of shading data-blocks).
This commit introduces a new `LIB_ID_CREATE_LOCAL` option for ID
creation/copying, which essentially implements the behavior of the
removed `BKE_XXX_localize()` functions into regular mainstream ID copy
code. When this option is set:
- new ID is tagged with `LIB_TAG_LOCALIZED`;
- Some ID copying callbacks have specific behaviors, mainly the root
nodetree of shading IDs gets duplicated with specialized
`ntreeLocalize()` function.
Note that I would not consider getting rid of `ntreeLocalize` for now,
this function is recursive, which should ideally never happen within ID
management copying code (this introduces all kind of complications).
No behavioral change expected from this commit.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
Lamps were not tagged with `ID_RECALC_SHADING` when they were updated
from drivers. As a result, Cycles considered the lamp as unchanged. This
is resolved by having a (seemingly non-functional) callback in a new
`LIGHT_UPDATE` depsgraph node.
This patch unconditionally adds the `LIGHT_UPDATE` node + the relation
from the lamp's PARAMETERS node.
Differential Revision: https://developer.blender.org/D7822
Reviewed by: brecht
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
Instead of using anonymous booleans flags, also allows to keep the same
behavior in all cases, without needing special handling from calling
code for our beloved oddballs object proxies...
