Don't log wm.operator operator properties when no properties
are stored/loaded, this was noisy, especially for the
INFO_OT_reports_display_update operator when runs from a timer.
As the window state will have been initialized, read the current window
state instead of assuming normal so changes are properly detected.
Also note that the cause of #107314 has been fixed up-stream.
This PR adds `@autoreleasepool` blocks around functions that have been observed to create hidden temporary NSObjects, and eventually cause command buffer failures. A couple of allocations needed to be tweaked in order to maintain correct retain/release behaviour. This PR also fixes the command buffer error text to show more useful information.
When retrieving a color attribute to paint it, the layer data needs to
be unshared so that it doesn't modify data from separate meshes.
In the past I think we've unknowingly avoided this problem by porting
code to the new attribute API. I've been refactoring `PBVH` and
`SculptSession` to make that possible (removing the long-lived
layer pointers in the two structs). But that wouldn't fit as a bug fix.
In the meantime, make sure the color attribute data is un-shared
and separate "for read" and "for write" versions of the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114119
A curve with only two points shouldn't be considered cyclic. Otherwise
a duplicate edge is added between the points. This fixes the utility
that calculates the segment count to account for this and adjusts
other code to account for that as necessary. Curves now evaluate
correctly to a single evaluated segment in this case (in the case of
Bezier and NURBS curves, it depends on the resolution though).
Co-authored-by: Dalai Felinto <dalai@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114095
The PBVH is given the evaluated positions from the end of the modifier
stack, but then updates normals from the original mesh based on those
positions. This causes a feedback loop, even when in vertex paint mode.
As mentioned in a comment, calculating these normals and duplicating
the arrays is quite wasteful. But it's necessary since the PBVH always
assumes we are interested in modifying the positions, and also always
retrieves the normals from the original mesh too. Those things would
be good to untangle at some point too, but for now this change is small
and helps to clarify the situation as well.
Caused by: b339e3937d
Pull Request: https://projects.blender.org/blender/blender/pulls/114118
`EdgeHash` was replaced by `VectorSet`, but the changes in the data
structure hid some other changes, causing incorrect indices to be used.
Instead use `Map` and explicitly build the indices similar to how they
were counted in a separate loop before.
Caused by: 425b871607
Labels in popover menus are always darker. That made the popovers for
Type and Modes to have a way too dark color. Specially when the values
were off.
This commit mimics what we do in the viewport Selectability &
Visibility menu. Basically we don't gray out the labels even if the
values are off.
Co-authored by: Hans Goudey <hans@blender.org>
- Added support for Point3* and Normal3* attributes as CD_PROP_FLOAT3.
- Caught the last two quaternion formats.
- Silenced prints on quaternion and string formats, as they are known unsupported attributes.
This pull addresses https://projects.blender.org/blender/blender/issues/112294.
The test file provided for that issue now only generates one error, which I believe
is important to keep.
Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/112298
When using Voronoi shader nodes on legacy Intel platforms (HD4400) Blender would crash
due to a driver bug. The bug is related to generating the `fractal_voronoi_x_fx` functions.
It doesn't effect all drivers, but mainly from vendors that don't allow installing the official
intel drivers.
We have tried several approaches including using unique function names and unroll only the
function of the body. But none worked on the failing platform.
In the future we could solve this by including our own GLSL compiler, but that is still very
experimental and requires a lot of testing.#113938
Pull Request: https://projects.blender.org/blender/blender/pulls/113834
The goal is to make it possible to have more or less reliable way
to perform performance comparisons of changes in algorithms used
in dynamic topology.
This change allows to run Blender with the following arguments:
blender --log "sculpt.detail,pbvh.bmesh" --log-level 2
and see timing of dynamic topology flood-fill operation, as well as
individual timings of edge subdivision/collapsing.
Pull Request: https://projects.blender.org/blender/blender/pulls/114099
This PR removes the "experimental" disclaimer from the MetalRT control now that the unit tests all render correctly with it enabled. As well as "Off" and "On", this adds a third "Auto" setting - a new default which can be used to pick the best option.
Pull Request: https://projects.blender.org/blender/blender/pulls/114067
Regression from [0] where the key-map was attempting to load preferences
for key-map items for add-on operators which were not yet defined.
Resolve by postponing keymap updating until after loading add-ons.
[0]: 6de294a191
The main goal of this patch is to turn `node.inputs[...]` and `node.outputs[...]` into
the main way to lookup sockets on a node. Currently, it's used for that sometimes,
but often it is not, because it does not work in all cases. More specifically, it does
not work when a node has multiple sockets with the same name but different
identifiers, which is relatively common.
This patch proposes to make the string lookup more convenient, more useful and
less prone to breaking after changes in Blender.
This is achieved by changing how the lookup works:
* First, it tries to find an available socket with an identifier that matches the given
key. This is checked first, it makes sure that every socket can be accessed by its
identifier. The identifier matching is currently disabled in some nodes where we
want to change identifiers soonish.
* If that didn't work, it tries to find an available socket with a matching name. This
is often convenient because it generally matches what can be seen in the UI.
Furthermore, it's also necessary to avoid breakage with old usages of this lookup
function.
* If both options above didn't work, it checks whether the given key matches any
socket name/identifier that the node used to have in the past, but has been
renamed for whatever reason. This mainly exists to avoid breaking scripts by certain
kinds of changes in the future. This is not included in this patch.
Note, previously, string lookup would also find unavailable sockets. This is disabled
now, because the way we handle unavailable sockets internally is likely to change.
Therefor, any use of unavailable sockets might break (unavailable != hidden). For
the time being, it's still possible to find unavailable sockets by iterating over all sockets.
This change has a small chance to break existing scripts because the behavior
changes for some inputs in some nodes. However, for the cases where the function
is used in practice, I don't really expect any breakage.
This patch also allows us to give a better answer to reports like #113106.
Pull Request: https://projects.blender.org/blender/blender/pulls/113984
Due to missing logic reflection probe updates where not always
performed. There were multiple artifacts:
* Lookdev Worlds where Black Until the Scene world was rendered.
Issue was that the lookdev world didn't initialized its atlas
coordinates.
* Lookdev world should only retrigger reflection probe update when
material is compiled
* When world is updated, reflection probes should be updated; this
might require a redraw when reflection probe draw passes aren't
updated this sample.
Pull Request: https://projects.blender.org/blender/blender/pulls/114064
No functional changes.
Changing old C code to C++ by returning a `Vector` from `ANIM_setting_get_rna_values`.
This reduces the argument count for that function and simplifies the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/113931
It's possible to encounter a true 1-channel image if it's coming
directly from, say, a float-value AOV or similar.
This was not accounted for and would cause issues when saving the image
out to a 3 or 4 channel format (wrong values) or when saving out to
another 1 channel format (unnecessary usage of luminance weight values).
Pull Request: https://projects.blender.org/blender/blender/pulls/111577
Last key is drawn on the right edge of the strip, but that is end of
the frame, which it should be bound to. Because of this, drawing code
and operators must consider, that this key is always displaced.
This was not done in 86a0d0015a and caused issues like #113755 that was
fixed incorrectly.