Operators that added themselves as modal handlers would crash if there
was a Python exception in the script before returning.
Now modal handlers are removed an exception occurs in exec & invoke
operator callbacks.
This currently contains some types I personally needed
more types can be added if people desire them.
Due to the .natvis being added to creator, Visual Studio
will automatically pick up on these types and show the
improved visualizers while debugging.
vscode can also use this file, but you'll have to check
its documentation on how to set that up.
Pull Request: https://projects.blender.org/blender/blender/pulls/118576
Properly handle exceptions from STL and PLY code to prevent crashes on
invalid file paths.
This will now also Report errors/warnings to the callers of these
formats as well. For the UI this means a Report banner and Info editor
entry. For Python scripts this means an exception instead of silently
continuing.
Related to #117881
Pull Request: https://projects.blender.org/blender/blender/pulls/118731
These expose internal data for unit testing purposes. While it might be
better to avoid this entirely, at least make the returned data const, so
there's no unexpected modification from outside the catalog service
internals.
Making this thread safe is quite trivial now. Note that for building the
tree we iterate the catalogs map, which may still be modified from
another thread in parallel. Making this thread safe is kept for a
separate commit.
Armature deformation modifier for Grease Pencil v3.
Changes compared to GPv2:
- `multi` DNA field was unused and was removed.
- `vert_coords_prev` array is unused and was removed (gets passed to
armature functions but never gets allocated).
- GPv3 modifier uses the common `influence` struct to store the vertex
group name, for consistency. The
`GREASE_PENCIL_INFLUENCE_INVERT_VERTEX_GROUP` flag is copied to
`deformflag` as `ARM_DEF_INVERT_VGROUP` before evaluation, which is
used internally by armature functions.
- `BKE_armature_deform_coords_with_curves` is added as another variant
of the deform function, but uses C++ parameter types (spans instead
of raw pointers). It gets a `Span<MDeformVert>` directly instead of
deducing it internally from the object type. This is because we want
to do this curve-by-curve and already use arbitrary vector spans for
positions.
Pull Request: https://projects.blender.org/blender/blender/pulls/118752
When a new liboverride is created from the IDTemplate UI widget, in case
its hierarchy root is different than the liboverride itself, ensure that
it is also instanciated in the scene, if possible (i.e. if it's an
object or collection).
Should allow for better representation of liboverride hierarchies
created that way, and reduce the risk of getting key liboverrides hidden
from the scene's hierarchy (in the Outliner ViewLayer view e.g.).
LibOverride creation code wrapper when called from the IDTemplates in
the UI was a tad too permissive in its attempts to find the best
possible liboverride hierarchy root, leading to potential invalid linked
ID selection.
Crash happens in `action_group_colors_set_from_posebone` /
`ANIM_bonecolor_posebone_get` on a `bPoseChannel` without a `bone`.
If I am not mistaken a new `bPoseChannel` (e.g. after duplication) will
only get its `bone` after leaving editmode.
So in a way the situation is similar to 2a8ce1f121
Behavior of `animchan_sync_group` is not reliable in a way that getting
a `bPoseChannel` from an `bActionGroup` will guarantee these are really
corresponding. So usually, if you dulplicate/symmetrize a bone, there
would be no corresponding `bActionGroup` and nothing would happen
really. But you could for example group fcurves from `Bone` under a
group called `Bone.001` and vice versa. This is totally allowed to do.
In this case, `animchan_sync_group` is doing nothing totally helpful, so
it could find the "wrong" `bPoseChannel`. And it could try
`action_group_colors_set_from_posebone` with that `bPoseChannel` which
still does not have a `bone` and then crash.
So now only do this if we have a valid `bone`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118676
`RootPChanMap` will be nullptr when building DEG object-level
constraints (as as opposed to bone constraints where this map is built
prior), and in that case we don't need to check for the common chains in
`bone_target_opcode`.
Thx @sergey for additional confirmation
Pull Request: https://projects.blender.org/blender/blender/pulls/118745
On lower end hardware the film accumulation has bad performance. Sometimes
upto 10ms. This PR improves the performance somewhat by adding a
specialization constant around the renderpasses that are actually needed for
rendering, the number of samples and if reprojection is enabled.
`enabled_categories`: Based on the enabled render passes some outer loops are
enabled/disabled that handle the specific render passes. This improves the performance
as no memory will be reserved for branches that are never accessed.
`samples_len` & `use_reprojection`: GPU compilers tend to optimize texture fetches
when they to the outer loop. This is only possible when the inner loop can be unrolled.
In the case of the film accumulation the inner loop couldn't be unrolled. By adding a
specialization constant would allow unrolling of the inner loop.
On old or low-end devices the improvement is around 40%. On newer devices
the improvement is 50+%. Performance of this shader is similar to
the godot.
| GPU | Before | New |
|----------------------|--------|-------|
| NVIDIA GTX 760 | 3.5ms | 2.4ms |
| GFX1036 (RDNA2 iGPU) | 9.9ms | 6.2ms |
| AMD Radeon Pro W7500 | 2.1ms | 0.9ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/118385
When implementing film accumulation specialization constants we came
across a missing implementation for uint as specialization constant.
This is a split-off from the original patch to add support for uint.
When using it is important to compile with asserts on. uint can be casted
to int without knowning. There are assert mechanism that point you to
these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/118750
Currently there are two vertex buffers that contain mesh normals. First, the
normals are extracted and stored interleaved with positions. Then there is
a second vertex buffer for just normals. Interleaving them makes some
sense, since they change together, but it fights with the contiguous storage
benefits of `Mesh` and generally makes code more difficult to optimize.
This PR removes the normals interleaved with the positions and changes
the code for extracting positions and normals from meshes to be simpler
and faster, mainly by not using the "extract iterators" as described by the
#116901 design task. That moves most of the branching outside of hot
loops, so we don't do the same work for every mesh element. This also
gives us the option of not calculating or extracting normals in more
situations like wireframe display in the future.
This is only a small part of the work for #116901, so the state of the code
after this PR will have more design inconsistencies. I'll keep working to
resolve those in the future.
In general I observed at least a 5-40% improvement in FPS in playback
of files with large meshes.
Pull Request: https://projects.blender.org/blender/blender/pulls/116902
This is a migration of the current Line Art modifier to GPv3.
Note:
- The modifier is using the exact same DNA structure as the old one, it's re-defined in a different name. At the moment all the variable names and placement after the `ModifierData` part should stay exactly the same until we do proper versioning of the modifier data and completely remove the GPv2 support.
- Vertex weight transfer feature no longer supports name initial matching ("group" used to match "group1","group2" etc). Now it will only transfer vertex weight from source vertex groups that has the exact same name as specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/117028
The Viewport Compositors crashes when there are many nodes that are not
connected to the compositor or viewer outputs.
That's because those sockets were wrongly added to the shader operation,
even though they will not be used, which surpasses the limit for the
maximum image units per shader.
This adds support by just reusing the GGX reflection LTC
look-up table. This avoid more memory usage for another
table.
This is quite a hack and has no real physical ground.
We already have a roughness remapping function for
reusing sphere-probe for refraction and matching the
blur level. We can reuse this function and use it
for sampling the reflection LUT.
Then getting the theta LUT parameter is done by
computing the angle between the refraction direction
and the reversed normal.
This works because the table is parametrized using the
angle between the view vector and the normal. This angle
is the same as the angle between the reflection vector
and the normal. So to get the equivalent lobe in the
refraction direction we get the angle between the
refraction direction and the reversed normal.
Note: This has issues shadow-map tagging but it should
be fixed separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/118589
Unit tests were assuming that creating a catalog from a path would not
create catalogs for the parent path elements if missing. I'd argue this
should not be unit tested since it's internal behavior that isn't
visible to API users. But for now I'll keep the test working as is, also
to avoid indirect recursive calls of `create_missing_catalogs()`.
Rebuilding the tree immediately after changes could cause the tree to be
rebuilt multiple times. More importantly, it made it harder to reason
about thread safety, since we would touch the tree within a whole bunch
of API functions. Now tree building is simplified and managed in a
single place, so making the tree building thread safe can be made
trivially in a follow-up.
Note, this means the initial catalog tree building doesn't happen in a
background thread together with loading the asset library and catalogs
anymore. But we would already do all further rebuilds on the main thread
anyway, this shouldn't have any notable impact.
Line art used to not calculate edges where both ends are outside image
frame, this will lead to missing edges in some cases where the model is
scaled up pretty big. Now it ensures those edges are still preserved.
Pull Request: https://projects.blender.org/blender/blender/pulls/118448
Line art shadow projection will cut lines indefinitely when it
encounters a edge segment with 0 length. In the case of #118547, it was
caused by the combination bevel modifier and the view angle. This fix
ensures that no such edge is worked on further.
Pull Request: https://projects.blender.org/blender/blender/pulls/118613
