| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
NOTE: This is committed to the 3.3 branch as decided by Bastien, Dalai
and me. That is because these are important usability fixes/improvements
to have for the LTS release.
Part of T95802.
Showing properties with an RNA path in the UI isn't very user friendly.
Instead, represent the RNA path as a tree, merging together parts of the
RNA path that are shared by multiple properties. Properties and "groups"
(RNA structs/pointers) are now shown with their UI name and an icon if
any. The actually overridden properties still show the Library Overrides
icon. See the patch for screenshots.
Also: When a RNA collection item, like a modifier or constraint was
added via a library override, indicate that item and show all collection
items in the list, since the complete list of items and their orders may
be important context.
Differential Revision: https://developer.blender.org/D15606
|
|
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
No user visible changes expected.
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
We have a bunch of "base" element types, just to show a label element
for grouping together other elements. There is no reason to have these
tied to a case, just have a generic label type for this. It requires a
string to display, and can display an icon too. The new element type
isn't used yet, but will be in one of the following commits. Would be
nice if the existing base elements can be replaced by this.
Part of D15606.
|
|
Part of T95802.
Showing properties with an RNA path in the UI isn't very user friendly.
Instead, represent the RNA path as a tree, merging together parts of the
RNA path that are shared by multiple properties. Properties and "groups"
(RNA structs/pointers) are now shown with their UI name and an icon if
any. The actually overridden properties still show the Library Overrides
icon. See the patch for screenshots.
Also: When a RNA collection item, like a modifier or constraint was
added via a library override, indicate that item and show all collection
items in the list, since the complete list of items and their orders may
be important context.
Differential Revision: https://developer.blender.org/D15606
|
|
No user visible changes expected.
Adds a function that prints the "path" of an element, that is, the
ancestor elements starting from the root, separated by slashes. This can
be useful for debugging. The function isn't used.
|
|
No user visible changes expected.
We have a bunch of "base" element types, just to show a label element
for grouping together other elements. There is no reason to have these
tied to a case, just have a generic label type for this. It requires a
string to display, and can display an icon too. The new element type
isn't used yet, but will be in one of the following commits. Would be
nice if the existing base elements can be replaced by this.
Part of D15606.
|
|
|
|
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
|
|
- Assert that one of the thwo branches in
`id_override_library_create_hierarchy` are always processed.
- Init success value regardless.
|
|
This commit allows to select several data-blocks in the outliner and
create overrides from all of them, not only the active one.
It properly creates a single hierarchy when several IDs from a same
hierarchy root data are selected.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D15497
|
|
names/basenames/suffixes
An implementation of T73412, roughly as outlined there:
Track the names that are in use, as well as base names (before
numeric suffix) plus a bit map for each base name, indicating which
numeric suffixes are already used. This is done per-Main/Library,
per-object-type.
Timings (Windows, VS2022 Release build, AMD Ryzen 5950X):
- Scene with 10k cubes, Shift+D to duplicate them all: 8.7s -> 1.9s.
Name map memory usage for resulting 20k objects: 4.3MB.
- Importing a 2.5GB .obj file of exported Blender 3.0 splash scene
(24k objects), using the new C++ importer: 34.2s-> 22.0s. Name map
memory usage for resulting scene: 8.6MB.
- Importing Disney Moana USD scene (almost half a million objects):
56min -> 10min. Name map usage: ~100MB. Blender crashes later on
when trying to render it, in the same place in both cases, but
that's for another day.
Reviewed By: Bastien Montagne
Differential Revision: https://developer.blender.org/D14162
|
|
overrides.
The outliner would tagg all existing local IDs (for remap from linked
reference data to newly created overrides) when creating a new override.
This would become critical issue in case there is several existing
copies of the same override hierarchy (leading to several hierarchies
using the same override).
Further more, BKE override creation code would not systematically
properly remapp linked usages to new overrides one whithin the affected
override hierarchy, leading to potential undesired remaining usages of
linked data.
|
|
We would first invoke the dragging, and then set the drag data (like the
ID or the dragged modifier), so the `wmDropBox.on_drag_start()` handler
wouldn't be able to access this. This broke dragging some IDs from the
Outliner, noticed in D15333.
It's now possible to first create/request drag data, extend it, and then
invoke the actual dragging. The normal function to start dragging
returns `void` now instead of `wmDrag *`, so the drag data can't easily
be modified after starting anymore.
|
|
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.
|
|
Because children point to, or "use" their parent, the Library Overrides
Hierarchies mode in the Outliner would show parents contained in children, not
children contained in a parent. See D15339 for pictures.
In production files this would make the rig listed under all its children, so
it would appear many times in the tree. Now it appears once and the children
are collected under it.
Refactors the tree building, so instead of using
`BKE_library_foreach_ID_link()`, it now uses the ID relations mapping in
`MainIDRelations`.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15339
|
|
|
|
Usual same issue with outliner operations, where you apply it on one
item, and then try to apply it again on same item listed somewhere else
in the tree...
Fixed by using the 'multi-tagged deletion' code we now have for IDs,
that way tree-walking function just tags IDs for deletion, and they all
get deleted at once at the end.
|
|
|
|
Previously, it would show "Link inside collection" but move between collections
instead in some cases. Additionally there was no tooltip for the "Link before/
after/between collections" case.
Behavior and tooltip should now be consistent in all cases.
Differential Revision: https://developer.blender.org/D15237
|
|
Mainly duplicate includes and else after return.
|
|
of the Outliner.
Regression from recent rB717ab5aeaecc.
|
|
Error in a4a7af47326.
To allow deleting tree elements while iterating, the new iterators would
get needed data out of the tree element before calling the iterator
callback. This included the info if the element is open or collapsed. So
if the callback would open or collapse elements, the iterator wouldn't
respect that change. Luckily the way the open/collapsed state is stored,
we can still query it after the callback is executed, without having to
access the (possibly freed) tree element.
|
|
The callback would just assume that it's only called on materials, which
may in fact not be the case. It could also be called for other ID types
and layer collections (see `outliner_do_libdata_operation()`). Properly
check this now.
Also avoid faling silently when the object or object-data to unlink from
couldn't be determined. Report this to the user. Operators that just do
nothing are confusing.
|
|
This issue was only exposed by ba49345705a3. The ID pointer of the
material's parent tree-element wasn't actually pointing to an ID, but to
the list-base containing the IDs. It was just unlikely to cause issues
in practice, although an assert was thrown.
Just don't do anything if the object or object-data to unlink the
material from could not be found. The following commit will introduce a
error message about this.
|
|
Before this, we would build the sub-trees of some elements, just to
remove them afterwards. In big files, this would sometimes build ten
thousands of elements unnecessarily. Now support not building those
sub-trees in the first place.
Performance tests in a Sprite Fright production file (release build):
- View Layer display mode, reduced Outliner tree rebuilding from ~45ms
to 12-17ms
- Library Overrides display mode, Hierarchies view, reduced tree
rebuilding from 5-6s(!) to 220ms
|
|
override' ones in the Outliner.
Conceptually animated/driven properties are not controlled by the
liboverride system anymore, even though they may generate override
operations. So consider them as part of the 'system overrides' category,
and hide them by default in the Outliner.
|
|
`BKE_lib_override_rna_property_find`.
Very useful e.g. for dealing with FCurves search.
|
|
Some operators OR'ed the existing flags in a way that made it seem
the value might already have some values set.
Replace this with assignment as no flags are set and the convention
with almost all operators is to write the value directly.
|
|
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
|
|
When launching Blender with a script creating a screenshot, the Outliner
tree wasn't initialized and built properly. That is because at this
stage, all visible regions were only tagged for a non-rebuild redraw,
not a full redraw. So ensure all regions are tagged for a full redraw
immediately after file reading. Usually the full redraw would be caused
by a file-read notifier, but the Python expression/script is executed
before notifiers are handled.
Note that even before this was crashing, the Outliner would be empty in
the created screenshot.
Additionally adds an assert to the Outliner to note assumptions
explicitly, rather than crashing later.
|
|
Uses the macro introduced in b45f410b315 where it makes sense.
|
|
|
|
IPO data-block types are deprecated since 2.5. Don't show them in the
Outliner at all.
Differential Revision: https://developer.blender.org/D15049
|
|
(Not meant to cause user visible changes.)
Makes use of the new iterators introduced in the previous commit. Some
benefits:
- Shorter, simpler, easier to read & understand
- Deduplicates logic
- Centralizes iteration logic, making it easier to replace tree storage
(as planned), see previous commit.
- Avoids having to pass (sub-)tree to iterate around (often redundant
since it's just `SpaceOutliner.tree`, even though `SpaceOutliner` is
already passed).
- Function arguments that are only passed to the recursive call are
recognized as unused (found and removed a few).
Also does some general cleanups while refactoring the code for the
iterators. Use `const`, use references (signals null is not expected),
early-exit (see 16fd5fa656af), remove redundant arguments, etc.
|
|
(Not meant to cause user visible changes.)
Adds some first new iterators to traverse over tree elements with a
functional syntax. Functional because it meant to be used with C++
lambdas.
For example, this common pattern:
```lang=cpp
void some_recursive_function(SpaceOutliner *space_outliner, ListBase *tree, ...)
{
LISTBASE_FOREACH (TreeElement *, te, tree) {
/* ... do something with the element ... */
/* Recurse into open children. */
if (TSELEM_OPEN(TREESTORE(te), space_outliner) {
some_recursive_function(&te->subtree, ...);
}
}
}
```
Gets simplified to this:
```lang=cpp
void some_function(SpaceOutliner &space_outliner, ...)
{
tree_iterator::all_open(space_outliner, [&](TreeElement *te) {
/* ... do something with the element ... */
});
}
```
We can add more iterators, e.g. some that support early exiting or
skipping children, returning a custom type, only act on selected
elements, etc.
The following commit will convert a bunch of code to use these. Some
further benefits will become visible there. Not all cases are straight
forward to convert, but hopefully more and more code can be refactored
to work with this. This deduplicates and centralizes the iteration
logic, which will later make it much easier to refactor how the tree
storage is done (e.g. move it to `SpaceOutliner_Runtime` and use a
better container than `ListBase`).
|
|
Design is to have warnings in the sub-tree of a collapsed element show
up next to the collapsed element. But if inside the collapsed element,
there was a uncollapsed one containing yet another element with a
warning, that warning wouldn't "bubble up" to the collapsed parent.
Issue was that the warning lookup would only recurse into collapsed
elements, rather than all elements inside of a collapsed element.
While the actual fix for this could've been simpler, I decided to rework
this code entirely. Recursively querying the warning message is now done
separately from drawing the message once found, which makes the code
easier to follow and implements the single responsibility principle
better.
|
|
Library overrides were basically using their own system to display
warnings for tree elements, even though for other display elements we
have a more general solution. With the previous commit this has been
generalized further and made trivial to extend.
|
|
Uses a inheritance based approach for querying warning of tree elements
and the mode column support of display modes.
For the warnings, tree elements can override the
`AbstractTreeElement::getWarning()` method and return a warning string.
The UI will draw the warning column with warning icons. This makes the
warning column more generalized and easier to extend to more use-cases.
E.g. library override elements will use this after a followup commit.
To support mode toggles a display mode can now just return true in the
`AbstractTreeDisplay::supportsModeColumn()` method. This makes it
trivial to add mode columns to other display modes, and less error prone
because there's no need to hunt down a bunch of display mode checks in
different places.
|
|
by default.
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).
|
|
This reverts commit 30534deced8dad16c566dd82db3edd462283de13.
After discussion and feedback from users, it's better to keep this tool
available until there is time to properly re-think the whole Outliner's
contextual menu.
|
|
Replace some `if/else if` chains by proper `switch` statement.
Replace some `BLI_assert(0)` calls by `BLI_assert_unreachable()` ones.
|
|
|
|
|
|
We cannot try to get RNA info when the rna path of an override property
is invalid.
|
|
This feature is very advanced, and the way it was exposed in the
Outliner was very confusing at best.
It remains available through the Python API (`ID.user_remap`) e.g.
|
|
This was historically the only way to change/fix paths of library files
in Blender. However, only changing the path then required a manual
reload of the library, which could be skipped by user, or a save/reload
of the working .blend file, which could lead to corruption of advanced
library usages like overrides.
Prefferred, modern way to change path of a library is to use the
Relocate operation instead. Direct path modification remains possible
through RNA (python console or the Data API view in the Outliner.
|
|
These were missing in "Blender File" view.
before
{F13053175}
after
{F13053176}
Differential Revision: https://developer.blender.org/D14859
|
