... for Grease Pencil & Curves
Was only moving the points relative to the origin (so only they stayed
in place, handles were still transformed along with the origin).
In order to fix this this, we now take into account curves handles in
the whole `XFormObjectData` related code (for both Grease Pencil &
Curves). There was a handly existing pair of functions
[`curves::bezier::retrieve_all_positions` &
`curves::bezier::write_all_positions`] which we can use for Curves, for
Grease Pencil this uses code from those functions (but not the functions
directly -- indices would fail there because Grease Pencil would call
this from multiple layers).
This also introduces `BKE_grease_pencil_has_curve_with_type` so we can
know in advance how many elements we need for the
`XFormObjectData_GreasePencil`.
Also corrects a typo in c1c67c918e (swapping `XFormObjectData_Curves`
with `XFormObjectData_GreasePencil`)
Pull Request: https://projects.blender.org/blender/blender/pulls/138665
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
This is re-apply of PR !138982 was backed out in cef7cb4534 due to
Win x64 buildbot failure. The error was:
```
view3d_navigate_view_all.cc(321): error C2672: 'blender::bounds::transform_bounds': no matching overloaded function found
view3d_navigate_view_all.cc(322): error C2784: 'blender::Bounds<blender::VecBase<T,3>> blender::bounds::transform_bounds(const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &,const blender::Bounds<blender::VecBase<T,3>> &)': could not deduce template argument for 'const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &' from 'const blender::float4x4'
```
which has nothing whatsoever to do with the PR. But something
in the PR (i.e. rename of a completely unrelated enum entries)
presumably makes this specific VS2019 compiler version not be
able to resolve template argument type. Again, in completely
unrelated file with completely unrelated types.
So "the fix" is to help VS2019 compiler in that place by explicitly
specifying the template types. What exactly in the original
change triggers the issue, remains a mystery. "It is known" that
VS2019 is quite funky in template argument deduction, maybe this
is one of these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/138995
This commit adds a toggle functionality to the `brush.asset_activate`
operator that makes it behave similarly to the `paint.brush_select`
parameter of the same name.
When the operator has this option enabled, using the operator or
pressing the relevant key will either:
* Activate the specified brush and store it if the current brush does
not match the specified brush
* Activate the previously stored brush if it exists.
This option is exposed in the keymaps and enabled by default for the
Sculpt Mask brush.
This allows, for example, users to press 'M' to switch to the mask brush
and then press 'M' again to switch back to their previously active
brush.
Partially addresses this RCS submission: [1]
[1] https://blender.community/c/rightclickselect/1VwZ/
---
### Notes
This commit does not currently clear the `AssetWeakReference` when switching paint modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/138845
Neither value was being cleared when the active vert was cleared,
leading to an invalid state where we could have no active vertex but an
active face or grid index.
Pull Request: https://projects.blender.org/blender/blender/pulls/138963
File under #138795 showed several issues, which, while investigating
them, led to also fixing some other issues.
- FBX files can contain non-bone nodes in between actual bone nodes
("fake bones" as they used to be called in Python importer). Handling
this case was missing in the new importer.
- Due to above, some armatures had what appeared like multiple
"root bones" inside them, which led to crashes while importing
animations.
- Meshes with multiple armature modifiers (multiple skin deformers
in FBX) were not handled correctly, see
https://projects.blender.org/blender/blender-addons/issues/45171
for when the same issue was fixed in the Python importer.
Extended test coverage to encompass the above.
Pull Request: https://projects.blender.org/blender/blender/pulls/138992
Similar to b51229f5fd.
The asset editing API would allow deleting any .blend file that was
linked via the same API, even if it was not created & managed by the API
itself but by the user.
All users of the API had sufficient other checks, so in practice it
wouldn't happen. Still make sure the API is safe to use without
requiring the caller to perform extra checks.
The asset editing API wouldn't check if the file it's writing to is
known to be managed by the asset editing API itself, and therefore
writable by the API. So the API could potentially lead to custom blend
files getting overridden.
To be clear, all users of the API had sufficient other checks, so in
practice it wouldn't happen. Still make sure the API is safe to use
without requiring the caller performing extra checks.
Gizmos that contain 3D wire parts, like the rounded lines of the
"Rotate" gizmo, have a fairly small hit size that make it hard to grab,
especially with tablet pens. This PR just increases the width of these
lines during the (invisible) selection process. This is done in such ability
way that it could be increased in the future for touch if needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/138406
Currently, `columnselect_action_keys` gets "raw" non-NLA-mapped keyframe
data via `ANIM_fcurve_keyframes_loop` with the `bezt_to_cfraelem` callback,
so the list of `CfraElem` contains frames in "local" FCurve space.
Later, this would be (rightfully) NLA-unmapped to "local/strip" time, because
this is what `ANIM_editkeyframes_ok(BEZT_OK_FRAME)` expects, it also only
compares "raw" `BezTriple` data.
But this only makes sense if we would store "global/scene" frame data in
`CfraElem` `cfra` already.
This is what we now do, let `bezt_to_cfraelem` perform the NLATIME_CONVERT_MAP
Pull Request: https://projects.blender.org/blender/blender/pulls/138937
invert button doesn't work quite well when `filter_items()` is used in
UIList (eg. workspace, attributes list). First issue is, when search
string is empty and invert button is pressed, none item is shown. Now
fixed with extra condition of `filter_byname[0]`. Another issue is when
search string is non-empty then invert button should show elements that
doens't match with the string but it doesn't work. This occurs due to
filtering elements twice. First inside
`filter_items_by_name(reverse=true)` then `UI_list_item_index_is_filtered_visible`.
Remove `UILST_FLT_EXCLUDE` so only once the items are filtered with
invert condition.
Noticed this during !138756
Pull Request: https://projects.blender.org/blender/blender/pulls/138761
Add new rna property that sets `UILST_FLT_ITEM_NEVER_SHOW` Flag for
internal attributes. This avoids internal attributes from showing in the
list with invert button is enabled, see: `UI_list_item_index_is_filtered_visible`
Pull Request: https://projects.blender.org/blender/blender/pulls/138756
Reworks the implementation for how knots are interpreted when importing
NURBS in .obj format. It refactors each test into a separate function
and simplifies functions using a 'multiplicity sequence' which counts
repeated occurances of knot values (or their 'multiplicity'). Making
comparisons simpler, clearer, and with improved correctness.
With regard to regression tests behavior is almost the same, noticable
difference is consideration of cyclic. Allowing curves with multiplicity
at the endpoints to be cyclic (so Bezier curves can be cyclic given
one repeated point). Untested behavior may also have been 'refined'
(changed), but additional tests would be needed to identify those cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/138778
Currently the depsgraph is re-evaluated between every parent operation
when parenting multiple objects. This patch evaluates it only once and
does all the parenting after.
Since it is most of the work, this makes a big difference in large-ish
files. For example, re-parenting 400 objects in a 4000 object file goes
from 10 seconds to a few tens of milliseconds.
I'm definitely not familiar enough with blender internals and all possible
situations to know if this is actually safe or not.
Pull Request: https://projects.blender.org/blender/blender/pulls/138616
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
Pull Request: https://projects.blender.org/blender/blender/pulls/138982
Refactor `Action::slot_remove`: implemented iteration over
`strip_keyframe_data_array` and direct calling
`StripKeyFrameData::slot_data_remove()`. Also removed
`Strip::slot_data_remove()` as well as `Layer::slot_data_remove` as it
had no usages after refactoring.
Fixes: #137095
Pull Request: https://projects.blender.org/blender/blender/pulls/138343
Armature bone display mode (Octahedral, Stick, Envelope, B-Bone,
Wire) could only be set on the whole armature. This adds ability to
override the display mode per-bone (by default bones use the
same display mode as the armature).
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/138445
No functional changes intended.
This moves the functions
* ANIM_bone_is_visible
* ANIM_bone_is_visible_ebone
* ANIM_bone_is_visible_pchan
into new files `ANIM_armature.hh`/`armature.cc`.
They were previously in `ANIM_bone_collections.hh` but don't
directly have anything to do with bone collections.
It also puts the functions into the `blender::animrig::` namespace
and removes the `ANIM_` prefix as is the standard for C++ files.
Part of #138482
Pull Request: https://projects.blender.org/blender/blender/pulls/138833
Our IME input system relied on passing around pointers to global variables.
However this will not work as the Wayland input handling is multithreaded so the content of the global variable would change while the event loop were reading the data.
Pull Request: https://projects.blender.org/blender/blender/pulls/138871
This adds support for the extension and always
set the clip state value to 0..1 to align with vulkan
and metal. Moreover this is needed for the Reverse Z
implementation.
Note that this is a OpenGL 4.5 feature and is not
required to start Blender. So there must still be
a fallback path for now.
Rel #138898
Pull Request: https://projects.blender.org/blender/blender/pulls/138941
No functional changes intended.
This adds `typedef`s for the enums used by Shape Keys.
Doing so makes it clear what kind of values are stored
under the `flag` and `type` fields.
Also adding/cleaning-up comments that various functions
in `key.cc` can be changed to a `switch/case`.
In preparation for #136838
Pull Request: https://projects.blender.org/blender/blender/pulls/138595
At this point, with pen tilt functionality having received the following
changes recently:
* Consistency between platforms for what pen tilt values represent
* Inactive cursor visualization
* Invertable per-brush strength
The majority of the work that remains is wider testing and addressing
per-device issues, thus it makes sense to make this option available in
release builds.
By default, no brushes packaged with Blender have a non-zero Tilt
Strength, making this option opt-in by default.
The following brushes support this option:
* Draw
* Draw Sharp
* Flatten
* Fill
* Scrape
* Plane
* Clay Strips
With a non-zero Tilt Strength value on the brush, the normal of the
brush plane is tilted in the same direction as the user's pen, where a
perpendicular orientation for the pen matches the behavior with a Tilt
Strength of 0.
Resolves#82877
Pull Request: https://projects.blender.org/blender/blender/pulls/137574
* Shift call to the Draw Face Set brush implementation as it is
irrelevant for other brushes.
* Instead of checking for the first brush step, check to see if the
value is still `SCULPT_FACE_SET_NONE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138949
The drawing of the background of panel categories is out by one pixel,
but was covered by the area borders until recently. This PR just draws
one pixel more to the edge.
Pull Request: https://projects.blender.org/blender/blender/pulls/138956
This converts the public `uiItemMenuF` and `uiItemMenuFN`
functions to an object oriented API (an `uiLayout::menu_fn`
and `uiLayout::menu_fn_argN_free` respectively), following
recent uiLayout changes.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138902
Currently, there was a lot of boilerplate to compute the compute context hash.
Now, the complexity is abstracted away to make it a simple function call.
Furthermore, this makes the compute context hash generation lazy. The goal here
is to make it very cheap to construct the compute context hash in the first,
while making it a little bit more expensive (still quite cheap overall) to
access the hash when any data has to be logged. This trade-off makes sense when
we want to pass the compute context to more lower-level places in order to be
able to create better error messages with more contextual information. For
example, we'd want to create error messages during multi-function evaluation
which happens during field evaluation within a node.
Pull Request: https://projects.blender.org/blender/blender/pulls/138912
This implements a new operator that automatically fits the width of a column to
its content. It's triggered by double-clicking on the column edge in the header
row. This is common functionality in other spreadsheet software.
Pull Request: https://projects.blender.org/blender/blender/pulls/138924
Currently, removing a node frame a frame is rather annoying. The `alt+P`
shortcut is hard to reach and probably not very intuitive. Furthermore, often
one only notices that one wants to remove a node from a frame after starting to
move the node. So one would have to put the node back down, detach it from the
frame and then start moving again.
This patch simplifies this entire process by adding a new shortcut that can be
used while dragging nodes. When `F` is pressed, the selected nodes are detached
from their parents. Alternatively, if the nodes are detached already, they may
be attached to the frame under the cursor.
Pull Request: https://projects.blender.org/blender/blender/pulls/138650
Currently, the steps required to add a named frame in the node editor are quite
cumbersome:
* Press ctrl+J, which is hard to reach.
* Press F2, to rename.
This is bad, because frames are a key part of making node trees understandable.
Therefore, we should lower the barrier to adding them as much as possible.
Additionally, named frames help significantly more with readability. Therefore,
it's good to lower the barrier to adding those even more. Of course it's still
possible to click in empty space to avoid having to give a frame a name.
This patch adds a new operator to join nodes in a named frame. When triggered,
it adds the frame and automatically opens the rename menu to set the name.
Keymap changes:
* Remove `ctrl+J` which was creating a frame without label.
* Move existing functionality of `F` key to `J` key
(including `shift+F -> shift+J`).
* Use `F` for this new operator to create a named frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/138390
Replace `DRW_Attributes` with a VectorSet of std::string. The max number of
attributes is still the same. The inline buffer size is 4, and std::string's inline
buffer is smaller than the previous char array size of 64, but it seems
reasonable to save those optimizations for shorter attribute names and
fewer attributes. In return we significantly decrease the size of the batch
caches, simplify the code, and remove the attribute name length limit.
I observed roughly an 8% increase in the 30k cube objects file, a change from
12 to 13 FPS. I'm guessing this is mostly because `VectorSet<std::string>` is
smaller than `DRW_Attributes`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138946
Regression caused by #138433
Somehow the lazy nature of the is_linear and is_srgb got lost in
the refactor and the fields were greedily initialized on startup
and it is not a cheap operation.
Pull Request: https://projects.blender.org/blender/blender/pulls/138945
