The old name was logic when the color of the stroke was using a palette and not materials, but now always a material is used so the name "color" is not logic.
As we are changing all the API, now is the moment to set the right name.
Also, the commit includes some cleanup of the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/114186
Customs sockets always ignore their draw_color method and are always
drawn using a magenta color.
This is a regression that was introduced in e071288ab2. The commit used
the simple variant even for drawing nodes where a context is available.
So this patch mostly reverts those changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/114148
The description first described functionality that doesn't work properly.
Prefer text that is to the point with what works well, elaborating on
error prone & partially working solutions afterwards.
Also include a stub example for script authors who prefer to develop &
maintain their scripts outside of Blender.
Windows allows people to pin an application to their taskbar, when a
user pins blender, the data we set in
`GHOST_WindowWin32::registerWindowAppUserModelProperties` is used
which includes the path to the `blender-launcher.exe`. Now once that
shortcut is created on the taskbar, this will never be updated, if
people remove blender and install it again to a different path
(happens often when using nightly builds) this leads to the
situation where the shortcut on the taskbar points to a no longer
existing blender installation. Now you may think, just un-pin and
re-pin that should clear that right up! It doesn't, it'll keep using
the outdated path till the end of time and there's no window API call
we can do to update this information. However this shortcut is stored
in the user profile in a sub-foder we can easily query, from there, we
can iterate over all files, look for the one that has our appid in it, and
when we find it, update the path to the blender launcher to the
current installation, bit of a hack, but Microsoft seemingly offers no
other way to deal with this problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/113859
This new member gives access to the current active panel category (i.e.
tab) if supported, and allows to set its value to another defined
category.
While typically add-ons should not force a tab to be the active one,
there are cases where this is a valid and necessary behavior, e.g. in
'Blender App' where an app can add some new tab to the UI and require
them to be active.
Note that there is a ctach here: typically at start time these panel
categories are unknown (enum is empty), since they are validated by
drawing code. So setting them usually needs to be done after initial
startup and drawing of the UI...
Pull Request: https://projects.blender.org/blender/blender/pulls/114070
Use more modern approaches for supporting all generic attribute types,
rather than hardcoding all of the types and mistakenly correlating types
and domains.
A "Converter" template class handles conversion to GPU data and
describing the GPU format. The class is based on recent work in Cycles
attribute upload and is meant to replace the `AttributeTypeConverter`
class in `extract_vbo_attributes.cc`. I will do that as a separate step.
This structure will give build errors if new attribute types are added
but not supported here, preventing the situation described in the
report.
All generic attribute types are supported now, consistently with non
sculpt mode drawing. The edge domain isn't supported though.
Typically edges are more costly and complex to access, and interpolation
is less well defined anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/114334
Done by passing USES_TERMINAL to the add_custom_command().
This allows to see sub-command messages early on, before they
are finished executing.
This should help buildbots to "see" that the kernels are still
being compiled and not kill the build because it did not output
anything in a long time.
Pull Request: https://projects.blender.org/blender/blender/pulls/114327
Currently the node tool node group and data-blocks referenced by it
may not be part of the active dependency graph. This means we
cannot retrieve their evaluated geometry when executing the operator.
Since operators almost always use the evaluated geometry of other
objects, and since geometry nodes is mostly set up to deal with
evaluated data-blocks currently, this must be fixed.
Instead, set up a temporary dependency graph and add the selected
objects and the data-blocks used by the node group. That graph is
evaluated to give simple access to evaluated data-blocks.
Unfortunately this will cause more work than necessary in a few ways:
1. Selected objects are reevaluated an extra time before execution.
2. All data-blocks referenced by the group are completely evaluated again.
3. The node group itself is reevaluated, which recreates the function graph.
These may or may not become bottlenecks in the future, but it's best to
keep it simple late in the release process. And between a completely
broken feature and a potentially slow feature, the choice is clear!
Pull Request: https://projects.blender.org/blender/blender/pulls/114293
After previous changes to allow command buffers to not require
execution and completion in submission order,
guarantees for releasing freed buffers back to the memory pool
within the frame life time had changed.
This could mean a released buffer could be returned to the
memory pool prematurely, if a subsequent command buffer
completes before a previously submitted one, flagging a resource as no
longer in use by the GPU, while it still may be in use by the orignal
command buffer.
This PR defers final reference count release for buffers
being actively used until the following call to GPU_render_step,
to ensure that buffers freed will be available for the lifetime of
the frame, covering all command submissions, rather than just
within the lifetime of the command buffer submission within which a
buffer was freed.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/114329
The issue was that when in tweak mode, there are other places than just
the strip list that keep pointers to the tweaked strip. So deleting
that strip would leave dangling pointers, which caused things to blow up
elsewhere.
Pull Request: https://projects.blender.org/blender/blender/pulls/114331
In certain cases bones can disappear in pose mode. The cause was
that the alpha channel was not set in all cases and might use uninitialized
memory as alpha value.
Pull Request: https://projects.blender.org/blender/blender/pulls/114324
The user-level goal is to make it so boundaries are preserved in a
much better manner.
At this point of the project boundaries are considered edges which
are marked as seam or sharp. It is possible to expand this logic to
more cases like boundary between face sets. For now the main focus
in the algorithm itself.
The rough idea is the following:
- Splitting an edge is "lossless" for boundary, so there is no need in
any special handling of edges there.
- When collapsing an edge prefer to collapse edges which are not
boundary but adjacent to it. The vertex which is adjacent to boundary
does is preserved and is not moved during the edge collapse algorithm.
- Then collapse boundary edges.
There are a bit of tricky parts, especially with the flaps. They are
explained in the code and ASCII diagrams are provided for better clarity.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/113836
If "Region Overlap" was disabled, the region coordinate calculations
would end up placing the header on the bottom, taking space away from
the main asset shelf region. This is because the header was abusing the
`RGN_SPLIT_PREV` flag a bit, because it gave the desired behavior of
hiding the regions together. This worked well because the regions
wouldn't actually do the splitting when one used region overlap and the
other not. But disabling region overlap would bring the splitting
usually enabled with the `RGN_SPLIT_PREV` flag.
This PR removes the `RGN_SPLIT_PREV` flag from the asset shelf header.
Instead a new flag is introduced to only enable the behavior of
`RGN_SPLIT_PREV` of hiding a region together with the previous one. So
the header stays at the top of the region, and labels stay visible.
The new flag is added to the `ARegion.alignment` flags, even though it's
more related to behavior than alignment. However this is more
convenient, and keeps it together with related flags.
Khmer was added for this release and is barely translated yet (about
1%), so it's not too bad. We will ensure that the Khmer script is added
to our default font for 4.1, but this is too late for 4.0.
The implementation follows the logic of the face set brush for the
faces and grids type of PBVH, with the similar weak part of iterating
over entire mesh at the start of a stroke.
The difference in the behavior is that face needs to be fully covered
by the brush in order to have face set assigned to it (while for the
other types of the PBVH face gets assigned its face set if any of its
vertices are covered). The main reason for this is that this seems to
avoid boundaries being too wiggly.
The auto-masking is not fully integrated into this brush yet. Doing so
is possible, but seems to require deeper re-considerations of the way
how automasking accesses original data and how it is fetched from an
undo node. It worth noting that auto-masking is something that needs
to be looked into for all brushes to make it supported in the dynamic
topology mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/113357
Khmer was added for this release and is barely translated yet (about
1%), so it's not too bad. We will ensure that the Khmer script is added
to our default font for 4.1, but this is too late for 4.0.
Regression from 7ec7dac860 (I assume). While the block active state is
relevant during drawing to avoid glitches, it should be ignored during
handling. Explained further in comment.
The functionality to frame channels in the Graph Editor
did not take into account any NLA mapping, causing the
viewport to frame the wrong part.
Fix it by mapping the `rctf` x-values
I had to remove the `const` on a parameter from the function
since `ANIM_nla_mapping_get` doesn't take a `const`.
Pull Request: https://projects.blender.org/blender/blender/pulls/114325
Implements #108948 - support for custom point domain attributes for PLY
import and export. Notes:
- Custom attributes are always represented as scalar floats. PLY itself
has some data types that blender can't fully represent, e.g. double or
uint32, or some that fit into a float just fine but blender does not have
them as separate types (e.g. int16).
- When importing, any PLY vertex attribute that is not one of "standard"
names (position, normal, etc.) gets turned into a custom attribute.
- For exporting, more complex custom attributes (e.g. 2D/3D floats,
quaternions, colors) get turned into several PLY attributes, with "_x"
like suffix.
Custom attribute import/export is on by default in the UI.
Pull Request: https://projects.blender.org/blender/blender/pulls/114320
Reviewed By: Hans Goudey
The issue was that the undo system detected that node trees have been changed
even though they have not. This is because the memory dump of the node tree
changed after unrelated changes. The root issue was that
`bNodeTreeInterface::write` also wrote the struct, and the pointer of the
`bNodeTreeInterface` itself. While this pointer is generally stable, it is not
during file-write, because when IDs are written, a shallow copy is created
first (see `BLO_write_init_id_buffer_from_id`). The temporary buffer for this
shallow copy is allocated on the heap, so its pointer may change over time.
The fix is to simply not write the `bNodeTreeInterface` separately, since it's
already embedded in `bNodeTree`.
Pull Request: https://projects.blender.org/blender/blender/pulls/114322
