While the fix worked in my tests, the compositor is allowed to ignore
a requested window state change which could have entered an eternal
loop. Avoid this by limiting the while loop to 2x round-trips.
Even though the window was maximized, the non-maximized size was used.
Since the display size was used the window would be slightly larger,
clipping the status bar in GNOME.
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>
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
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
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.
When the output wasn't fractionally scaled but the compositor supports
fractional scaling, new windows were smaller than requested.
Caused by [0] which was incorrectly calculating the non-fractional scale
used by LIBDECOR (which isn't accessible via it's API).
Resolve by only using fractional scaling logic when outputs
have a fractional component.
[0]: 3eda5a114f
The issue was that a node was supposed to propagate an anonymous
attribute that is only created further to the right in the tree. This does not
during inferencing, where uses of fields can only come to the right of its
creation. Note, all fields coming out of the repeat input/output node are
new field sources during inferencing.
Now, only field sources that are passed from the outside into the repeat zone
can be propagated from the repeat output to the repeat input node.
Solving this also showed another issue where anonymous attributes are
not properly propagated through a repeat zone where there is no link between
the repeat input and output node. In such cases, data is still propagated between
those two nodes when the number of iterations is zero.
The way we handled activation of view item buttons (which are placed
underneath other buttons) would leave that button in an active state,
giving it priority on the next event handler run. Instead we want to
cleanly exit the button after activation, so that the overlapped chevron
icon can be recognized as hovered again.
Also limit this to mouse press events, since otherwise the tree view
item would toggle the collapsed state on both the press and the release
event.
Choosing "Mark as Asset" from the context menu of the ID selector (ID
template) would always use the selected objects instead of the ID set in
the ID selector. This is because since f22e2bab72, multiple selected IDs
have priority over a single active ID (to give batch editing priority),
and the 3D view context exposes both.
Adds variants of the mark and clear asset operators that only work on a
single ID ("id" context member). Context menus for buttons representing
an ID use this instead. Using an operator property resulted in too
complicated code. Plus the poll function would succeed in cases where
the operator wouldn't be able to succeed. Separate operators keep things
simple and more reliable.
This was caused by the framebuffer incorrectly being recreated
using a byte buffer. From now on, always use the input format
or guess the format based on the output bitdepth.
Pull Request: https://projects.blender.org/blender/blender/pulls/114061
This is because `TRANSFORM_OT_edge_slide` has `OPTYPE_DEPENDS_ON_CURSOR`
flag set. Due to this, invoke call to loop-cut operator was not sent
from function `WM_operator_name_call_ptr_with_depends_on_cursor`.
Since `edge slide` operator does not depend on actual cusor position, we
can remove this operator flag to fix the problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/113140
Translation markers `N_()` were added to IDs' plural names in !113912.
I also renamed some of those because I thought there were only display
names.
This commit reverts the renaming, leaving only the addition of the
markers.
Pull Request: https://projects.blender.org/blender/blender/pulls/114030
Steps to recreate were:
- Open factory startup
- Add armature, switch to Pose Mode
- Drag upwards the little triangle/chevron tab in the lower right of the
3D View
If the asset shelf would be displayed the first time for an editor, the
asset shelf data isn't valid yet and can't be accessed.
In earlier design, retiming selection was managed outside of retiming
keys struct. This was changed to a flag of the retiming key struct.
Since moving of the transition deletes and re-creates keys, the
selection was lost. Selection is now re-established in
`seq_retiming_transition_offset()`.
After eda58d6419, multiply operation does not affect alpha channel, but
Some users do expect this feature present.
This adds option `multiply_alpha`, so that multiplication (in strip
color panel) will affect alpha channel as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/113791
Alternate fix for [0], a crash when a texture fails to load since this
seems to cause animation playback to fail on WIN32, see #113849.
While I can't redo the error, the main change was setting up
`immVertexFormat` before calling `ocio_transform_ibuf`.
[0]: 34899ec13d.
This reverts commit 34899ec13d.
This causes issues on WIN32 which I'm unable to reproduce.
Resolving the error with textures failing to load can be done with
fewer changes.
When the subtype of a custom property is set programmatically to
something that isn't in the subtype enum of this operator, attempting
to edit it will throw an error. This check should avoid that, by simply
not setting the subtype if it's not in the enum, resulting in a default
subtype of NONE. This is the second attempt at #112582, which I broke
when messing with branches.
Pull Request: https://projects.blender.org/blender/blender/pulls/114003
The repeat zone needs some special treatment during anonymous attribute
inferencing, because it propagates those attributes directly from the repeat
input to the repeat output node and vice versa.
Now the algorithm uses multiple passes if necessary to reach a stable
inferencing result.
Pull Request: https://projects.blender.org/blender/blender/pulls/113970
Some of these devices are not capable of running >=4.0, due to issues
with Mesa's Compute Shaders and their D3D drivers.
This PR marks those GPUs as unsupported, and prints info to stdout.
A driver update will be available for 8cx Gen3 on the 17th October
from here:
https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-tablets/snapdragon-8-series-mobile-compute-platforms/snapdragon-8cx-gen-3-compute-platform#Software
It will take longer via the standard MS Windows Update channels,
as there is certification, testing, etc required, but it is possible
to get the drivers, at least.
This issue applies even when using emulated x64.
If this does not get merged, all WoA devices will break with 4.0,
where older ones will just launch a grey screen and crash, and newer
ones will open, but scenes will not render correctly in Workbench.
These devices work by using Mesa's D3D12 Gallium driver ("GLOn12"),
which is why we have to read the DirectX driver version - the version
reported by OpenGL is the mesa version, which is independent of the
driver (which is the part with the bug).
Pull Request: https://projects.blender.org/blender/blender/pulls/113674
