Caused by 6c05859b12
OpenVDB does not handle transformations with determinants smaller than
3e-15 and throws an `ArithmeticError` when a `Transform` is created
with invalid values.
To avoid abrupt crashes on the user side, this commit catches the error
and displays a warning message.
Pull Request: https://projects.blender.org/blender/blender/pulls/136690
This adds a new Camera Info node to Geometry Nodes. It provides information
about the passed in camera like its projection matrix and focus distance.
This can be used for camera culling which was must more complex before.
It also allows building other view-dependent effects.
Pull Request: https://projects.blender.org/blender/blender/pulls/135311
Found this while reviewing #136021. It's somewhat surprising that this didn't cause issues before.
This patch also adds some unit tests for `BLI_str_endswith` and `BLI_str_startswith`.
Pull Request: https://projects.blender.org/blender/blender/pulls/136679
In Geometry Nodes a geometry is represented by a `GeometrySet`. This is a
container that can contain one geometry of each of the supported types (mesh,
curves, volume, grease pencil, pointcloud, instances). It's possible for a
`GeometrySet` to contain e.g. a mesh and a point cloud.
This patch creates a Python wrapper for the built-in `GeometrySet`. For now,
it's main purpose is to consume the complete evaluated geometry of an object
without having to go through complex hoops via `depsgraph.object_instances`. It
also also allows retrieving instances that have been created with legacy
instancing systems such as dupli-verts or particles.
In the future, the `GeometrySet` API could also be used for more kinds of
geometry processing from Python, similar to how we use `GeometrySet` internally
as generic geometry storage.
Since we can't really have constness guarantees in Python currently, it's
enforced that the `GeometrySet` wrapper always has its own copy of each geometry
type (so e.g. it does not share a `Mesh` data-block pointer with any other place
in Blender). Without the copy, changes to the mesh in the geometry set would
also affect the evaluated geometry that Blender sees. The copy has a small cost,
but typically the overhead should be low, because attributes and other run-time
data can still be shared. This should be entirely thread-safe, assuming that no
code modifies implicitly shared data, which is forbidden. For historic reasons
there are still cases like #132423 where this assumption does not hold in all
cases. Those cases should be fixed. To my knowledge, this patch does not
introduce any new such issues or makes existing issues worse.
Pull Request: https://projects.blender.org/blender/blender/pulls/135318
Adds a new argument for the class constructor as well as a new macro to
support printing the rolling average of a number of samples intead of
the total average.
This can be useful for getting a sample of an average durations in
functions that are continually running, e.g. the main event loop.
Pull Request: https://projects.blender.org/blender/blender/pulls/136530
The selection and lengths for the resampling of the outline were based
on the original curves rather than the generated outline curves causing
out of bounds access.
---
#### Problem
Exporting grease pencil objects and setting the "Sampling" option
to higher than 0.0 will cause a crash during export.
In a debug build the following assert is triggert:
```
BLI_assert failed: C:\Users\leons\dev\blender-git\blender\source\blender\blenlib\BLI_virtual_array.hh:625, operator [](), at 'index < this->size()'
```
##### Steps to reproduce the issue
1. Open the attached .blend file: [gp-export-resample-crash.blend](/attachments/3be6839f-3376-4d75-ad54-077f1eeab472)
2. Select the "Monkey" grease pencil object and export it as PDF or SVG
3. In the export dialog set the "Sampling" to something other than `0.0` e.g. `0.2`
4. Confirm.
5. Blender should crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/136585
When mouse is moved from one area to other of same spacetype, previous
region is not redrawn. This results in tooltip being stuck at the edge of
previous area. In such case, send a redraw call to that region.
Pull Request: https://projects.blender.org/blender/blender/pulls/136168
The Blender config.ocio does not have any rules, but custom ones can.
The default file rule is ignored if default_byte or default_float roles
exist. These roles are Blender specific, so would not be found in a typical
OCIO config. But when they are set appropriately, they help provide better
default guesses than what is possible with standard OCIO rules.
Pull Request: https://projects.blender.org/blender/blender/pulls/136516
The file formats now fill in ImColorSpaceInfo with the metadata colorspace
and a boolean saying if the pixels have HDR colors. And then the actual
colorspace is decided in imb_handle_colorspace_and_alpha.
This centralizes the logic in one place to make it possible to add
OpenColorIO file rules.
Pull Request: https://projects.blender.org/blender/blender/pulls/136516
Function `strip_effect_get_new_inputs` contained selection parsing and
error handling. It also returned values by setting 3 pointer addresses.
Split function to selection parsing which returns strips in container
and validation function, which returns error string if selection is not
valid. If selection is valid, empty string is returned
Pull Request: https://projects.blender.org/blender/blender/pulls/136474
This should ideally be used more in Geometry Nodes to avoid realizing subdiv
on the cpu if it's not really necessary. However, fully supporting it require more changes
in places that actually need the final subdivided mesh.
This also extends the "to string" conversion for `GeometrySet` to include information
about the subdivision level.
When using a small brush size, if enough latency is encountered,
sculpting can become unresponsive. See #131334 for more in-depth
information on this issue.
In general, this is most apparent to users with the Smooth brush and
any brushes with auto-smoothing enabled. Much of the work for this
brush action is in retrieving and averaging the neighboring vertex
positions. This is wasted work for vertices outside of the brush radius,
as ultimately they will have no displacement applied to them.
To help mitigate this performance regression, this PR adds a variant
of functions that calculate neighboring vertices that takes in the
precalculated `factor` to skip further processing. Additionally, some
methods are restructured to take advantage of this.
This change represents a speedup of 4x, from `0.40ms` without this
patch to `0.10ms` with it on a cube with 400k vertices and a brush
radius of 10px. For most brush size to BVH Node / Mesh ratios, we see
improvements, as we can avoid processing most nodes that a brush only
affects a small number of vertices of. For cases where the entire mesh
is affected by a brush, this patch does introduce a small but
measurable slowdown of 0.31ms to 0.33ms.
Ref: #136006
Pull Request: https://projects.blender.org/blender/blender/pulls/136274
The Blender's VkInstance cannot be shared with OpenXR VkInstance. The
reason is a chicken and egg problem where OpenXR needs to be started
before Vulkan. OpenXR can add special vulkan specific requirements
(instance&device) that are only available when the user starts an OpenXR
session.
The goal implementation is to share memory between both instances using
[VK_KHR_external_memory](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory.html) and related extensions. However this seems
to be a bridge to far as a initial step. Reason: There are not that many
samples/ guides and documentation to be found to handle the workflow that
we require. We want to do a smaller step by step approach to gain the needed
knowledge.
For that reason this PR does the most stupidest thing that can be done to
share memory between instances. Download the render result to CPU RAM share
the host pointer with the OpenXR instance which copies it to the swap chain.
Also the synchronization is done using wait idle commands.
<video src="attachments/32a0d69b-c3fa-4272-aea0-d207609afaaf" title="Screencast From 2025-03-18 11-16-17.webm" controls></video>
**Gaining knowledge**
- Experiment with `VK_KHR_external_memory_host` extension for uploading vertex buffers (not related to OpenXR).
- Import host pointer with `VK_KHR_external_memory_host`. This reduces the additional
memcpy on OpenXR side.
- Export host pointer from Blender side from a mappable buffer.
- Replace host pointers with fd/dmabuf/winhandle
- Remove mappable buffer.
Ref #133718
Pull Request: https://projects.blender.org/blender/blender/pulls/133824
Followup to 9b70851d91.
Return buffers by value rather than creating an empty/uninitialized
buffer first, then initializing it in an extraction function. This generally
makes the code easier to follow. And avoiding these half-created buffers
is an essential step to adding some sort of more global cache.
Pull Request: https://projects.blender.org/blender/blender/pulls/136570
python3.dll was installed for blender, but not next to the
python binary, leading to issues with subprocesses. Given
it's only a small dll the duplication isn't that big of a deal.
Add support for using the Stash (to NLA) and Push Down operators on
empty Actions. In the past years, the NLA has seen stability updates
that ensure strips are at least a single frame long, and with that even
pushing down an empty Action will create a visible (albeit tiny) NLA
strip. There doesn't seem to be a practical reason to disallow this any
more.
Pull Request: https://projects.blender.org/blender/blender/pulls/136604
It is possible to un-assign the action slot from an NLA strip. If then
you enter tweak mode on it and insert keys, a new slot is created on the
Action (so far so good). However, exiting tweak mode did not assign that
slot to the NLA strip, deactivating the animation. This is now solved.
The slot assignment is done when exiting tweak mode because that's
when the whole "sync from assigned Action back to the NLA strip"
happens. Also things like syncing the strip length is done at
tweak-exit, so that seemed like the right place to me to do this too.
Pull Request: https://projects.blender.org/blender/blender/pulls/136601
Update all F-Curves so they have the correct flags (`FCURVE_INT_VALUES`,
`FCURVE_DISCRETE_VALUES`) for the RNA property type that they animate.
The bug that caused these flags to be incorrect (#136347) is already
fixed. This commit ensures that F-Curves that were created while the bug
was in a Blender release are updated to ensure they have the correct
flags.
This is quite important to fix, as otherwise enum properties will
actually be interpolated. Imagine the "fun" when a rig is going
through all the intermediate rotation modes when it was intended to
switch from "Quaternion" to "ZYX".
Even before this commit, these flags were already recomputed on key
insertion (at least the ones through the UI). The versioning code simply
runs this update on all existing F-Curves.
Since this may have some performance impact (doing an RNA path resolve
on all F-Curves on all Actions), the versioning code is only run when
the blend file is from 4.4 or newer, as the bug was introduced in that
release.
Pull Request: https://projects.blender.org/blender/blender/pulls/136512
