For Metal we can change the texture usage flags to get more optimal
behaviour - one example is adding the attachment flag so we can utilise
renders to do texture clears. However these usage flags are used as the
part of the match-criteria when trying to reuse released textures in
the texture pool.
The modifications means a request for the same type of texture will
fail causing a cache miss. When we render to an
image-view the texture pool is not released until the final sample has
been rendered as we consider the entire render to be a single frame
(as opposed to normal viewport rendering when we are presenting the
intermediate results).
This causes the texture pool to grow and grow and grow hence the large
memory usage. This fix splits the usage flags
into two sets, the internal ones we use to create the MTLTexture (which
we may modify) and the originally requested ones. The originally requested
ones are used for the texture pool matching.
This fix also improves memory efficiency for normal viewport rendering.
Mr Elephant Scene
Before -> After
Load scene in viewport: 13.04Gb -> 9.15 Gb
Viewport Render Image: 78.69Gb -> 16.61Gb
Authored by Apple: James McCarthy
Pull Request: https://projects.blender.org/blender/blender/pulls/129951
Brushes and changes done to them are preserved now when loading
different files (until Blender closes). Unpin and clear the material
assigned to the brush when loading a different file, since this material
is local to the previous file.
Pull Request: https://projects.blender.org/blender/blender/pulls/128080
GPv3 Undo loading code would not clear the active node pointer, leaving
it to point to an invalid (freed) memory, in case there is no active
node in the loaded undo step.
Pull Request: https://projects.blender.org/blender/blender/pulls/129918
Code detecting unused drawings and swapping them with a used one would
fail in a most basic case, leading to invalid state down the line:
```
[used_drawing, unused_drawing]
```
`unused_drawing` was not properly removed, as it is expected.
NOTE: Added an extra assert on (presumably) expected conditions of the
drawing indices and drawings array at the end of the process.
Co-authored-by: Lukas Tönne <lukas@blender.org>
Catch any exception from the JSON parser and handle it by returning a
null value from the deserialization function. Let the asset indexer
regenerate the index file to handle the error.
At least for the asset index case we don't care about the exact parsing
error, so this simple error handling strategy is fine. Should more
precise error reporting be necessary for other use-cases this can be
added still, but I think these errors are usually a bit too low level to
expose to users.
Pull Request: https://projects.blender.org/blender/blender/pulls/129879
When the light volume probe cannot be allocated a pool of a different
size is used. A message is displayed to the user. This PR improves the
message by adding the previous size as well.
Ref #129889
Pull Request: https://projects.blender.org/blender/blender/pulls/129963
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
