These are not fully supported, users who load these will not be able
to access all the faces within the TTC/OTC.
Existing uses of TTC/OTC won't be blocked, these are just not shown as
supported fonts in the file selector. Addresses #44254.
Ref !121060
Both vertexpaint and weightpaint would only apply all of radial symmetry
for the "initial stroke".
When going over the combinations of symmetry axis, some of radial
symmetry would be skipped, e.g. when mirroring from right to left with
`Mirror X` turned ON, a dab on the right would have radial symmetry from
that point, and an additional dab on the left from mirroring (but the
mirrored dab would not have radial symmetry on its own).
This does not lead to symmetric results at all, sculptmode also does not
behave that way (there, radial symmetry is performed on the mirror axis
as well).
Now do the same thing as in sculptmode to get symmetric results when
using mirror and radial symmetry together.
Also use the utility function to skip invalid symmetry iterations.
Stumbled over this when looking into #120843
Pull Request: https://projects.blender.org/blender/blender/pulls/120931
While using texture on the brush in vertex paint mode (neither generated
or imported texture), the brush texture is sampled based off of the
unmirrored coordinate.
To resolve, use the same method that sculptmode uses in
`sculpt_apply_texture` (flipping the coordinate over the mirror axis).
Pull Request: https://projects.blender.org/blender/blender/pulls/120935
Previously, the track axis would remain X on the other side. It should
be flipped to -X to give a symmetrical result.
Building upon ee43cf5722, this adds support for flipping the track
axis in certain constraints, namely:
- Track To
- Locked Track
- Damped Track
- Shrinkwrap
Pull Request: https://projects.blender.org/blender/blender/pulls/120979
Exposed by 6c774feba2
`BM_mesh_decimate_dissolve_ex` sets up `DelimitData` with layer offset
(start), size and end so that `bm_edge_is_contiguous_loop_cd_all` can
check a range of edges for being contiguous.
The way `cd_loop_offset_end` is calculated is wrong though, it does not
take the actual start into account (this has to be added to fix the
bug). When it is wrong, it can happen that start and end are the same,
so no check actually takes place and no delimiting edges are found.
It seems that prior to 6c774feba2 the customdata layer always had an
offset of zero, so never really showed in practice (at least I couldnt
make it break in 3.4), but after 6c774feba2 we can at least observe the
following:
- when creating a bmesh, an offset would to the uv layer would still be
zero in my tests
- however, as soon as we iterate loops of a face (as done in the
report), we get an additional layer `CD_BM_ELEM_PYPTR`
- this then changes the offset
- `BM_uv_map_get_offsets_from_layer` seems to do the right thing afaict
So to resolve, just add the "start" offset to the end, to get the right
range.
NOTE: there is a very similar `DelimitData` used in
`bmesh.ops.join_triangles` and the way in which `bm_edge_delimit_cdata`
sets up te range is exactly like what this PR proposes.
Pull Request: https://projects.blender.org/blender/blender/pulls/121033
While additional context is typically useful to include,
this is such a corner-case that it's not expected script authors
would run into this during regular development.
Since the flood fill callback uses FunctionRef now, there is no need to pack
the relevant arguments into a separate struct. Though there are a lot of
arguments now, there is one less indirection which hels when clicking
through the code.
Building with clang on windows isn't an officially supported scenario
but it's something we'd like to keep working, but as it doesn't see
regular use, things tend to bit rot a bit.
0136289cb6 got things back into somewhat working order however the build
log came in at a little over 5.5GiB emitting a total of 11.787.294
warnings (827.847 unique), it was getting to the point where printing
all warnings, was a rather significant contributor to the total build
time.
this PR, suppress every single warning out of that build, one could
argue that some of these warnings are actually genuine and should be
enabled, and dealt with, the thing is, building with clang isn't
supported as of now and I honestly lack the time right now to sift
though this barrage of data.
given MSVC, Clang on mac and GCC on linux currently all build without
warnings, having clang on windows match that baseline seems like a
reasonable thing to do.
I left some notes in cmake flagging the potential cleanup, and added
counts of how often each warn occurred (The one off warns are much more
likely to lead to a genuine bug fix than the ones that produce a whole
lot of noise) so if someone wants to spend some effort they can do so
effectively.
The suppression is guarded with clang on windows specific guard and
should not affect any other platforms.
Pull Request: https://projects.blender.org/blender/blender/pulls/121085
This implements all the sculpt tools in Grease Pencil 3.
UI changes in the 3D view header and keymap entries for sculpt mode are
still minimal, more entries should be added once the relevant operators
are supported.
A set of utility functions and a shared base class
`GreasePencilStrokeOperationCommon` for sculpt operations has been added
to make individual operations less verbose.
The `GreasePencilStrokeParams` struct bundles common arguments to reduce
the amount of boilerplate code. The `foreach_editable_drawing` utility
function takes care of setting up the parameters and finding the right
drawings, so the tool only has to modify the data. Common features like
tracking mouse movement and inverting brush influence are handled by the
common base class.
Most operations are then relatively simple, with the exception of the
Grab and Clone operations.
- __Grab__ stores a stroke mask and weights on initialization of the
stroke, rather than working with the usual selection mask.
- __Clone__ needs access to the clipboard, which requires exposing the
clipboard in the editor API.
Pull Request: https://projects.blender.org/blender/blender/pulls/120508
Moving a constant variable results in a copy occurring instead. This
looks to have been an accidental change as part of ea937b304d.
A few tools will warn about this:
`Warning C26478 Don't use std::move on constant variables. (es.56)`
`Warning cpp:S5415 "std::move" should not be called on a const object.`
Pull Request: https://projects.blender.org/blender/blender/pulls/121063
This PR changes the `swap_handles` variable of the
`BeztMap` from `short` to `bool`.
The only reason it was a `short` was so that 0 could be
interpreted as "not checked" within the sorting loop.
Instead, I moved the checking for swapping to a separate loop.
That means the `BeztMap` array needs to be traversed one more time,
but given sorting might already do that multiple times that won't be
a performance issue
(plus we don't have the `if` within the sorting loop potentially messing up branch prediction).
In addition to that this PR also removes `prev_ipo` and
`current_ipo` from the `BeztMap` struct. Those were never used.
This is also partly a fix to restore 3.6 behavior.
With the move to C++, `swap_handles` was never initalized,
so the logic ` if (bezm->swap_handles == 0)` would always be false.
That resulted in the following behavior when
**rotating a bunch of keys 180deg** around their common center.
Pull Request: https://projects.blender.org/blender/blender/pulls/121076
The previous implementation was not considering each
channel magnitude, which was not rotationally
invariant. This fixes changes in lighting as the world
rotates (and if clamping is enabled).
This fixes the slightly incorrect solid angle by using
the symetries of the mapping. This avoids orientation
dependent lighting. The computation is not much more
expensive.
This PR adds the feature of displaying which property is modified
to the slider GUI.
This is useful in cases like #117287
where the slider can modify different properties during the modal operation.
The string is optional and will be empty by default.
This label is placed to the left of the slider where the percentage was usually located.
The percentage has now been moved to the right.
Pull Request: https://projects.blender.org/blender/blender/pulls/119920
This PR implements the Weight Paint tools for GPv3.
Tools:
- Draw, for assigning weight to stroke points
- Blur, smooths out weight using adjacent stroke point weights
- Average, smooths weight using the average weight under the brush
- Smear, like finger painting, drags weights in the direction of the brush
- Sample weight, sets the brush weight to the weight under the cursor
The weights are assigned to the active vertex group. When there is no
active vertex group, a group is automatically created.
When the Auto Normalize option is enabled, it is ensured that all
bone-deforming vertex groups add up to the weight of 1.0.
When a vertex group is locked, it's weights will not be altered by
Auto Normalize.
The PR already supports multi frame editing, including the use of a
falloff (defined by a curve).
The implementation is in accordance with the Weight Paint tools in GPv2.
Pull Request: https://projects.blender.org/blender/blender/pulls/118347
All callers except for one were already checking, add ATTR_NONNULL
attribute to functions that take a FileData to make it clear that
it's not expected to be null.
This reverts part of 36cda3b3116acba3b895daf68689f8af01b62392
and replaces the use of `OB_MODE_PAINT_GREASE_PENCIL`
`OB_MODE_PAINT_GPENCIL_LEGACY` flag instead.
The `OB_MODE_PAINT_GREASE_PENCIL` is removed.
The `GREASE_PENCIL_OT_draw_mode_toggle` operator is removed
and the `GPENCIL_OT_paintmode_toggle` operator is adapted to
work with GPv3.
Pull Request: https://projects.blender.org/blender/blender/pulls/121027
The drawing code in the Graph Editor reduces the points drawn by checking the pixel distance.
The calculation for the pixel distance didn't take the normalization into account though, so
in certain scenarios points would be skipped that shouldn't be skipped.
The fix is to pass the normalization factor into the pixel distance calculation.
Pull Request: https://projects.blender.org/blender/blender/pulls/121070
This adds a new `Handles` checkbox to the conversion operator that
affects how the conversion works in the following cases:
`Bezier -> Catmull Rom / Poly / Nurbs` and `Catmull Rom -> Nurbs`.
If enabled, three control points are added for each original control
point, otherwise only one.
-----
The images show the effect of the toggle. The top result is always the one with handles and the bottom one without.
* `Bezier -> Poly`
* `Bezier -> Catmull Rom`
* `Bezier -> Nurbs`
* `Catmull Rom -> Nurbs`
Pull Request: https://projects.blender.org/blender/blender/pulls/120423
Dangling reroute nodes have no source of value. For that reason, such reroute nodes
are ignored by geometry nodes. Other node systems still have to handle this case
more explicitly. To users this behavior generally makes sense, but it's also not completely
obvious. Now, there is a new tooltip when hovering over dangling reroute nodes that
mentions how those work.
Pull Request: https://projects.blender.org/blender/blender/pulls/120851
There was no check for a convex hull with 1-2 points,
causing unwrap to crash on degenerate faces.
Regression caused by [0] (fix for #115061), which hid this bug.
[0]: 0053de6556
Previously when opening 2 images like `['img1.png' ,'img002.png']` the
sequence detection will open this images as a single image sequence.
However internally this is not a supported sequence.
To fix that this changes will also differentiate sequences
by their digit count, so if a group of images like:
`['img1.png','img2.png' ,'img002.png','img003.png']`
are open now it will create 2 images sequences instead of just one.
Ref: !120185
