The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
The graph editor supports an Extend transformation mode, which is
essentially Move that only affects keyframes either before or
after the current frame, based on the mouse cursor position.
This fixes a bug in this mode where it doesn't respect the snap setting.
- Improve the look of them, so they feel less like from year
1998 (more details and images in the PR).
- Some of the scopes got slightly faster in the process, others
stayed the same performance (details below).
- Remove VSE Scopes related data from SpaceSeq DNA, move it into
runtime instead.
Rename `ANIM_bonecoll_is_visible(armature, bone)` to
`ANIM_bone_in_visible_collection(armature, bone)`, as that reflects the
actual functionality.
No functional changes.
The issue was that the "Affect" options from the 3D viewport
were also used for the Graph Editor.
This was discussed in the Animation & Rigging module meeting.
https://devtalk.blender.org/t/2023-12-21-animation-rigging-module-meeting/32748
The consensus was that the Animation Editors should have their own copy of the "Affect" flags.
For this commit I opted for a more immediate solution that ignores the "Affect" flag in the animation editors.
The adding of the flag can be left for a feature PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/116781
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
The issue occurs when auto-keyframe AND "Only Insert Needed" enabled.
And only when no keyframes have been added yet.
Before the commit that caused the issue, moving an object with `G` would
create only location keyframes. After it would key all.
That is because that commit removed the logic that checks the
`eTfmMode` (Transform mode). That only works as long as there are already
keyframes on the object/bone because the logic needs an
existing value to compare against. In the case where the first keyframe is set,
it would always key everything.
The fix is to bring back the logic that checks the Transform mode and pass
a `Span` of rna paths to the autokeyframe function. This restores the behavior.
This still has the issue that "Only Insert Needed" behaves differently if
keys exist vs inserting the first keys. While this isn't ideal, I don't see a way
to get values of an object/bone before and after the transformation.
We might be able to fix this in a future PR, but for now we restore the
old behavior.
Caused by #115522
Pull Request: https://projects.blender.org/blender/blender/pulls/116219
Except for vertex groups and a few older color types, these
are generally replaced by newer generic attribute types.
Also remove some includes of DNA_mesh_types.h, since it's
included indirectly by BKE_mesh.hh currently.
Remove most includes of this header inside other headers, to remove unnecessary
indirect includes which can have a impact on compile times. In the future we may
want more dedicated "_fwd.hh" headers, but until then, this sticks with the
solution in existing code.
Unfortunately it isn't yet possible to remove the include from `BKE_geometry_set.hh`.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
Caused by 9c2e768f5b
Since above commit, drawing of the normal is not done in
`ED_view3d_cursor_snap_draw_util` anymore [that function checked the
existence of a valid target location], now add the check back.
Pull Request: https://projects.blender.org/blender/blender/pulls/116292
`float4x4` requires 16 byte alignment. The compiler can add padding
within the struct, but the allocation needs to know about the alignment
too. Fix by using an allocation function that handles this properly.
Prior to this PR, the autokeying system used keying sets
to insert keyframes where required.
With the functions introduced in #113504
the code can be simplified and made to not rely on keying sets,
allowing autokeying to also insert keys by rna path directly.
This also removes all the code related to "Insert Needed" from autokeying.
The insert key functions deal with that now, all that is needed is to pass
in the flag.
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/115522
The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
These shouldn't be called in hot loops at all, and mostly aren't
anymore anyway. Definining them outside of a header allows removing
the `BKE_customdata.hh` include from `BKE_mesh.hh`.
Continuation of fix for #115776. Removes attribute copy functions
that calculate the map inline, this is error prone as it's easy to
call these functions from a loop which may result in poor performance.
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
Apparently this problem has existed at least since b6b61681ef.
When converting pointers to generic structs in
`transform_convert_action.cc`, elements of type `TransData` and
`TransData2D` must align by maintaining synchronized indices within
their respective arrays.
Despite both arrays having equivalent lengths, some `TransData2D`
instances were omitted when they come from types `ANIMTYPE_GPLAYER` or
`ANIMTYPE_MASKLAYER`.
This misalignment resulted in `TransData` elements not properly
corresponding with their `TransData2D` counterparts.
A potential fix could be incrementing `td2d++` for each
`ANIMTYPE_GPLAYER` or `ANIMTYPE_MASKLAYER` occurrence. This approach,
while introducing blank `TransData2D` entries, would preserve index
alignment with `TransData`.
However, I opted for a less workaround-centric approach by converting
`tGPFtransdata` elements into `TransData2D`.This solution, albeit
slightly fragile due to the lack of a dedicated member in `TransData2D`
for integer value flushing, appears better than allowing blank
`TransData2D` fields.
Move the contents of `ANIM_bone_collections.h` into its C++
`ANIM_bone_collections.hh` sibling. Blender is C++ by now that we can do
without the C header.
No functional changes.
`ED_view3d_win_to_ray_clipped_ex` requires `ray_end` when
`do_clip_planes` is true.
Since the snap code uses `ray_depth` instead of `ray_end`, the solution
is to always calculate the `ray_end` and convert to `ray_depth` when
necessary.
Implement the next phases of bounds improvement design #96968.
Mainly the following changes:
Don't use `Object.runtime.bb` for performance caching volume bounds.
This is redundant with the cache in most geometry data-block types.
Instead, this becomes `Object.runtime.bounds_eval`, and is only used
where it's actually needed: syncing the bounds from the evaluated
geometry in the active depsgraph to the original object.
Remove all redundant functions to access geometry bounds with an
Object argument. These make the whole design confusing, since they
access geometry bounds at an object level.
Use `std::optional<Bounds<float3>>` to pass and store bounds instead
of an allocated `BoundBox` struct. This uses less space, avoids
small heap allocations, and generally simplifies code, since we
usually only want the min and max anyway.
After this, to avoid performance regressions, we should also cache
bounds in volumes, and maybe the legacy curve and GP data types
(though it might not be worth the effort for those legacy types).
Pull Request: https://projects.blender.org/blender/blender/pulls/114933
