Assert that the partial is part of the particle system before
creating an index. This is a hint to developers that the cast
is safe and using a pointer offset isn't going to cause problems.
Issue raised by !111193.
Co-authored-by: Loren Osborn <linux_dr>
When using a pointer offset that may be out-of-bounds the integer
must not truncate the offset.
Issue raised by !111193.
Co-authored-by: Loren Osborn <linux_dr>
"Apply as Shape Key" and "Save as Shape Key" shared the same icon, it
is good practice to not use the same icon for two consecutive items
in the same group in a menu.
Also add a separator to split Shape Key-related items from the rest.
Don't call `MEM_dupallocN` on unknown data. We don't know that this
pointer references a heap allocation, especially not an allocation made
by Blender's allocator. Even if that's the case currently, we don't want
to rely on that in the future as attribute data management gets more
flexible with implicit sharing.
Using `Array` is a simpler way to copy memory, though it does require
a bunch of boilerplate changes in the rest of the modifier.
In the charge splash screen demo file for Blender 3.4, the corrective
smooth modifier is called with a zero vertex mesh, which means it ends
up trying to free a null pointer is creates locally. Checking for null
resolves the crash. A future fix will remove the assumption that
`rest_coords` are allocated with the guarded allocator and can be
used as an argument to `MEM_dupallocN`.
#111972 made sure copied sockets have unique identifiers, but it didn't
cover the case of copying a panel and its children.
- Added an optional `uid_gen` argument to item copy functions which
generates new unique identifiers for copied items. If not specified
the items will retain the original identifiers (e.g. when copying an
entire node tree).
- Removed the `copy_items` panel function from the API. Only used
internally and requires a uid generator now.
Pull Request: https://projects.blender.org/blender/blender/pulls/112074
When adding modifiers from assets in the new modifier menu, switching
the node group the modifier uses afterwards will not be common. The goal
is to replace the builtin modifier directly. In that case it's easier to
just add a new modifier. The "Empty Modifier" item makes it easy to
choose an arbitrary node group anyway.
Combined with hiding the two sub-panels when they are unnecessary,
many node-modifiers will look just as clean as their builtin counterparts.
The option to show the data-block selector is added to the menu
in the node header so it's still accessible though.
Pull Request: https://projects.blender.org/blender/blender/pulls/111995
Introduced with #110788
Because of the logic introduced there, the first key might not be drawn,
resulting in a wrong extrapolation line.
This fixes it by always adding the first point
Pull Request: https://projects.blender.org/blender/blender/pulls/112072
Resolve an issue where drawing the status-bar's report info could
assert on startup. This was probably caused by accessing theme colors
before drawing.
The reporter traced this back to [0] however I couldn't reproduce the
problem. Remove theme access from INFO_OT_reports_display_update as the
color has not been used since [1].
[0]: 6de294a191
[1]: 694bc4d040
Remove debug asserts that don't serve a clear purpose besides testing
something that's clear from the called code, and require accessing mesh
data just for asserts.
"filepath" was misleading since this path could also point into a .blend
file. Further, the convention was to use "filepath" for such files, and
"file_path" for when only an actual file path was expected. This is
highly confusing and non-obvious. Plus a (newer?) function broke with
the convention.
Just be explicit about the type of path, even if a bit verbose. It's
good to always have the reminder that this may be more than just a file
path when passing it around.
Batch deletion of IDs could lead to deleting ObData ones while keeping
the related ShapeKeys.
Orphaned shape keys are not allowed anymore in Blender, they are checked
against in both file write and read code.
This would lead to assert (and crash) e.g. in the liboverride code.
This commit forcefully add shapekeys of deleted meshes, curves etc.,
when calling e.g. `BKE_id_multi_tagged_delete`.
Note that deleting the shapekey when deleting the obdata ID was already
implemented in single ID deletion (`BKE_id_delete` & co), in the
underlying private `id_free`. But this is skipped in `no main` case.
which is used by the batch deletion code for performance optimizations.
Code would access invalid (null) `pchan->bone` pointers, presumably due
to the (linked) armature data being heavily modified compared to the
local Object's poses? At least that's the idea of what caused this
invalid state of pose data.
Unfortunately the issue was detected in a very complex case.
Essentially, opening an older snapshot (r3034) of a Pets production anim
file with assets from current repository r3055), which have been heavily
cleaned-up.
This triggers massive amount of missing linked data from the older anim
file, and extremely heavy resyncing process of liboverrides.
In any case, calling `BKE_pose_ensure` before accessing object's pose
data should never be a bad thing. ;)
The basic idea is very simple. Whenever a supported menu is open, one can just
start typing and this opens a search that contains all the (nested) menu entries.
The main downside is that this collides with accelerator keys. Those are the
underlined characters in each menu. For now, we just enable this new searching
behavior in a few selected menus: Node Add Menu, View3D Add Menu and
Modifier Add Menu.
This new functionality can be enabled for a menu by setting
`bl_options = {'SEARCH_ON_KEY_PRESS'}` to true in the menu type.
The status bar shows `Type to search...` when a menu is opened that supports search.
Pull Request: https://projects.blender.org/blender/blender/pulls/110855
e071288ab2 changed the "make node group" operator for new interfaces,
and in the process added incorrect lines removing a link when a group
input exists already. This crashes when there are multiple sockets
in selected nodes linked to the same non-selected output.
The link should not be removed, this is just lazy-initialization of the
group sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/112027
When data-block/asset previews were not stored in the thumbnail cache
yet (or were outdated), we'd read them from .blend files. This could
lead to random crashes (but quite reliable with a small number of
previews to be read).
Wasn't clearing runtime memory which could lead to the
`PRV_TAG_DEFFERED` bit being set. This meant we would try to free
deferred preview data since eefee47a8a, which was just garbage memory.
This confused me plenty of times. If there are two local variables I
assume they contain different things. In fact these two were equal
throughout the function.
Could be useful for automated update/sanitizer tools in a production
pipeline.
Note that this propoerty is left editable for now, on purpose (external
tools may want to clear the flag).
The `Library.tag` data is supposed to be runtime only, so needs to be
cleared when reading data from blendfile.
This fixes the 'need resync' status of a library staying around forever
once set, annoying visual warning in the Outliner.
Change the existing "Is Shade Smooth" node to be named "Is Face Smooth"
and add a new "Is Edge Smooth" node. Also give the "Set Shade Smooth"
node the ability to set face or edge smoothness.
The fact that the nodes process "smooth" data reversed from the builtin
"sharp" attributes can be reversed with versioning in a separate commit.
While it's tempting to abstract the sharpness status into a single node,
face and edge smoothness are accessed separately in edit mode, and the
subtlety of interacting with data on different domains would make that
confusing. Instead, a separate "Is Shade Smooth" node group asset will
give all the sharp elements taking into account both builtin attributes.
The fact that sharpness is stored separately on two domains makes the
best design for simple operations non-obvious. For example, you should be
able to remove all sharpness or make everything flat with a single node.
The behavior depends on whether the two attributes exist and the
combination of values between the domains.
---
Pull Request: https://projects.blender.org/blender/blender/pulls/112029
This function is rather big and it's not clear what state variables are
in without a bunch of scrolling around. Plus, having the declarations
close to the function calls that set them makes it more clear that these
functions use the variables as output parameters. So this change should
help understanding the function flow.
This is a nasty gathering of several issues, main one being that 'local
collections' of 3DViews are still updated immediately instead of the
deferred update used for all other viewlayer cases.
The change in a16bcb6576 led to internal references to the Scene's
master collection to become invalid, which is the expected behavior.
But this turns the Scene's view_layers into invalid state too.
Ideally, there should never be resync of viewlayers of a scene being
deleted anyways.
For now, take the (hopefully!) safe approach of explicitely forbidding
any viewlayer update during ID deletion process, and deferring it at the
end of the process.
Note that this change may also give some marginal gerformance
improvements in some rare edge cases (like deleting a very heavy scene
with many collections and 'local collection' 3DViews ?).
