| Age | Commit message (Collapse) | Author |
|---|
|
Also remove outdated comment.
|
|
Just showing the library override icon for every item doesn't add much
information, it's just redundant. Displaying the data-block type icon on
the other hand can be useful.
Differential Revision: https://developer.blender.org/D14208
|
|
This patch enables enables the outliner to use the correct icon for each
of the curve subtypes (Curve/Surface/Font).
Differential Revision: https://developer.blender.org/D14093
Reviewed by: Julian Eisel
|
|
Correct check for left-mouse event which assumed the alternative was
a tweak event.
Also remove print added by accident.
|
|
|
|
Something went wrong here in 61776befc3f8.
|
|
|
|
This operation can only be applied on one ID at a time, so only apply it
to the active Outliner item, and not all the selected ones.
Also renamed `Make Library Override` menu entry to `Make Library Override
Single` to emphasis this is not the 'default expected' option for the
user.
|
|
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.
|
|
Using flags makes checking multiple modifiers at once more convenient
and avoids macros/functions such as IS_EVENT_MOD & WM_event_modifier_flag
which have been removed. It also simplifies checking if modifier keys
have changed.
|
|
Reverts 6d97fdc37eef. A function like this should not return a different
tree-display object than of the requested type. This may hide errors,
and leaves the Outliner in an undefined state (where the stored display
mode doesn't match the tree-display object). I rather don't hide the
fact that all display-modes should be handled here, and emit a clear
error if one isn't.
|
|
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
|
|
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
|
|
Braces missed in b73d3b80fdcb72446
|
|
Now that proxy conversions if enforced, those operations are not useful
anymore.
Part of T91671.
|
|
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.
|
|
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.
|
|
Previously, macros were ifdefed using the cmake option `WITH_INTERNATIONAL`
However, the is unnecessary as withen the functions themselves have checks for building without internationalization.
This also means that many `add_definitions(-DWITH_INTERNATIONAL)` are also unnecessary.
Reviewed By: mont29, LazyDodo
Differential Revision: https://developer.blender.org/D13929
|
|
In Outliner, 'Make Override Hierarchy' on an indirectly linked data would
fail in case some items higher up in the hierarchy also needed to be
overridden was also indirectly linked.
|
|
In Outliner, 'Make Override Hierarchy' on an indirectly linked data would
fail in case some items higher up in the hierarchy also needed to be
overridden was also indirectly linked.
|
|
The `OUTLINER_OT_item_activate` operator, although it detects when
something changes, always returns `OPERATOR_FINISHED` and thus induces
the creation of undo steps.
So return `OPERATOR_CANCELLED` when nothing changes.
Ref T94080
Reviewed By: Severin
Maniphest Tasks: T94080
Differential Revision: https://developer.blender.org/D13638
|
|
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()`.
|
|
I prefer it this way around now, especially since I'm adding a
`getPointerRNA()` too. Good to keep it match the actual struct names.
|
|
Smaller cleanups to improve readability of a complex function.
|
|
Bug introduced in 7cbcfb7f492d.
|
|
Continuation of the previous commit, this time addressing the same for
RNA tree-elements.
|
|
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 sequences, strips and strip
duplicates.
|
|
Forgot to add these in 9bce134e56c2. Also tweaked assert to print a
message that was previously communicated via a comment only.
|
|
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.
|
|
During sprite fright loading of complex scenes would spend a long time in remapping ID's
The remapping process is done on a per ID instance that resulted in a very time consuming
process that goes over every possible ID reference to find out if it needs to be updated.
If there are N of references to ID blocks and there are M ID blocks that needed to be remapped
it would take N*M checks. These checks are scattered around the place and memory.
Each reference would only be updated at most once, but most of the time no update is needed at all.
Idea: By grouping the changes together will reduce the number of checks resulting in improved performance.
This would only require N checks. Additional benefits is improved data locality as data is only loaded once
in the L2 cache.
It has be implemented for the resyncing process and UI editors.
On an Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz 16Gig the resyncing process went
from 170 seconds to 145 seconds (during hotspot recording).
After this patch has been applied we could add similar approach
to references (references between data blocks) and functionality (tagged deletion).
In my understanding this could reduce the resyncing process to less than a second.
Opening the village production file between 10 and 20 seconds.
Flame graphs showing that UI remapping isn't visible anymore (`WM_main_remap_editor_id_reference`)
* Master {F12769210 size=full}
* This patch {F12769211 size=full}
Reviewed By: mont29
Maniphest Tasks: T94185
Differential Revision: https://developer.blender.org/D13615
|
|
This reverts commit 948211679f2a0681421160be0d3b90f507bc0be7.
This commit introduced some regressions in the test suite.
As this change is a core part of blender Bastien and I decided to revert
it as the solution isn't clear and needs more investigation.
The following tests FAILED:
62 - blendfile_liblink (SEGFAULT)
63 - blendfile_library_overrides (SEGFAULT)
It fails in (id_us_ensure_real)
|
|
During sprite fright loading of complex scenes would spend a long time in remapping ID's
The remapping process is done on a per ID instance that resulted in a very time consuming
process that goes over every possible ID reference to find out if it needs to be updated.
If there are N of references to ID blocks and there are M ID blocks that needed to be remapped
it would take N*M checks. These checks are scattered around the place and memory.
Each reference would only be updated at most once, but most of the time no update is needed at all.
Idea: By grouping the changes together will reduce the number of checks resulting in improved performance.
This would only require N checks. Additional benefits is improved data locality as data is only loaded once
in the L2 cache.
It has be implemented for the resyncing process and UI editors.
On an Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz 16Gig the resyncing process went
from 170 seconds to 145 seconds (during hotspot recording).
After this patch has been applied we could add similar approach
to references (references between data blocks) and functionality (tagged deletion).
In my understanding this could reduce the resyncing process to less than a second.
Opening the village production file between 10 and 20 seconds.
Flame graphs showing that UI remapping isn't visible anymore (`WM_main_remap_editor_id_reference`)
* Master {F12769210 size=full}
* This patch {F12769211 size=full}
Reviewed By: mont29
Maniphest Tasks: T94185
Differential Revision: https://developer.blender.org/D13615
|
|
Conversion of void* should not use the unsafe reinterp cast.
|
|
|
|
|
|
|
|
`TreeElement` isn't a trivial type anymore, so `MEM_delete()` should be
called, which calls the destructor.
AFAICS this would cause a memory leak, since the contained `unique_ptr`
is allocated but not destructed correctly - but it's not using the
guarded allocator so woudn't be reported.
|
|
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.
|
|
- modernize-deprecated-headers
- modernize-use-using
- modernize-use-nullptr
- modernize-use-bool-literals
|
|
Some of the message-bus macros are not safe to use in C++. This has come
up before, but no good solution was found. Now @LazyDodo, @HooglyBoogly
and I concluded this is the best duct tape "solution" for the moment.
The message-bus API should address this.
|
|
|
|
|
