This renames the `BKE_gpencil_*` as well as the `DNA_gpencil_types.h`
files to indicate that it's the legacy grease pencil.
Pull Request: blender/blender#105597
This renames the `OB_GPENCIL` object type and the `ID_GD` to `OB_GPENCIL_LEGACY` and `ID_GD_LEGACY` respectively.
There is no change for the user.
Pull Request: blender/blender#105541
Currently there's no way to assign a geometry node group from the asset
browser to an object as a modifier without first appending/linking it
manually. This patch adds a drag and drop operator that adds a new
modifier and assigns the dragged tree.
Pull Request #104430
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
When the active selected object in the 3DView is already a local
liboverride, only perform the 'clear system flag' process on selected
objects, there is no point in trying to create an override out of it.
This crash occurs when the bone is newly created. In certain
circumstances the depsgraph data for the armature is not updated,
causing `pchan_eval` to be NULL when the parent is updated. This causes
a segfault in `ED_object_parent_set` when the flags are updated.
This change fixes the underlying depsgraph bug, and also adds both an
assertion and NULL pointer check to `ED_object_parent_set` to better
handle this scenario if it recurs via another path.
Maniphest Tasks: T94441
Differential Revision: https://developer.blender.org/D16065
When a change happens which invalidates view layers the syncing will be postponed until the first usage.
This will improve importing or adding many objects in a single operation/script.
`BKE_view_layer_need_resync_tag` is used to tag the view layer to be out of sync. Before accessing
`BKE_view_layer_active_base_get`, `BKE_view_layer_active_object_get`, `BKE_view_layer_active_collection`
or `BKE_view_layer_object_bases` the caller should call `BKE_view_layer_synced_ensure`.
Having two functions ensures that partial syncing could be added as smaller patches in the future. Tagging a
view layer out of sync could be replaced with a partial sync. Eventually the number of full resyncs could be
reduced. After all tagging has been replaced with partial syncs the ensure_sync could be phased out.
This patch has been added to discuss the details and consequences of the current approach. For clarity
the call to BKE_view_layer_ensure_sync is placed close to the getters.
In the future this could be placed in more strategical places to reduce the number of calls or improve
performance. Finding those strategical places isn't that clear. When multiple operations are grouped
in a single script you might want to always check for resync.
Some areas found that can be improved. This list isn't complete.
These areas aren't addressed by this patch as these changes would be hard to detect to the reviewer.
The idea is to add changes to these areas as a separate patch. It might be that the initial commit would reduce
performance compared to master, but will be fixed by the additional patches.
**Object duplication**
During object duplication the syncing is temporarily disabled. With this patch this isn't useful as when disabled
the view_layer is accessed to locate bases. This can be improved by first locating the source bases, then duplicate
and sync and locate the new bases. Will be solved in a separate patch for clarity reasons ({D15886}).
**Object add**
`BKE_object_add` not only adds a new object, but also selects and activates the new base. This requires the
view_layer to be resynced. Some callers reverse the selection and activation (See `get_new_constraint_target`).
We should make the selection and activation optional. This would make it possible to add multiple objects
without having to resync per object.
**Postpone Activate Base**
Setting the basact is done in many locations. They follow a rule as after an action find the base and set
the basact. Finding the base could require a resync. The idea is to store in the view_layer the object which
base will be set in the basact during the next sync, reducing the times resyncing needs to happen.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15885
Related to {D15885} that requires scene parameter
to be added in many places. To speed up the review process
the adding of the scene parameter was added in a separate
patch.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15930
From the 3DView code has basically no knowledge of collection hierarchy,
so we can either not remap any local usage of linked objects that are
being overridden, or remap them in all their local collections.
The second behavior makes most sense in the vast majority of cases.
Note that this was only an issue when directly linking and overriding
objects, not when doing so through collections.
Inconsistencies in update/tagging code between different code doing the
same 'Clear. liboverride operation lead to crashes in some cases.
Unify deg tagging and WM notifiers accross the three editor-level
codepaths performing the common Make/Reset/Clear operations.
Preserve if possible the active object accross Clear operation.
Several cleanup/rename/re-arangement of code to make it more consistent.
Affected by rB8621fdb10dc4
Crash if single-user data is created when we apply transform
on multi-user image data. Crash occurs because creation of new copy
was not handled in `single_obdata_users` for empty objects (image for example)
Reviewed By: dfelinto, mont29
Maniphest Tasks: T100040
Differential Revision: https://developer.blender.org/D15587
Curves that are attached to a surface can now follow the surface when
it is modified using shape keys or modifiers (but not when the original
surface is deformed in edit or sculpt mode).
The surface is allowed to be changed in any way that keeps uv maps
intact. So deformation is allowed, but also some topology changes like
subdivision.
The following features are added:
* A new `Deform Curves on Surface` node, which deforms curves with
attachment information based on the surface object and uv map set
in the properties panel.
* A new `Add Rest Position` checkbox in the shape keys panel. When checked,
a new `rest_position` vector attribute is added to the mesh before shape
keys and modifiers are applied. This is necessary to support proper
deformation of the curves, but can also be used for other purposes.
* The `Add > Curve > Empty Hair` operator now sets up a simple geometry
nodes setup that deforms the hair. It also makes sure that the rest
position attribute is added to the surface.
* A new `Object (Attach Curves to Surface)` operator in the `Set Parent To`
(ctrl+P) menu, which attaches existing curves to the surface and sets the
surface object as parent.
Limitations:
* Sculpting the procedurally deformed curves will be implemented separately.
* The `Deform Curves on Surface` node is not generic and can only be used
for one specific purpose currently. We plan to generalize this more in the
future by adding support by exposing more inputs and/or by turning it into
a node group.
Differential Revision: https://developer.blender.org/D14864
This is temporary to investigate which behavior should be kept when
creating an override hierarchy if there are no cherry-picked data
defined: make all overrides user-editable, or not.
This removes the 'make override - fully editable' menu entries.
This commit:
* Removes the popup to choose the root collection when called with a
linked object selected (in typical cases there is only one valid
option, if more then the operator fails and report to the user).
* Ensures that the linked reference of newly overridden collections are
also removed from the ViewLayer (i.e. their local parent collections).
Add the following macros for enums as support for these features wasn't
all that obvious and there were some inconsistencies in their use.
- RNA_ENUM_ITEM_HEADING(name, description)
- RNA_ENUM_ITEM_SEPR
- RNA_ENUM_ITEM_SEPR_COLUMN
8f79fa9c67 was an attempt to fix this already, but it didn't quite
work. Problem was that the tooltip was messing with the drop-box and
operator properties, setting the name property for its own internal
logic. This name property would then be used rather than the session
UUID to query the material, which gave the wrong material (linking can
result in multiple IDs of the same type with the same name). A followup
commit will further sanitize this.
More and more of the drop operations are being switched to use the ID's
session UUID rather than the name, but the cleanup after a drop operator
was cancelled assumed they would set the name. They will now first
attempt to use the session UUID and fallback to the name if needed.
917c096be6 applied to objects only, this also applies the same fix for
the general 3D View drop operations, e.g. used for dragging materials,
images, worlds, etc.
This is needed to fix T95706, but apparently something else is still
going on. Needs further investigation.
Avoids having to manually enable data-blocks for user-edition when you
do not care about what should be edited by whom. Similar to default
behavior before introduction of system overrides (aka non-user-editable
overrides).
Inherited from older versions of the code, not needed anymore in most
common cases (like making override from a local empty instantiating a
collection, or if the active object is directly overridable).
**Relevant to Artists:** This patch adds an option to the Parenting
menu, `Object (Keep Transform Without Inverse)`, and Apply menu, `Parent
Inverse`. The operators preserve the child's world transform without
using the parent inverse matrix. Effectively, we set the child's origin
to the parent. When the child has an identity local transform, then the
child is world-space aligned with its parent (scale excluded).
**Technical:** In both cases, the hidden parent inverse matrix is
generally set to identity (cleared or "not used") as long as the parent
has no shear. If the parent has shear, then this matrix will not be
entirely cleared. It will contain shear to counter the parent's shear.
This is required, otherwise the object's local matrix cannot be properly
decomposed into location, rotation and scale, and thus cannot preserve
the world transform.
If the child's world transform has shear, then its world transform is
not preserved. This is currently not supported for consistency in the
handling of shear during the other parenting ops: Parent (Keep
Transform), Clear [Parent] and Keep Transform. If it should work, then
another patch should add the support for all of them.
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D14581
The current behaviour is to prevent multi-user data from having its
modifier applied.
Instead, with this patch, we now warn the user that if they want to
proceed the object will be made single-user.
Note that this only makes the object data single-user. Not the material
or actions.
As a future step we can apply the same behaviour for the Grease Pencil modifiers
Differential Revision: https://developer.blender.org/D14381
Add new `BKE_id_is_editable` helper in `BKE_lib_id.h`, that supercedes
previous check (simple `ID_IS_LINKED()` macro) for many editing cases.
This allows to also take into account 'system override' (aka
non-editable override) case.
Ref: {T95707}.
Implement default behavior to decide which overrides remain 'system'
ones, and which become 'user editable' ones, when creating hierarchy
override from 3DView or the Outliner.
3DView:
If from an Empty-instanced collection, only Armature objects in
that collection are user overrides.
If from a set of selected objects, all overrides created from selected
objects are user overrides.
Outliner:
All override IDs created from selected elements in the Outliner are user
overrides.
There is one special case: When a collection is selected, and is
'closed' in the outliner, all its inner armature objects are also user
overrides.
Ref: {T95707}.
This affects essentially the Outliner 'create hierarchy' tool currenlty.
Previously code did not handle properly hierarchy root in case overrides
where created from a non-root ID (e.g. an object inside of a linked
collection), and in case additional partial overrides were added to an
existing partially overrided hierarchy.
Also did some renaming on the go to avoid using 'reference' in override
context for anything else but the reference linked IDs.
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
This will help when dealing with liboverrides from other library files,
e.g for resync or proxies conversion.
This commit only affects proxy conversion.
Part of T91671.
Do not allow 3DView operator to run on the liboverride of an
instantiating Empty object. And tweak behavior in the Outliner
operations too.
Related to T94226.
Note that this remains fairly exotic, bad idea not recommended cases,
such complex inter-dependencies between different libraries inside a
same liboverride hierarchy is just not possible to handle properly.
Outliner would frame the armature object instead of the bone if the bone
was on a hidden armature layer.
Similar to issues reported in e.g. T58068 and T80464, this is due to the
fact that `BKE_pose_channel_active` always checks for the armature layer
(and returns NULL if a bone is not on a visible armature layer).
Now propose to make this layer check **optional** (and e.g. from the
Outliner be more permissive). This also introduces
`BKE_pose_channel_active_if_layer_visible` which just wraps
`BKE_pose_channel_active` with the check being ON.
Maniphest Tasks: T92930
Differential Revision: https://developer.blender.org/D13154
