After the removal of the "normal" attribute providers, we no longer
use the concept of read-only attributes. Removing this status simplifies
code, clarifies the design, and removes potentially buggy corner cases.
Pull Request #104795
The "normal" was added before fields existed because we needed a
way to expose the data to geometry nodes. It isn't really an attribute,
because it's read-only and it's derived rather than original data.
No features have relied on the "normal" attribute existing, except
for the corresponding column in the spreadsheet. However, the
column in the spreadsheet is also inconsistent, since it isn't an
attribute but looks just like the other columns. The normal is
always visible in the spreadsheet.
Pull Request #104795
The active tools in `_defs_curves_sculpt` don't use names that are
exactly the same as the corresponding brush name with "builtin_brush."
at the beginning, instead they use more standard identifiers without
capitals or spaces.
The "brush_select" utility operator assumed the names matched though.
That can be fixed by manually mapping the brushes to the active tools.
Pull Request #104792
The keymap name in `WM_keymap_guess_from_context` didn't match the
name of the keymap in the Blender default keymap (`km_sculpt_curves`).
Fix by changing the utility function to match the keymap name.
Before right clicking on any tool in curves sculpt mode gave an assert,
now it shows a context menu.
Pull Request #104791
In BKE_screen_area_map_find_area_xy (find a ScrArea by 2D location),
ignore edges by using screen verts instead of totrct
Differential Revision: https://projects.blender.org/blender/blender/pulls/104680
Reviewed by Brecht Van Lommel
Lookup cache was not invalidated, to update attached effects position, a handle
of a input strip is touched.
To update attached effects, currently the code only does that when strip
position is changed. This is, because effect strip updating is done internally
in sequencer module code and ideally shouldn't be done at all. A TODO comment
with further explanation is added.
Avoid running out of attributes when multiple material slots use the same one.
Cleanup:
Removes the return value from drw_attributes_add_request since it shouldn't be modified afterward and it's never used.
Avoid making copies of DRW_AttributeRequest in drw_attributes_has_request.
Co-authored-by: Miguel Pozo <pragma37@gmail.com>
Pull Request #104709
Now that the UV map names are read from the evaluated mesh the names of
the anonymous layers would show up in the UV Map node and be accessible
via the python interface.
This changes the collection definition to skip anonymous layers.
Pull Request #104783
Instead of retrieving which attributes to transfer from the geometry set
which exists at a different abstraction level, get them from accessors
directly with a newer utility function. This removes boilerplate code
and makes the logic clearer for a future even more generic attribute
propagation API.
The evaluated positions cache can live longer than a specific
`CurvesGeometry`, but for only-poly curves, it pointed to the positions,
which are freed when the curves are. Instead, use the same pattern
as the evaluated offsets and don't store the positions span, just return
it when retrieving evaluated positions.
The evaluated positions cache can live longer than a specific
`CurvesGeometry`, but for only-poly curves, it pointed to the positions,
which are freed when the curves are. Instead, use the same pattern
as the evaluated offsets and don't store the positions span, just return
it when retrieving evaluated positions.
This reverts 1116d821dc and part of 5bac672e1a.
The solution was made specifically for the 3.5 release, to avoid
breaking other cases. The previous commit addressed the problem properly
by letting the general menu code align labels where needed.
Usually in Blender, we try to align the labels of items within a menu,
if necessary by adding a blank icon for padding. This wasn't done for
menus generated from enum properties (RNA or custom property enums). Now
we do it whenever there is at least one item with an icon.
Since the menu doesn't automatically align the labels like other menus
and pulldowns in Blender, I manually made them align using the blank
icon. However the menu button would also include this blank icon now.
This is a specific fix for the 3.5 release. In the main branch I will
replace it with proper support for automatically aligning labels in such
menus.
Since the menu doesn't automatically align the labels like other menus
and pulldowns in Blender, I manually made them align using the blank
icon. However the menu button would also include this blank icon now.
This is a specific fix for the 3.5 release. In the main branch I will
replace it with proper support for automatically aligning labels in such
menus.
* BLENDER_VERSION_CYCLE set to beta
* Update pipeline_config.yaml to point to 3.5 branches and svn tags
* Update and uncomment BLENDER_VERSION in download.cmake
Usually when a menu item displays an icon, we indent all other items
with an empty icon so items align nicely. Now with more built-in asset
libraries (the new "Essentials" library), this inconsistency becomes
more apparent.
Also add a separator line between the "All" asset library and the
others, makes the menu look more organized.
The Preferences for asset libraries are becoming more than a simple name
+ path. E.g. there is now an Import Method options, and we previously
also considered a Relative Paths option (which we may still want to
add). The previous UI, while consistent with the Auto Run Python Scripts
UI isn't well suited for less than trivial cases. Using UI lists makes
the UI more scalable and follows usual list UI patterns more. There is
also more space for the path button now.
Part of #104686.
The default import method for an asset library can now be determined in
the Preferences. The Asset Browser has a new "Follow Preferences" option
for the importing. The essentials asset library still only uses "Append
(Reuse Data)".
This is part of #104686, which aims at improving the import method
selection, especially for the introduction of the new essentials library
(which doesn't support certain import methods). Further changes are
coming to improve the UI, see #104686.
Pull Request: #104688
We (Dalai, Hans, Falk, Simon and me) decided that the curves edit mode
is useful enough to justify moving it out of experimental now. So far it
supports the following features:
* Various selection tools. The selections are synced with sculpt mode.
* Transform tools.
* Delete curves/points.
More functionality of the old curve edit mode will be ported over in
future releases.
This implements the delete operator in curves edit mode. The behavior
is similar to the delete operator in the edit mode of legacy curves,
i.e. it's actually dissolving and doesn't split curves. This is also
the behavior that we generally want for the hair use case.
The operator is added to the `Curves` menu and can be accessed via
the keyboard using `X` or `Del`.
Pull Request #104765
This adds a new `Curve Falloff` popover to the comb brush tool settings.
The curve control allows changing the brush weight along the curve to
e.g. affect the tip more than the root. This is a relative way to get
something like stiffness for short hair.
This functionality could potentially be added to some other brushes,
but the comb brush is the most important one, so that is added first.
I did add the buttons add the buttons to choose a curve map preset.
However, I did not add the preset dropdown, because that just adds
some unnecessary complexity in the code now and is redundant.
Pull Request #104589
This patch adds a simple operator to set values of the active
attribute for the selected element. The aim is to give simple control
over attribute values in edit mode rather than to provide the fastest
workflow for most cases. Eventually this operator might be less
important compared to more advanced attribute editing tools, but for
now, exposing a little bit of functionality is low hanging fruit and
will help to see the possibilities.
The implementation mostly consists of boilerplate to register the
necessary property types for the operator and draw their UI.
Beyond that, we just loop over selected elements and set a value.
Pull Request #104426
Caused by strips being flagged for removal, but the flag was never
cleared. As far as I can tell, this issue is not reproducible anymore,
but there may be files with this flag still set.
