Recently it came to out attention that macOs13 doesn't always work due
to texture atomics not supported by that version of the OS.
Development happens most of the time on newer versions of the OS without
ability to check if it still works on the older versions.
This PR enables to disable some Metal capabilities to better check how
Blender works on those OS's. The capabilities that will be disabled
are texture gathering and texture atomics. It doesn't disable the
capabilities that are required to start Blender, which are still
part of the `MTLCapabilities` struct.
This allows us to reproduce issues like #129571
Pull Request: https://projects.blender.org/blender/blender/pulls/133636
When moving an object with a motion path and animdata but no assigned
action, and with certain auto-key settings enabled, Blender would crash.
The cause was code that tried to access an action's fcurves without
proper guarding: the guard checked whether an object had animdata, but
not whether it had an action assigned or not, and would happily try to
access that non-existent action's fcurves.
This fixes the crash by also checking if an action is assigned.
Pull Request: https://projects.blender.org/blender/blender/pulls/133552
This PR implements a new the threading model for building render graphs
based on tests performed last month. For out workload multithreaded
command building will block in the driver or device. So better to use a
single thread for command building.
Details of the internal working is documented at https://developer.blender.org/docs/features/gpu/vulkan/render_graph/
- When a context is activated on a thread the context asks for a
render graph it can use by calling `VKDevice::render_graph_new`.
- Parts of the GPU backend that requires GPU commands will add a
specific render graph node to the render graph. The nodes also
contains a reference to all resources it needs including the
access it needs and the image layout.
- When the context is flushed the render graph is submitted to the
device by calling `VKDevice::render_graph_submit`.
- The device puts the render graph in `VKDevice::submission_pool`.
- There is a single background thread that gets the next render
graph to send to the GPU (`VKDevice::submission_runner`).
- Reorder the commands of the render graph to comply with Vulkan
specific command order rules and reducing possible bottlenecks.
(`VKScheduler`)
- Generate the required barriers `VKCommandBuilder::groups_extract_barriers`.
This is a separate step to reduce resource locking giving other
threads access to the resource states when they are building
the render graph nodes.
- GPU commands and pipeline barriers are recorded to a VkCommandBuffer.
(`VKCommandBuilder::record_commands`)
- When completed the command buffer can be submitted to the device
queue. `vkQueueSubmit`
- Render graphs that have been submitted can be reused by a next
thread. This is done by pushing the render graph to the
`VKDevice::unused_render_graphs` queue.
Pull Request: https://projects.blender.org/blender/blender/pulls/132681
PR #133601 exposes some holes in the Status Bar display. Currently you
can see keymap entries for other areas, like 3D View, when hovering in
the Top Bar. Or see the wrong items when hovering in a non-region
portions of an area. Or see keymap entries for window regions while
hovering headers. This PR fixes all these things.
Pull Request: https://projects.blender.org/blender/blender/pulls/133620
When your mouse is hovering in the gaps between editors the Status Bar
indicates that you can resize and bring up context options. This same
gap is also along the outside window edges even though not visible and
so shows these options when not applicable. This PR carefully shows the
actual area options right up to the edge instead. And also does not
show "Resize" for the gap between global areas and the rest.
Pull Request: https://projects.blender.org/blender/blender/pulls/133601
Paste and text insert could delete selected text, but then cancel
operator execution due to buffer being too small. Ensure, that operator
returns value based on state being actually changed or not.
Pull Request: https://projects.blender.org/blender/blender/pulls/133569
After 0e8e219d71 / efb511a76d, memfile undo step is not used for writing
the autosave file, instead regular file saving function is used (`BLO_write_file`).
With that it is possible to compress the file when `G_FILE_COMPRESS`
flag is set.
As discussed in !132685, always compress auto-save .blend file
irrespective of `USER_FILECOMPRESS`
Pull Request: https://projects.blender.org/blender/blender/pulls/132685
Caused by db73ef0f2f
The displacement smear brush works by evaluating the previous
displacement of a given neighbor vertex to generate a weighted average.
Prior to the linked commit, the mesh-sized `prev_displacement` array
would be initialized to (0.0, 0.0, 0.0) by subtracting the
`limit_surface_co` from itself.
in certain cases, a neighbor vertex value may not be initialized,
causing NaN to get propagated through the mesh.
To fix this, and avoid needing to reintroduce this unnecessary
computation, explicitly initialize `prev_displacement` to an array of
(0.0f, 0.0f, 0.0f).
Pull Request: https://projects.blender.org/blender/blender/pulls/133522
Instead of requiring an image buffer to draw a bigger preview image
while dragging, allow passing an icon ID and draw that as preview. This
is also how we draw previews elsewhere. Use this for attaching the asset
previews to draggable buttons.
A small user visible change is that previews from the asset browser will
always draw at the default size (multiplied by the interface scale)
while dragging. Previously it used the same size as the asset browser
preview size, which I don't think was useful really. With small sizes
the preview while dragging got unnecessarily small too, with big sizes
it got in the way.
Needed for #131871.
Custom preview images loaded from disk are supposed to load one by one
in a background thread, but pop up in the UI as they get ready. This
gradual/progressive loading wasn't working correctly, previews would
only show up after all current preview requests were handled. I think
there would still be some progressive loading, since handling a batch of
requests might finish before all requests for the current frame are in.
Now it works as intended, by actually tagging loaded previews.
Mistake in 16ab6111f7.
Noticed while working on #131871.
When loading preview images from disk, we'd first scale them to the
standard preview image size (in `icon_copy_rect()`) and then scale them
again to the drawing size when eventually drawing to screen. The first
scaling would happen on the CPU, which is slow, and without filtering.
Now the image is stored in its original size and only scaled when
drawing, which uses scaling on the GPU with mipmaps and bi-linear
filtering. While a bit more blurry, the resulting image has less
artifacts and represents the original image better. Keeping the images
unscaled means memory footprint is bigger, we could cap the size if
necessary.
Noticed while working on #131871. Asset shelf previews would have more
artifacts than before.
See pull request for comparisons.
Pull Request: https://projects.blender.org/blender/blender/pulls/133559
The handling of influence vertexgroups was incomplete/inconsistent.
Some prior work was already done in 08539618cd, c452d5d9e8,
782a4c9d85, 0fd3f3c216, 434f94b254, 82ea972834, f6b820ccb7,
00968fe6db .
Now that the inverting is handled consistently, we can move that part
out of specific modifier code an into the generic retrieval function
`greasepencil::get_influence_vertex_weights` -- resulting in all
modifiers using it behaving the same.
There were some modifiers already handling
`GREASE_PENCIL_INFLUENCE_INVERT_VERTEX_GROUP`, however even those still
had one issue: if no vertexgroup was set, invert would still have been
calculated (this issue is also resolved with this PR).
Remaining modifiers that were offering influence vertexgroups (e.g.
Noise) but ignoring it now work correctly.
NOTE: there are still modifiers handling influence vertexgroups outside
of `greasepencil::get_influence_vertex_weights`:
- Armature (has own code for this in
`BKE_armature_deform_coords_with_curves`)
- Shrinkwrap (has own code for this in `shrinkwrapParams_deform`)
- Thickness (this rather special behavior is untouched)
Pull Request: https://projects.blender.org/blender/blender/pulls/133426
This patch delays applying transformations until realization happens on
some other domain.
Currently, transformations are applied immediately at the point of
transform nodes, this is problematic for a few reasons:
- If that result was then realized on some other domain, interpolation
will have happened two times, at the transform nodes and at the node
that required realization, causing less than ideal precision issues.
- It is not possible to repeat or extend a rotated result because its
empty areas will be zero filled, leaving gaps in its extension. So
this patch is a prerequisite for #132371 if we want full support for
repetition.
- Doing inverse transformations will introduce interpolation artifacts
which might be undesirable. Inverse transformations might be used to
do pixelation for instance, so this change will be undesirable in this
case. But we decided that this is not a use case that we want to
support, and we added explicit pixel size control to the pixelate node
as an alternative.
So this has four implications, two that might be considered bad:
- Transformations will now be higher quality and more precise.
- Repetition and other boundary extension methods will now be possible.
- Downsampling then upsampling will no longer produce pixelated results.
- Realization might happen multiple times with identical results in some
cases.
The last point not a big issue, since domain realization is not a big
bottleneck in the compositor, and the plan is to move realization into
pixel operations, so it will even be more efficient than it is now.
Pull Request: https://projects.blender.org/blender/blender/pulls/133158
This changes the `ListBase` argument for certain motion path functions
to `Vector<MPathTarget *>`. (and `Span`)
To better describe what the function is doing,
`animviz_get_object_motionpaths` has been renamed
to `animviz_build_motionpath_targets`.
Since `BLI_freelistN` can no longer be used, I added
`animviz_free_motionpath_targets`.
Note that the Vector is of `MPathTarget *` which
are allocated the C way. Because the `MPathTarget` struct is defined
in the .cc file, that's the only way for it to work atm.
Other refactors may mitigate that in the future, but I wanted to keep
the scope small.
Pull Request: https://projects.blender.org/blender/blender/pulls/133212
Vulkan shader compiler accesses the cache folder via multiple threads.
GHOST part isn't thread safe and can return and overwrite the returned
cache path. This resulted into crashes when performing background
rendering and failing test cases, loading of incorrect shaders etc.
This PR fixes this to cache the cache folder location in the
VKShaderCompiler, which is loaded via the main thread when the vulkan
backend is initialized.
Pull Request: https://projects.blender.org/blender/blender/pulls/133535
The core issue was that the geometry batch cache (e.g. `MeshBatchCache` or
`PointCloudBatchCache`) was dependent on the object. This is problematic when
the the same geometry is used with multiple different objects because the cache
can't be consistent with all of them.
Fortunately, the only thing that was retrieved from the object was the number of
material slots, so if that can be avoided we should be fine. We can't just use
the number of material slots stored on the geometry because that may have no
material slots but still has material indices which are overridden on the object
level.
The solution is to take make the number of materials for a geometry only
dependent on the actual `material_index` attribute and not on the number of
available slots. More specifically, we find the maximal referenced material
index and handle that many materials. This number does not depend on how many
material slots there are on the object, but it still allows the object to
override materials slots that the mesh references.
A downside is that the maximum material index has to be computed which often
requires an iteration over the mesh. Fortunately, we can cache that quite easily
and the computation can be done in parallel. Also we are probably able to
eagerly update the material index in many cases when it's set instead of
computing it lazily. That is not implemented in this patch though.
The largest part of the patch is making the maximal material index easily
available on all the geometry types. Besides that, the material API is slightly
replaced and the drawing code now makes use of the updated API.
Pull Request: https://projects.blender.org/blender/blender/pulls/133498
Memory areas was requested to be preferable host visible. On some
platforms this would fail to allocate. Best is to not add preferable
host visible for typically large allocations.
This PR also gives the caller the responsibility to set the allocation flags.
Pull Request: https://projects.blender.org/blender/blender/pulls/133528
Set sample tool as default for `view` mode of image editor.
Also expanded the condition in `toolsystem_key_ensure_check` so default
tool can be obtained inn view ui_mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/133471
The issue was twofold, the `draw_tests` library was missing a link
dependency on `gpu_tests`, and the `gpu_tests` would only be generated
if `WITH_GPU_BACKEND_TESTS` or `WITH_VULKAN_BACKEND` were also ON due
to a superflous condition.
Pull Request: https://projects.blender.org/blender/blender/pulls/133511
This implements all the auto masking options in sculpt mode.
* Stroke: Only affects strokes that are initially under the cursor.
* Layer: Only affect strokes in the same layer as the initial strokes under the cursor.
* Material: Only affect strokes with the same material as the initial strokes under the cursor.
* Active Layer: Only affect strokes in the active layer.
* Active Material: Only affect strokes that use the active material.
The `Active Layer` toggle in the toolbar has been moved to this panel.
Resolves#130022.
Pull Request: https://projects.blender.org/blender/blender/pulls/132986
This patch uses OCIO luminance for implicit conversion from color to
float in the compositor. This is done to match other node systems, and
because luminance is a much better default than the average formula used
before.
Versioning was added to retain average conversion for old files.
Pull Request: https://projects.blender.org/blender/blender/pulls/133206
This would change the image type in image_save_post, which would make the
logic in BKE_image_acquire/release_renderresult mismatched.
Also consistently call BKE_image_release_renderresult when the render result
is null, rather than only doing it half the time.
Pull Request: https://projects.blender.org/blender/blender/pulls/133503
* Ensure valid bit depth is set along with file type
* Guard against invalid inputs in stereo imbuf creation
* Remove some unused code
Thanks Yiming Wu for finding the cause.
Pull Request: https://projects.blender.org/blender/blender/pulls/133499
This add back the NDC offset that was present in the legacy overlay.
But instead of adding a new view for it, we add `ndc_offset_factor`
to `State` to simplify wire offseting
Instead of modifying the projection matrix, we compute the unit
offset and pass it to the shader which choose the appropriate
factor to apply to the vertex position.
The value is put inside `State` so that it can be referenced
easily by multiple overlays.
Later on (once we move the global UBO inside Overlay) we can
move this to a UBO.
This only implements it for wireframe and edit mesh vert and
edges.
Note: that there seems to be some code duplication with the
edit mesh vertex code. That's to be tackled in another commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/133433
