Similar to other bugs caused by ada367a0e9 (e.g.
ff9de2f7da9dcec96692355a67a7e7e280c223a7), the issue is that the object is
tagged for changes before retrieving its evaluated state.
I can't say I fully understand the all the code path for the object conversion
already. However, the change seems to make sense based on the `/* other users
*/` comment right above the change. Also, the selected object is tagged again
further down in my test anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/129948
When running test cases
`test_texture_roundtrip__GPU_DATA_10_11_11_REV__GPU_R11F_G11F_B10F`
would read and write outside of allocated memory. This is an error in
the test case itself the GPU API doesn't have a public function to get
the desired byte and component size.
Pull Request: https://projects.blender.org/blender/blender/pulls/129958
The `GreasePencil::update_drawing_users_for_layer` function was using an
incorrect drawing index check, skipping over drawing 0 every time.
As a consequence the first drawing may have zero users despite at least
one frame referencing it.
Pull Request: https://projects.blender.org/blender/blender/pulls/129955
First this make the wire batch use the same set of drawing that the main
gpencil batch uses (as they share the same VBO data, they need to use
the same drawings).
Then we skip drawing the onion frames by nullifying the indices in the
index buffer. A better way would be to skip these strokes or drawing
but that can be done later and seems more bug prone.
Pull Request: https://projects.blender.org/blender/blender/pulls/129920
The issue was that the masks for the current frame would be
rendered for a different frame.
Unfortunately, we can't easily render masks for the onion
skinned frames correctly at the moment.
The fix makes it so that we render the mask only for the current frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/129878
Possibly due to c13cde24cc
This commit clamps the `brush->size` value to 1 at lowest for the
Grease Pencil Draw mode. There are situations where when the brush scene
space value is set to a small enough size that the distance calculated
by `project_brush_radius` becomes 0.
When this value is set as the actual brush size, the `wm.radial_control`
operator fails to work properly as the new size is now lower than the
expected minimum value, causing incorrect clamping of the modal value.
Pull Request: https://projects.blender.org/blender/blender/pulls/129937
Drivers should perform a limit check when creating images and return
`VK_ERROR_OUT_OF_DEVICE_MEMORY`. However there are drivers where this
check is a pass-through and leads to `VK_ERROR_DEVICE_LOST`.
This issue was introduced !128877 and only shows up on official NVIDIA
drivers.
Pull Request: https://projects.blender.org/blender/blender/pulls/129939
There is an issue in the GPU depth picking that is only visible
in official AMD/NVIDIA drivers. AMD does pick objects that are
around the cursor. NVIDIA drivers include any overlay objects.
This PR will disable GPU pick selection for AMD/NVIDIA official
drivers. This will limit some selection functionality.
This PR will be reverted in Blender 4.4 to find the root cause.
Ref: #128624, #127768
Pull Request: https://projects.blender.org/blender/blender/pulls/129863
When using a lot of instances the requested and needed attributes
are merged. This process uses a lock even when no work needs to be
done.
By early exiting the merging process when no work needs to be done
the performance of navigating 60k cubes went from 17.5 fps to 18.3 fps.
Detected when researching #126391.
Pull Request: https://projects.blender.org/blender/blender/pulls/129791
When opening the asset shelf brush selector popup in paint modes, clicking on a
catalog on the left wouldn't refresh the popup properly. Two catalog items
would be drawn as active, and the active catalog change wouldn't be reflected.
Only some mouse movements would trigger an update eventually.
Do copy asset data when copying an ID into the PartialWriteContext.
Currently there does not seem to be any use-case where this would not be
the desired behavior. This can be made an optional behavior in the
future if needed.
This lead to infinitely small return values from
`paint_space_stroke_spacing` (since the size can become so small) which
in turn causes an infinite loop in `paint_space_stroke`.
Was considering clamping to some other measure (e.g. based on bounding
box factors), but these might not work well in all circumstances
(dyntopo on a terrain-size mesh might still need tiny spacing), so
settled to clamp to the minimal numerical value.
Pull Request: https://projects.blender.org/blender/blender/pulls/129908
This was caused by `drw_ResourceID` taking one vertex input
(at slot 15) which was then also used by material shaders.
Starting material shaders at 14 in this case avoid the overlap.
Note that this reduces the amount of supported attribute when
using the workarounds by one.
This commit adds a minimal, simple detection for future, incompatible
blendfiles (in case the header itself is modified).
The current available info does not allow to be more specific, but at
least this avoids telling users that it is not a blendfile.
In the future, the new header format designed in #129309 for Blender 5.0
should allow for a better report (since the first 16 bytes of the header
should always have the same meaning from there on).
Pull Request: https://projects.blender.org/blender/blender/pulls/129875
The issue was that changing the area did not immediately update the
`snode->edittree` when changing between different node editor types. That update
only happened later in `node_area_refresh`. However, by that time, the `poll`
function of the modal operator has already succeeded even though when there
operator actually starts `poll` would not succeed anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/129870
Caused by 2 issues:
- Incorrect logic when checking if added key matches last key
- FPS mismatch not compensated in `SEQ_retiming_key_speed_set()`
Also `seq_retiming_evaluate()` output was not clamped to 0-1 range. This
was not causing issues in sample .blend file, but output should be
clamped.
Pull Request: https://projects.blender.org/blender/blender/pulls/129838
Verge groups operations such as assign/remove/select/deselect from data
properties tab edits all drawings instead of visible drawings at current
frame. Now fixed with `retrieve_editable_drawings`.
For remove/remove_from operator, separate PR is created: !129890
Pull Request: https://projects.blender.org/blender/blender/pulls/129789
Mesh filter modes that use averaged neighbor data were not passing in
the mesh `hide_poly` attribute data, leading to incorrect behavior when
calculating averaged positions. To fix this and account for hidden
elements since we are operating on the entire mesh, we pass in the
attribute and use the `neighbor_data_average_mesh_check_loose` method to
account for vertices with no neighbors.
Pull Request: https://projects.blender.org/blender/blender/pulls/129886
No idea why this was not reported before... Kind of critical info here.
Committed directly to 4.2 as:
* This is trivial change with extremely small risk of causing issues.
* Gold team at the studio needs it to better cleanup the production
files for publication.
Follow what was already done with the "reload" operator and tag the
Image ID during "replace".
A tag of "0" is used for now until we can investigate why the other more
appropriate values are not working.
Pull Request: https://projects.blender.org/blender/blender/pulls/129619
This would happen if the viewport with large enough
and a tile resolution of 1:1 was choosen.
This changes the fallback behavior from simply clamping
the resolution (which did break a lot of math downstream),
to simply finding the next largest tile size that fits
the hardware requirements.
Crash manifested after the inclusion of #128877.
The very tall 3D texture tested by the new code
were not supported / tested by the Metal Backend.
Simply adding the appropriate upfront checks fixes
the issue.
Needs to be backported to 4.2
Adding a dummy storage buffer to the classification shader
seems to fix the issue on Qualcomm drivers (WoA).
The workaround is added to the force workaround option to
allow other platforms to test the fix.
Rel #122837
Pull Request: https://projects.blender.org/blender/blender/pulls/129857
Code used library reloading which would reload all data-blocks from a
data-block library. Since the essentials brushes are stored in a single
.blend file (one per mode), they would all be reset. In general this
violates the design where multiple brushes in a single .blend file
should be usable just fine. (A single file per brush is only necessary
to allow saving edits to that file without opening it.)
Instead of library reloading, delete the brush from the current file and
re-link it.
The link/append API should probably get support for reloading a single
data-block (and optionally its dependencies) but for now this is not
supported yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/129866
Some modifiers expect the curves to be of type `POLY`.
For such modifiers we need to resample the curves to the
evaluated points so that the modifiers work as expected.
Resolves#129859.
Pull Request: https://projects.blender.org/blender/blender/pulls/129860
The issue was that with a96f1208cc the clamping
of the `View2D` happened in the drawing function
of the channel list. That of course won't work if the
channel list isn't drawn.
The fix is to ALSO clamp in the drawing function of
the main area. The reason this has to be in addition, is that
(I think) the channel box is drawn first. So if the clamping doesn't
happen there, the channels and their keys can lose their vertical
alignment.
Pull Request: https://projects.blender.org/blender/blender/pulls/129864
Armature::collection_array was indexed with -1,
returning an invalid collection.
When the collection index isn't usable, create a new collection
with the default name.
Ref !129608
