Caused by 6faa39edb7
In that commit it was assumed that the view offset does not need to be
updated if the operator is `V3D_OP_MODE_ROTATE` instead of simply
checking `this->use_dyn_ofs`.
Since `use_dyn_ofs` is always `True` when using Auto Depth or Orbit
Arround Select, the offset should always be updated in these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/114726
This fixes a bug where the rgb UsdUVTexture shader output
attributes were created with incorrect type color3f when
connected to UsdPreviewSurface diffuseColor and emissiveColor
inputs. The UsdPreviewSurface specification requires the
UsdUVTexture rgb output to be of type float3.
This was happening because the UsdUVTexture outputs were created
implicitly by the call to UsdShadeInput::ConnectToSource(). I.e.,
because the diffuseColor and emissiveColor inputs are of type
color3f, this was the type assigned by default to the rgb source
attributes as well.
Now explicitly creating the UsdUVTexture shader output attributes
with the correct types.
Pull Request: https://projects.blender.org/blender/blender/pulls/114728
When VSE cache is invalidated (on most VSE edit operation e.g.), or
Blender quits, in some cases (complex and very long edits), the
prefetch job would block several seconds after being requested to stop.
This was because one codepath would keep looping over all frames without
checking for the `stop` flag.
Ensure that the view layer is properly synced before trying to get the
active collection.
Without the sync, imported objects typically get placed in the global
Scene Collection rather than the new collection that was just created
for the import.
Pull Request: https://projects.blender.org/blender/blender/pulls/114650
Restoring the behavior while transforming keys and pressing `Ctrl`
The regular snapping code has the feature that
when you press `Ctrl` you can toggle the snapping on and off.
Prior to 4.0 the snapping for the Graph Editor used a
completely different system, including a different flag to toggle snapping.
Because of that, the flag that the regular snapping
code uses was never set by default. So the system thought it was disabled.
Now when you press `Ctrl` you would enable that
flag and the snapping code would run.
It would snap to increments because that is the mode that
is returned for the Graph Editor space type.
(Note that this is the mode of the generic snapping
system, not of the Graph Editor specific one)
However at the same time, doing that would disable the
Graph Editor specific snapping code.
So the snapped values from the original system would bubble through.
This did not occur in the Dope Sheet and NLA Editor,
because those never returned a snapping mode.
Those still have a different behavior to 3.6 where they
now snap to seconds, instead of not snapping at all.
Pull Request: https://projects.blender.org/blender/blender/pulls/114607
During the 2.93 to 3.0 transition, instance handling was made more
explicit in general. However, we forgot to change the boolean node,
which still implicitly gathered all the instanced meshes and fed them
to the boolean algorithm separately. We waited for the next breaking
release, 4.0 to "correct" this, and did it in fc06a471f1.
However, in that commit it was assumed that the "Self Intersection"
mode would be able to address the use case. The idea was also to push
some complexity outside of the boolean code, which is already one of
the more complex areas in Blender. Though it's possible to have a
"Group ID" or "Shape ID" input in the future as well, it's also
reasonable to expect some instances to be processed by the node,
even though it isn't quite consistent.
This commit makes a compromise by processing meshes contained by
top-level instances. We do it at this stage of the release to avoid the
breaking change.
Pull Request: https://projects.blender.org/blender/blender/pulls/114632
Alternative solution to #114414 which reduces the scope of
textures for which single-channel greyscale optimization
is removed from.
Some byte buffers are converted to float buffers during
color management. These cases should retain support in
the optimal path.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/114611
Code using #PyObject_GetBuffer was combining the `PyBUF_FORMAT` and
`PyBUF_SIMPLE` flags, but the documentation specifies that
`PyBUF_FORMAT` can be |'d to any of the flags except `PyBUF_SIMPLE`
because the latter already implies format `B` (unsigned bytes).
The flags in such cases have been replaced with
`PyBUF_ND | PyBUF_FORMAT`, which has the additional requirement that the
buffer must provide it's `shape` field.
This fixes `memoryview` objects raising a `BufferError` when requested,
due to the invalid combination of flags making them be considered
invalid buffers when they would otherwise be valid.
Ref: !106697
Address regression in [0] which allowed wmKeyMapItem::properties to
remain set when a valid wmKeyMapItem::ptr can't be created because the
wmOperatorType isn't available (temporarily in the case of reloading).
Resolve by freeing wmKeyMapItem::properties when the `ptr` isn't set.
Also add null pointer check not to assume wmKeyMapItem::properties
implies an allocated wmKeyMapItem::ptr. Something which is already
accounted for everywhere else.
[0]: 08e5f94a70
This was fixed by [0] however that fix didn't account for IMB
sometimes freeing GPU resources created by color management
(resolved by [1] which effectively reverted [0]).
Resolve by re-initializing IMB in the case of drag & drop.
[0]: 51467b0611
[1]: 05c56603a9
Fix#112697: Skip unavaliable UV maps on VBO upload
The list of available UV maps is generated for the evaluated object,
however if any modifier generates UV maps (for example Geometry
Nodes) it is possible the evaluated object contains UV maps which are
not present in the base mesh. So when only the base mesh is uploaded,
for example in the UV editor, UV maps present in the list are not
guaranteed to exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/114558
In Blender 4.0 Grease Pencil was showing up as "Grease Pencil (legacy)" in the UI in some places.
Since the current Grease Pencil is not replaced yet, it shouldn't be named this way in 4.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/114531
There are two bugs with data-block inputs currently. One is #113383,
where clicking the "Clear" button on the data-block picker closes the
redo panel. The worse issue is that storing pointer properties in
operators isn't safe at all. Deleting the data-block doesn't clear
the pointer property in operator storage, for example.
The proper solution is to reuse some code from the existing data-block
picker but back it with a `session_uuid` integer property instead of an
actual pointer. This makes lookups safe without depending on the name.
However, doing that for 4.0 is too risky, so for now we will just not
support data-block inputs in the redo panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/114621
This was initially added a long time ago[1] to help with certain exit
behavior while running under a debugger. However, this shouldn't be
necessary any longer.
More importantly, tests have started to use the `--debug` option[2].
Somehow the bots are fine, but anyone running the tests locally on
Windows will experience what looks like a hang; unless they press a key
to allow the tests to continue.
[1] 1cc19c6993
[2] The `blendfile_versioning` test
Pull Request: https://projects.blender.org/blender/blender/pulls/114605
The code from 5ac392ca4 did not work on macOS since WITH_INSTALL_PORTABLE
is not set there. This issue was hidden before, but now happens due to
the changes in #114569 to avoid using /etc/ssl.
The Cryptomatte node is not searchable in the link drag search operator.
That's because it still uses socket templates, which are no longer
supported for search since f5e6d4e4b0.
This patch fixes that by using the declare method instead of socket
templates.
Pull Request: https://projects.blender.org/blender/blender/pulls/114537
Standalone animation player has inconsistent GPU context activation
paradigm compared with standard rendering paths. The Metal backend
utilises the context activation step to refresh target window swapchains
from within the GHOST module.
This PR adds activation and deactivation calls, and also aims to clean up
GPU_render_begin/end setup to ensure all paths are covered.
Also resolves a bug upon shutdown wherein GPU resources which may
be tied to a GPU context are released during IMB_exit(), which is called
after GPU context destruction.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/114573
- Add OARS info, <url/> tags and screenshot captions
- Change metainfo file extension from the deprecated ".appdata.xml" to.
- Update bugtracker and help URL tags in metainfo file.
- The metainfo file is now installed.
- The file now passes flatpak validation.
Ref !114115
Looks like most of `ui_apply_but_XXX` or `ui_do_but_XXX` functions rely
on `uiHandleButtonData` (and not necessarily context).
Now the problem from a popover in `ui_but_list_row_text_activate` was
that the label button to be set in BUTTON_ACTIVATE_TEXT_EDITING for
renaming could not be found because it was using the "wrong" region from
context (`CTX_wm_region` - which still seem to point to the region the
popover was spawned from). The correct region is available in
`uiHandleButtonData` though, so now use this instead.
Not totally sure if `CTX_wm_region` should actually be correct in all
cases - which would hint at an underlying problem of not setting it
right - but since other functions rely on `uiHandleButtonData` as well,
this fix seems to make sense.
Fix should go into LTS I think.
Pull Request: https://projects.blender.org/blender/blender/pulls/114363
Ensure that on closing of the application, all pending
SafeFreeLists are released. A new change to ensure
release of SafeFreeLists was always deferred until
full completion of GPU buffers meant that a pending
MTLSafeFreeList container may not be released on
shutdown.
This change ensures that the container is fully
destructed on final shutdown.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/114532
Fixes a harsh transistion between diffuse and subsurface scattering
materials in the Principled BSDF as a user increases the Subsurface
Scattering Weight from 0 to 1.
Pull Request: https://projects.blender.org/blender/blender/pulls/114500
When click-dragging on the 'up-arrow' of the asset-shelf to show it the
first time, some resizing operation could get called before the shelf
region was initialized, leading to crash on null pointer access.
The null byte wasn't taken into account when allocating memory
to strcpy into.
The calculation to check if allocation was needed was also wrong,
causing allocation for every string.
In practice it's not so likely users would ever hit this since
the function tended to over allocate, even in the case an off by one
error occurred, in all likelihood the room would already be available.
Ref !114512
If the draw_color method is not defined, try to use draw_color_simple as
a fallback. If not defined either, fallback to a magenta color.
The patch also updates the description of the method to clarify its use.
Pull Request: https://projects.blender.org/blender/blender/pulls/114527
A missing part since PR #110139: the nodes and relations builders
needs to be in-sync and build the same objects. The relations builder
was missing relations building for camera referenced by markers.
Pull Request: https://projects.blender.org/blender/blender/pulls/114443
Code tried to move such strips (using the same action on equal IDs such
as meshes or shapekeys) between tracks multiple times [even though they
were actually moved already] which could end up with the wrong track
index and things just went downhill from there.
So now skip strips we cannot find in the original track, saves
us from the whole codepatch about "Moving strip into track in the
requested direction".
Pull Request: https://projects.blender.org/blender/blender/pulls/114458
Single channel JPEG files are stored in 4 channels image buffers, with their
bit planes set to 8.
When creating the GPU texture the number of bit planes is used to identify
if the data could be stored as a single channel texture, but in this case
the source data contains 4 channels and doesn't align with the GPU
texture format.
In Blender 3.6 the way how bit planes were stored changed (the planes
used to be 32 for the grayscale byte images matching the number of channels,
but now is set to 8, matching the original loaded image).
Since Blender 3.5 the grayscale byte images are uploaded using a single channel
GPU format, which leads to the mentioned artifacts. Grayscale byte buffers never
seems to have worked since its introduction in
https://archive.blender.org/developer/D15484
This PR disables using the grayscale GPU textures when it sourced from
a byte image.
Pull Request: https://projects.blender.org/blender/blender/pulls/114441
Root of the issue was that a1d7ec7139 (from !110109, new comptibility
handling) missed to update code of `handle_subversion_warning`, file
version numbers should be checked here now, not the minversion ones.
On top of that, this report has been changed to a `RPT_WARNING` instead
of a `RPT_ERROR`, and reports 'print level' for file reading was set to
`WARNING` level way too late to have any effect in existing code...
USDZ conversion currently requires to change the 'current working
directory', due to internal USD library limitations.
This can only be done from main thread (and is highly discouraged in
general). This implies that USDZ conversion cannot happen from the Job
worker thread.
This commit moves it to the `endjob` callback of the USD export job
instead, as it is guaranteed to be executed from caller thread, i.e.
main thread in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/114420
The file that reproduces this had some faces of a mesh with vertex
normals, while some other faces were without vertex normals.
The parsing code assigns INT32_MAX as a fallback of "I could not parse
the normal index as a number" case, but later on code was not
catching this "normal index might be invalid" case. Fixes#114304
The issue crash was caused by non-safe cast from a bare C array
float[4][4] to float4x4*. Such cast is not safe because it might
break alignment.
Modified the code so that the transform matrices are passed by
value.
Technically it could mean higher memory usage, but odds that the
actual geometry which is a part of boolean operation consumes much
more memory. Additionally, avoiding indirection could potentially
lead to better performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/114421
Adding strips or changing filepaths caused thatde movie files were loaded,
but memory was only released after new frame was rendered. Since FFmpeg
can take a lot of memory per strip, this can cause crash.
Free memory for each strip immediately after it is not needed after
these operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/114381
