Color the interpolation icons matching the new interpolation theme
settings added in 75eaecf350
This makes a clearer connection with the lines drawn in Dope Sheet.
See PR for details and screenshots.
Pull Request: https://projects.blender.org/blender/blender/pulls/148215
This PR increases the points shown on the Curve Mapping widget a bit,
with the selected ones ever larger. This is more in line with what we
saw in 4.5. This also draws the points with AA by changing to a
different shader - which means drawing the selected ones separate from
the unselected ones.
Pull Request: https://projects.blender.org/blender/blender/pulls/148176
Blender 5.0 got a theme overhaul, removing hundreds of options and
adding some more. While versioning was attempted to keep themes
looking as close as possible, some settings are impossible to guess
so they require manual editing.
Reset the theme to the default. Similarly to how it was done in other
major overhauls (2.80, 3.0).
Documentation and tools to migrate themes will be available at:
https://developer.blender.org/docs/release_notes/5.0/user_interface/
Pull Request: https://projects.blender.org/blender/blender/pulls/147637
When strokes from to different layers get joined together, if one layer
had the `resolution` attribute and the other did not. The new
`resolution` attribute would be left with uninitialized values and then
a crash would happen.
This fixes this by filling all attributes that didn't exist with their
default value.
This also ensures that when strokes are removed, the drawing is
tagged as dirty.
Pull Request: https://projects.blender.org/blender/blender/pulls/147948
- "Acion Slot" -> "Action": typo.
- "Specifies the input node used the created zone" -> "by the created
zone": typo.
- "No reference available {!r}, Update..." -> "update": lower case.
- "uninitialized file-list" -> "Uninitialized": sentence case.
Some issues reported by Alexandr Fatih.
Pull Request: https://projects.blender.org/blender/blender/pulls/148265
Caused by 113d91aba8
Code first gathers a list of all vertexgroups on all objects.
Then it iterates the objects to join, and for each of them, puts their
vertexgroups in an index map.
However (by a typo?), it was doing it for the `active mesh` (instead of
the one currently visited) over and over again, resulting in weights
from other objects written to `def_nr` from groups of the `active mesh`.
Now corrected.
Pull Request: https://projects.blender.org/blender/blender/pulls/148259
This is an alternative to ba0f73d076. I'm not exactly sure why that on
didn't work yet. Seems like there is some hidden state somewhere, not sure.
Now this fix is more similar to what is done in `curves_blend_write`.
Pull Request: https://projects.blender.org/blender/blender/pulls/148267
While more of a theoritical issue currently, this change is a
pre-requisite to support properly compo nodes duplication in 'linked
copy' case (see !148210).
Also add a basic unittest for this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/148222
BLI code for enums that are meant to be used as "bit flags" defined
an ENUM_OPERATORS macro in BLI_utildefines.h. This cleans up things
related to said macro:
- Move it out into a separate BLI_enum_flags.hh header, instead of
"random bag of things" that is the current place,
- Update it to no longer need manual indication of highest individual
bit value. This originally was added in a31a87f89 (2020 Oct), in
order to silence some UBSan warnings that were coming
from GPU related structures (looking at current GPU code, I don't
think this is happening anymore). However, that caused actual
user-visible bugs due to incorrectly specified max. enum bit value,
and today 14% of all usages have incorrect highest individual
bit value spelled out.
- I have reviewed all usages of operator ~ and none of them are
used for directly producing a DNA-serialized value; all the
usages are for masking out other bits for which the new ~
behavior that just flips all bits is fine.
- Make the macro define flag_is_set() function to ease check of bits
that are set in C++ enum class cases; update existing cases to use
that instead of three other ways that were used.
Pull Request: https://projects.blender.org/blender/blender/pulls/148230
Since matrices are usually indexed **row first**, displaying matrices in
the UI seems flipped.
They are stored as flat arrays.
When `matrix[1][0]` is accessed via python, the logic from
`pyrna_py_from_array_index` will actually look up index 2 in the flat
array (rightfully so).
But UI code was flipped in that regard.
The second value in the flat array **should** show at row 1 column 0,
but it currently doesnt.
Now (hopefully) handled properly (not only in `ui_item_array` but also
made code in `ui_item_rna_size` detect proper row count for a `height`)
Pull Request: https://projects.blender.org/blender/blender/pulls/148197
Reported for the geometry nodes gizmos, but in general `cage2d`,
`cage3d` and `arrow` were affected (so for example Forcefield arrows, UV
editing transform tool, Lamp angle gizmo, ...)
`gizmo_cage3d_modal`, `gizmo_cage2d_modal` and `gizmo_arrow_modal` add a
`WM_event_add_mousemove` which ... lets the modal run even if the mouse
does **not** move...
This seems to date back to d8f931c9b7 in the arrow gizmo, others
probably just copied from there (not the DialGizmo though), did not do
further git archeology.
Propose to just remove `WM_event_add_mousemove` (even though there
_might_ still be reasons for this -- could not spot any though...)
Pull Request: https://projects.blender.org/blender/blender/pulls/146310
The issue is in the `ED_region_overlap_isect_` family of functions I
believe. Their purpose is to check if a coordinate is in the
"non-transparent" or opaque parts of the overlapping region.
These are getting event coordinates (in window space), converted to
region relative space (substracting region->winrct).
Comparison is in view space (through `UI_view2d_region_to_view_y`)
to account for scrolling and zooming.
The thing where it goes wrong is that we are actually comparing to
`region->v2d.tot` (this can be huge, most of it not visible), where I
think we should be comparing to `region->v2d.cur` (that is the part that
is actually visible...)
Swapping `region->v2d.tot` with `region->v2d.cur` is what this PR does.
Pull Request: https://projects.blender.org/blender/blender/pulls/146032
Oversight in 4bede1b555
`transformApply` / `transformEnd` already gives us a `NC_MASK |
NA_EDITED` notifier (via `viewRedrawForce`), so listen to that in
`image_main_region_listener`.
NOTE: alternatively, we could send an appropriate notifier in
`special_aftertrans_update__mask` (or remove the condition from the one
that is already there), with the difference that the gizmo would only
update after the transform is confirmed -- which may or may not be
desired
Pull Request: https://projects.blender.org/blender/blender/pulls/146292
The recently introduced size, strength, and jitter pressure curves
affect most paint code. This exposed further odd behavior inside
`paint_brush_update` where the size pressure curve was being evaluated
even if the brush's size did not vary with pressure.
To fix this issue, this commit clarifies a few comments and updates the
code flow such that cached input values and evaluated pressure values
are used more consistently.
Pull Request: https://projects.blender.org/blender/blender/pulls/148077
Rewrite the "mesh is valid" and "validate mesh" functions to be more
agnostic of the custom data storage system, align with the changes to
topology storage in the last 5 years, be much clearer overall, more
reusable.
Each check is implemented as a separate pass over the remaining
valid geometry in the mesh, producing an IndexMask of the invalid
elements it finds. At the cost of some extra iteration over mesh elements,
this should make each requirement clearer and make it easier to
optimize and reuse each check if needed.
The code is roughly twice as fast as it was before. I measured 92ms
instead of 200ms for a 1 million vertex cube on a Ryzen 7950X.
There's a bit of low hanging fruit for further optimization too.
There are now automated tests just for the validation code as well.
For now they are very basic but they could be extended in the future.
Some non-obvious points:
- The new face offsets storage (replacing `MPoly`) upholds more
invariants by itself. Previously faces could easily overlap or leave
corners unreferenced. That doesn't really happen anymore, but
bad offset values are a more "global" problem.
- The validation code for the old "MFace" storage was removed. It is
just rebuilt when it's needed at runtime anyway, so there isn't much
point in validating it.
- The versioning code for 2.90.1 was calling the mesh validation code
to fix an issue where the extrude manifold tool could generate bad faces.
Unfortunately keeping that would mean being unable to remove the old
code, so now there's a warning to open and save the file in a previous
version instead.
- One of the main goals of the new code is better const correctness, and
working better with implicit sharing. The code now only requests mutable
copies of the mesh data if it has to change.
Part of #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/148063
This was caused by 3dfec1ff73
which introduce the new behavior. This was to fix workflows
using a lot of semi-transparent objects which made nagivation
difficult.
This patch first roll back to the previous behavior: The
unselectable object will affect depth-aware operators.
This patch introduces a new visibility property to remove
the influence of objects in all depth picking operations
and selection operations. However the object is still
selectable through non-drawing selection operators
(e.g. select by material) and through the outliner.
This is to adress the aforementionned navigation issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/146706
644fb2b679 fixed a long standing issue
that offscreen example showed the wrong colors. However the fix assumes
that input texture color space is always sRGB.
This adds a shader variation that draws textures that are stored in scene referred
linear color space (like all of our Image data-block).
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/147788
