| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The context menu would always show a section with "Select", "Deselect",
"Hide", "Unhide" and "Select Linked" if there were no more specific
operators to show (e.g. modifier operations). For many tree elements
they did not make sense and simply would do nothing. Only show the
section for supported types.
|
|
- Remove unnecessary calls to `get_element_operation_type()` (result
wasn't used).
- Remove branches/checks for cases that couldn't possibly happen.
(assert instead).
- Ensure all return arguments are set so caller can't make the mistake
of forgetting that.
- Early exit instead of big `if` block.
- Use `const`.
|
|
Essentially calls `IDTypeInfo->owner_get` for now, will make more sense
once the callback is changed to return the address of the pointer
instead.
|
|
Rename, add comments, and use flag in the depsgraph to ensure the logic
matches.
Differential Revision: https://developer.blender.org/D15883
|
|
Now that all embedded IDs have a loopback pointer to their owner, we do
need anymore extra parameters for this accessor.
|
|
|
|
The only difference between `GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR`
and `GPU_SHADER_3D_LINE_DASHED_UNIFORM_COLOR` is that in the vertex
shader the 2D version uses `vec4(pos, 0.0, 1.0)` and the 3D version
uses `vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
|
|
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
|
|
|
|
This patch is a cleanup required before refactoring the view layer syncing
process {T73411}.
* Remove FIRSTBASE.
* Remove LASTBASE.
* Remove BASACT.
* Remove OBEDIT_FROM_WORKSPACE.
* Replace OBACT with BKE_view_layer_active_object.
* Replace OBEDIT_FROM_VIEW_LAYER with BKE_view_layer_edit_object.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15799
|
|
|
|
Checks for 'invalid' selected IDs that need to be skipped were
incomplete, and one was missing the actual return statement.
|
|
|
|
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.
|
|
|
|
|
