| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
(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.
|
|
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.
|
|
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.
|
|
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.
|
|
Add blank lines after file references to avoid them being interpreted as
doc-strings the following declarations.
|
|
As proposed in T95802, this adds buttons to a new column on the right to modify
the override in the Library Override display mode. Some further usability
improvements are planned. E.g. this does not yet expand collections (modifiers,
constraints, etc) nicely or group modified properties of a modifier together.
Vector properties with more than 3 items or matrices aren't displayed nicely
yet, they are just squeezed into the column. If this actually becomes a problem
there are some ideas to address this.
Differential Revision: https://developer.blender.org/D14268
|
|
Passing a `TreeElement *` instead of its `TreeStoreElement *` to
`TSELEM_OPEN()` would seem to work but cause a bug. Add a type check
that will cause a compiler error if it fails.
|
|
For whatever reason the "in-view" check was using 2x the element height.
From what I can see this isn't needed, so I'll remove it in a follow-up
commit.
|
|
Restrict a lot deletion/moving around of liboverride objects and
collections in the Outliner.
While some of those operations may be valid in some specific cases, in
the vast majority of cases they would just end up breaking override
hierarchies/relationships.
Part of T95708/T95707.
|
|
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
|
|
The name `type` was confusing, since we usually use that in other ways.
Also updated the relating comments.
|
|
Long namespace qualifiers add visual noice and make code harder to read.
|
|
The `TreeElement.rnaptr` was only needed for RNA tree-elements. Now it
can be gotten through the new type specific classes, e.g.
`TreeElementRNAProperty.getPointerRNA()`.
|
|
Plan is to remove things like `TreeElement.directdata` and to instead
expose specific queries in the new type specific tree-element classes.
e.g. like here: `TreeElementSequence.getSequence()`
For now uses `tree_element_cast<>()` to get the new type specific
tree-element, later these should replace `TreeElement` all together.
|
|
Add function to safely request the type-specific C++ element from a
C-style `TreeElement`. Looks like this:
```
TreeElementFoo *te_foo = tree_element_cast<TreeElementFoo>(te);
```
The "cast" will return null if the tree-element doesn't match the
requested type.
This is useful for the transition from the C-style type to the new ones.
|
|
Continuation of work started in 2e221de4ceee and 249e4df110e0.
Adds new tree-element classes for RNA structs, properties and array
elements. This isn't exactly a copy and paste, even though logic should
effectively be the same. Further cleanups are included to share code in
a nice way, improve code with simple C++ features, etc.
|
|
Simplifies and makes things safer due to proper RAII usage.
|
|
Smart pointers should be the default choice for C++ owning pointers,
since they let you manage memory using RAII.
Also moved type factory methods into static class functions.
|
|
Basically this removes any C <-> C++ glue code. C++ types are accessed
directly via the public C++ APIs.
Contains some related changes like, moving functions that were
previously declared in a now removed header to a different file, whose
header is the more appropriate place (and the source file as well).
But generally I tried to avoid other changes.
|
|
Also ensure space at end of comment.
|
|
We want to refactor quite some of the Outliner code using C++, this is a
logical step to help the transition to a new architecture.
Includes plenty of fixes to make this compile without warnings, trying
not to change logic. The usual stuff (casts from `void *`, designated
initializers, compound literals, etc.).
|
