| Age | Commit message (Collapse) | Author |
|---|
|
These functions used the term "find", which makes it sound like a lookup
callback, when in fact it would add elements to a set for further
processing. So use "collect" instead.
|
|
|
|
|
|
With C++ we should transition towards namespaces to avoid naming
collisions. Having the namespace in place is the first step for that
transition.
Plus, the `typedef` isn't necessary for struct/class/enum definitions
in C++, so avoid the verbosity it adds.
|
|
|
|
on Clear, general cleanup.
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.
|
|
When displaying the Hierarchies view of the Library Overrides display
mode in a specific Heist production file, Blender would become
unresponsive for about 30 seconds and every redraw in the Outliner would
lag noticably. Issue is that the sum of hierarchy elements is multiple
thousands, and that really brings the Outliner to its knees. I've looked
into some improvents and committed a few minor ones already, but it
seems it's really the big sum of elements causing the issue. There
doesn't appear to be a single bottle-neck.
To work around this, "lazy build" children, so that children of
collapsed elements are not actually created. This brings the tree
building down to some tens of miliseconds, and redrawing becomes
rather lag-free again, even with big parts of the tree un-collapsed.
Problem: Searching still needs to build the entire tree, so it's
essentially unusable right now. Should we disallow searching
altogether?
|
|
Makes the lazy-building (where children are only built when the parent
isn't collapsed) more generic, so more display modes can use it. So far
this was hardcoded for the "Data API" display mode.
This will be used to work around a big performance issue with the
Library Overrides Hierachies view in a complex production file, see
following commit.
|
|
When displaying the Hierarchies view of the Library Overrides display
mode in a specific Heist production file, Blender would become
unresponsive for about 30 seconds and every redraw in the Outliner would
lag noticably. Issue is that the sum of hierarchy elements is multiple
thousands, and that really brings the Outliner to its knees. I've looked
into some improvents and committed a few minor ones already, but it
seems it's really the big sum of elements causing the issue. There
doesn't appear to be a single bottle-neck.
To work around this, "lazy build" children, so that children of
collapsed elements are not actually created. This brings the tree
building down to some tens of miliseconds, and redrawing becomes
rather lag-free again, even with big parts of the tree un-collapsed.
Problem: Searching still needs to build the entire tree, so it's
essentially unusable right now. Should we disallow searching
altogether?
|
|
Makes the lazy-building (where children are only built when the parent
isn't collapsed) more generic, so more display modes can use it. So far
this was hardcoded for the "Data API" display mode.
This will be used to work around a big performance issue with the
Library Overrides Hierachies view in a complex production file, see
following commit.
|
|
|
|
collection.
|
|
This is unused, and I don't see a need for it.
|
|
- Turn storage into an object with "automatic" memory management (RAII)
so freeing is implicit and reliable.
- Turn functions into member functions, to have the data and its
functions close together with controlled access that increases
encapsulation and hiding implementation details.
- Use references to indicate null is not an expected value.
- Related minor cleanup (comments, use const etc.)
Couldn't spot any changes in performance.
|
|
This way you can benchmark the tree rebuilding by simply commenting out
a single line. Not that it was difficult before, but this makes it as
easy as it gets, with basically no knowledge of existing benchmarking
tools required.
|
|
|
|
Could lead to crahses in some cases, with outliner drawing code
accessing freed ID data in its tree.
|
|
Some performance issues were found here with a heavy production file and
we want to look into using some C++ to improve things for this ancient
code.
|
|
This is old code to keep track of an active search element, so you could
step through the search results. This isn't used anymore, and not needed
since searching now filters the tree to only show matches. If we ever
wanted to have support for stepping through elements again, that should be
done via the active element instead.
|
|
|
|
|
|
Move override creation into their own menu, add entries for reset and
clear operations.
|
|
|
|
Also add new outliner liboverride operators mapping to the manual,
though this is useless currently as this feature is not working in many
part of the UI, including the Outliner contextual menu.
|
|
Only object renaming was properly depsgraph-tagged, now all IDs (and
their sub-data like bones etc.) should be properly handled.
|
|
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
|
|
|
|
|
|
|
|
Conflicts:
source/blender/editors/space_outliner/outliner_tools.cc
|
|
Follow-up to design discussions here at the studio, add liboverride
operations into their own sub-menu, with three main entries:
- Create: Create, or enable for user editing, override hierarchies.
- Reset: Keep overrides data, but reset all local changes to the
reference linked data values.
- Clear: like reset, but also turn editable overrides back to system
overrides (aka non user editable).
Those three options can all operate either on the selected items, their
content only, or both.
Advanced operations are moved into a "Troubleshoot Hierarchy" sub-menu,
where one can resync, resync enforced, and fully delete library
overrides. Those operations always affect a whole override hierarchy,
regardless of which items are selected or not.
|
|
Conflicts:
source/blender/blenkernel/BKE_lib_override.h
|
|
Fix wrong assumption that 'embedded' IDs are only ever used by their
owners. This is especially not true with shape keys.
Also small optimization by adding an eraly abort when both IDs are the
same (i.e. an ID has a pointer to itself).
|
|
In some cases, there is a chance code already knows who might be the
owner of the given ID, in which case it can be more efficient to check
it first (especially in cases like embedded node trees or scene
collections, where the only other way is to loop over all possible
owners currently).
Will be used in next commit in some Outliner fix.
|
|
|
|
|
|
|
|
|
|
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
|
