Instead of computing an index mask for all curves, then returning an
intersection with the visible curves, just use the visible curves as
a universe for the original calculation. Also add another early out
for when there are no NURBS curves.
Currently the drawing data extraction code uses the offset indices API
quite inefficiently, copying the size of every selected every curve, then
accumulating those sizes. Instead just use the existing API function that
counts the size of all selected curves. Also for the weight overlay, avoid
doing the same calculation twice.
There is no real reason to keep these read-only, they are not exposed in
the UI anyway, and being able to edit them can become necessary in a
pipeline mamangement context.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135870
This patch refactors the result class to replace proxy results with the
possibility of doing data sharing through a shared heap allocated data
reference count. This is more robust and simpler since proxy results no
longer need to be handled as a special case in a lot of the results
code. Additionally, it allows stronger const correctness since inputs to
operations can now be const.
This is somewhat similar to implicit sharing used in other parts of
Blender, so we can look into using that in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/135778
It seems that this was 'fine', as non-trivial data in `BVHTreeFromMesh`
appear to be 'safe' when simply zero-initialized instead of being
properly constructed.
Note that this 'calloced' data was already 'MEM_deleted', this is
currently considered as a valid use-case unfortunately, otherwise the
issue would have been detected earlier.
Directly use 'copy' `MEM_new` code instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135862
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135855
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135852
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135813
This patch adds the ability to snap to the frame range bounds in the VSE
timeline, on by default. End frame snap location is offset by 1 to
ensure the snap point aligns with the visible end frame boundary
(otherwise e.g. right handle of strip would be one frame short).
Timeline and preview snapping is also turned on by default using the
same versioning block.
Pull Request: https://projects.blender.org/blender/blender/pulls/135753
There is a bug in OpenEXR bug where it requests at least 4096 bytes even
if the file is smaller than that. Work around it by padding with zeros.
This was fixed upstream in commit 97f857131e6b4c43ab after the 3.3.2
release, but not in any official release yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/135796
This replaces the implicit use of the `radius` attribute on the input
curves with an input field `Scale` that gets evaluated on the point
domain of the input curves to scale the profile.
It wasn't super intuitive that the `radius` would actually act as
a scale of the profile. E.g. if the radius of the input curve was
`1 meter` the resulting profile was unscaled (scaled by 1), but
wouldn't necessarily have a size of `1 meter` (only if the profile
also had a size of 1m)! If imperial units were used, `3.28084 ft`
would correspond to a scale of 1.
This change makes this behavior a lot more clear and potentially
removes the need for the assumption that the default curve radius
is `1.0f` (Ideally, the default curve radius should be `0.01f`).
While we did consider making the `Scale` input use the `radius`
field implicitly by default, we decided against it, because it again
"hides" the dependency on the radius and the fact that the radius
is used as a scale. Letting the user make this decision seems better.
Pull Request: https://projects.blender.org/blender/blender/pulls/134187
The issue was that the `FCURVE_DISABLED` flag is set when an
RNA path cannot be resolved, and that skips evaluation.
However in the specific case, that is actually something expected as
the property only exists on one ID and not the other.
Pull Request: https://projects.blender.org/blender/blender/pulls/135782
Part of #134755 / #134766.
Add the blend file name and directory path to the tooltip of assets in
custom asset libraries (as configured in the Preferences), for the asset
browser and asset shelf. This information is often important when
dealing with production assets. In the asset shelf it wasn't available
at all.
Based on feedback from the Blender Studio.
Using `UI_but_func_tooltip_custom_set()` to create a custom tooltip
would completely disable the quicker label tooltip, even when explicitly
set using `UI_but_func_tooltip_label_set()`. Instead the quick label
should show first, and then the full tooltip once the usual tooltip
timer is reached.
**How to reproduce:**
1. Add Cryptomatte Node
2. Enable 'Object' render passes
3. Connect Cryptomatte to output (composite or viewer node)
4. Optional: set matte ID
5. (Do not connect input image)
6. Render
7. Observe invalid output image (or assert in debug build)
(see also PR for an example blend file)
Only CPU is affected. The solution follows the behavior of the GPU backend, where the input color of the single value input image is multiplied with the matte result to produce a non constant output.
Pull Request: https://projects.blender.org/blender/blender/pulls/135786
Add an explanation to the keyframe insertion function
`animrig::insert_keyframes()` as to why it does not use
`ID_RECALC_ANIMATION`:
Animation flushing would be quite annoying in the following case:
- Key Cube's loc/rot/scale.
- Go to another frame.
- Translate, rotate, and scale the cube.
- Hover over the loc/rot/scale properties and one by one press 'I' to
insert a key there.
If `ID_RECALC_ANIMATION` were used, keying the location would immediately
cause a flush of the animation data, popping the rotation and scale back
to their animated values.
No functional changes.
**How to reproduce:**
1. Add Cryptomatte Node
2. Enable 'Object' render passes
3. Connect Cryptomatte to output (composite or viewer node)
4. Optional: set matte ID
5. (Do not connect input image)
6. Render
7. Observe invalid output image (or assert in debug build)
(see also PR for an example blend file)
Only CPU is affected. The solution follows the behavior of the GPU backend, where the input color of the single value input image is multiplied with the matte result to produce a non constant output.
Pull Request: https://projects.blender.org/blender/blender/pulls/135786
When saving a file, move the catalog service from the runtime asset library into the new on-disk
asset library. This makes all catalog data like the undo history and deleted catalogs be preserved.
The fact that a new asset library type gets allocated is an implementation detail that shouldn't
affect behavior.
Once the service is moved, an undo push is added (so this state can be restored to), and if the new
.blend file location can be associated with a catalog definition file, its catalogs are merged in.
Includes unit tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/135589
This removes the use of `system_gpu_context_mutex`
which was making render command submission threadsafe.
The only issue is the concurent usage of GPUShader objects.
To fix this, we only guard the submission section which
are the only parts that uses the GPUShaders.
Removing this critical section all together requires some changes
in the GPUShader. See #135406
Rel #134690
Pull Request: https://projects.blender.org/blender/blender/pulls/135595
Material user count in duplicated ob.data is not updated. Separate layer
operation later iterates over all the material slots thenremoves unused
slots from respective objects. Since id.us=1 for individual material, if
material is used by one object but not the other, count is decremented
to zero. If we use `USER_DUP_GPENCIL` then user count is properly
handled in `grease_pencil_foreach_id/id_copy_libmanagement_cb`.
Pull Request: https://projects.blender.org/blender/blender/pulls/135769
When a layer channel is clicked to select inside dopesheet editor, this
sets the flag `GP_LAYER_TREE_NODE_SELECT` (i.e. is_selected() to true),
It prevents separate layer operation to create a new object for this
layer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135765
This PR enabled GPU based subdivision on Metal.
Most work is done in #135296.
- Metal max storage bindings for compute shaders were never set.
Some performance figures: Suzanne 6 subdivision levels
| Machine | CPU Subdivision | GPU Subdivision |
| --------------- | --------------- | --------------- |
| M1 Studio Ultra | 7fps | 12 fps |
| M2 Air | 3fps | 11 fps |
Pull Request: https://projects.blender.org/blender/blender/pulls/135628
This PR enabled GPU subdivision on Vulkan backend. Measured
performance is slower compared to CPU on my system. But it is
expected that other bottlenecks should be solved in order to
fully benefit from this feature.
We enable it so we keep track of the performance bottlenecks.
Pull Request: https://projects.blender.org/blender/blender/pulls/135777
