This adds a Python API for layout panels that have been introduced in #113584.
Two new methods on `UILayout` are added:
* `.panel(idname, text="...", default_closed=False) -> Optional[UILayout]`
* `.panel_prop(owner, prop_name, text="...") -> Optional[UILayout]`
Both create a panel and return `None` if the panel is collapsed. The difference lies
in how the open-close-state is stored. The first method internally manages the
open-close-state based on the provided identifier. The second one allows for
providing a boolean property that stores whether the panel is open. This is useful
when creating a dynamic of panels and when it is difficult to create a unique idname.
For the `.panel(...)` method, a new internal map on `Panel` is created which keeps
track of all the panel states based on the idname. Currently, there is no mechanism
for freeing any elements once they have been added to the map. This is unlikely to
cause a problem anytime soon, but we might need some kind of garbage collection
in the future.
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Before")
if panel := layout.panel("my_panel_id", text="Hello World", default_closed=False):
panel.label(text="Success")
if panel := layout.panel_prop(scene, "show_demo_panel", text="My Panel"):
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="After")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/116949
Oversight in [0] which assumed the cage meshes vertices were aligned
with the edit-mesh vertices which isn't always the case.
Check the cage mesh only has deformations applied before using it.
[0]: 29a338811c
There was one functional issue with the previous API which was its
use in `VolumeGrid<T>::grid_for_write(tree_token)`. The issue was
that the tree token had to be received before the grid is accessed.
However, this `grid_for_write` method might create a copy of the
`VolumeGridData` internally and if it does, the passed in `tree_token`
corresponds to the wrong tree.
The solution is to output the token as part of the method. This has two
additional benefits:
* The API is more safe, because one can't pass an r-value into the methods
anymore. This generally shouldn't be done, because the token should
live at least as long as the OpenVDB tree is used and shouldn't be freed
immediatly.
* The API is a bit simpler, because it's not necessary to call the
`VolumeGrid.tree_access_token()` method anymore.
Crash is due to accessing higher index of 0 sized array. Fix this by
changing the size of vector.
Missing update seems to be due to wrong PBVH node flags and typo.
Pull Request: https://projects.blender.org/blender/blender/pulls/116935
This cleanup changes the `layer` parameter in `get_drawing_at` and `get_editable_drawing_at` to a reference.
This makes it clear that the layer is required for this function.
When loading an unknown node type from a newer Blender version, the node
storage data cannot be properly loaded. Re-saving the file will then
crash if saving with the same node type idname, since new Blender
versions cannot find the expected storage data.
Loading in older versions should replace unknown node types with a dummy
"Undefined" node that will get loaded as NodeTypeUndefined in newer
versions as well. Custom node types are exempted from this since they
store all data as generic ID properties and can always be fully
serialized.
This is a revised version of the initial attempt in #114803.
Doing the node type fix in the after-linking stage ensures that
versioning code can change outdated node types which might otherwise get
removed by this type check.
Pull Request: https://projects.blender.org/blender/blender/pulls/116908
Now, such links are treated similar to muted links. Links coming from dangling
reroutes are not added to the set or border links anymore. They should be
ignored by evaluation systems.
Even though the brush rotation is computed as a 2D angle (based on the mouse
movement), it currently gets applied by rotating the projected X direction
around the the normal in 3D.
This patch ensures that rotation gets applied first, and only then does the
motion direction get projected into the tangent plane. A potential issue with
the current approach is that the random perturbations will also be applied in
2D, but this seems to be fine from discussions with @JulienKaspar and @Sergey.
Also, there was an error where the location should probably be converted *to*
world coordinates.
All these changes seem to fix the issue described in #116418.
I also noticed some minor "inconsistencies" with how the rotation is applied:
For curve strokes, the direction of the curve corresponded to the upward
direction of the brush. For view plane, area plane mapping and anchored strokes,
the mouse motion indicated the downward direction of the brush.
For compatibility, I tried my best to enforce the latter conventions throughout,
but I'm not so confident about oversights.
Pull Request: https://projects.blender.org/blender/blender/pulls/116539
Update the command line help message to reflect the actual image output
formats available. Remove mention of IRIZ and DDS, rename MPEG to
FFMPEG. HDR and TIFF are always valid now.
Pull Request: https://projects.blender.org/blender/blender/pulls/115987
Instead of storing a boolean "update tag" for every vertex, just
recalculate the normals of all the faces and vertices in affected PBVH
nodes. This avoids the overhead of tracking position updates at the
vertex level, and simplifies the normal calculation, since we can
just calculate values for all the normals in a node.
The main way we gain performance is avoiding building a `VectorSet`
for all vertices and faces that need updates in the entire mesh. That
process had to be single threaded, and was a large bottleneck when many
vertices were affected at a time.
That `VectorSet` was necessary for thread safety deduplication of work
though, because neighboring nodes can't calculate the normals of the
same faces or vertices at the same time. (Normals need to be calculated
for all faces connected to moved vertices and all vertices connected to
those faces). In this PR, we only build a set of the *boundary* faces
and vertices. We calculate those in a separate step, which duplicates
work from the non-boundary calculations, but at least it's threadsafe.
I measured normal recalculation timing when sculpting on a 16 million
vertex mesh. The removal of the `vert_bitmap` array also saves 16 MB
of memory.
| Nodes | Affected Vertices | Before (ms) | After (ms) |
| ----- | ------------ | ----------- | ---------- |
| 4 | 15625 | 0.208 | 0.304 |
| 35 | 136281 | 2.98 | 0.988 |
| 117 | 457156 | 15.0 | 3.21 |
| 2455 | 9583782 | 566 | 84.0 |
Pull Request: https://projects.blender.org/blender/blender/pulls/116209
As discussed in #105407, it can be useful to support returning
a fallback value specified by the user instead of failing the driver
if a driver variable cannot resolve its RNA path. This especially
applies to context variables referencing custom properties, since
when the object with the driver is linked into another scene, the
custom property can easily not exist there.
This patch adds an optional fallback value setting to properties
based on RNA path (including ordinary Single Property variables
due to shared code and similarity). When enabled, RNA path lookup
failures (including invalid array index) cause the fallback value
to be used instead of marking the driver invalid.
A flag is added to track when this happens for UI use. It is
also exposed to python for lint type scripts.
When the fallback value is used, the input field containing
the property RNA path that failed to resolve is highlighted in red
(identically to the case without a fallback), and the driver
can be included in the With Errors filter of the Drivers editor.
However, the channel name is not underlined in red, because
the driver as a whole evaluates successfully.
Pull Request: https://projects.blender.org/blender/blender/pulls/110135
In order to prepare for introduction of fallbacks, refactor the
function to return its status as an enumeration value. Also, move
the index range check inside the function from python-specific code.
The same is done for other geometry types. This allows us to use C++ types in
the run-time data more easily and avoids dumping runtime data into .blend files.
Pull Request: https://projects.blender.org/blender/blender/pulls/116840
Added support to Drag and Drop to file handlers, part of #111242.
If file handlers are registered with an import operator they can now be
invoked with drag and drop path data.
Import operators must either declare a `filepath` StringProperty or both
a `directory` StringProperty and a `files` CollectionProperty depending
on if they support single or multiple files respectively.
Multiple FileHandlers could be valid for handling a dropped path. When
this happens a menu is shown so the user can choose which exact handler
to use for the file.
Pull Request: https://projects.blender.org/blender/blender/pulls/116047
- Move code to C++ namespace for blenkernel
- Remove unnecessary prefixes based on namespace change
- Remove use of `RawVector` for function-scoped static variable
- Use `StringRef` instead of char pointer
- Use safer `STRNCPY` instead of `strcpy` in tests
- Give span instead of vector to users of API
Pull Request: https://projects.blender.org/blender/blender/pulls/116808
Bone collection visibility now respects their hierarchy.
A bone collection is only visible when it is marked as visible and all
its ancestors (so parents, greatparents, etc.) are visible. Root bone
collections have no ancestors by definition, and only consider their own
visibility.
The effective ancestors' visibility is stored on each bone collection,
in its `BONE_COLLECTION_ANCESTORS_VISIBLE` flag. This makes it possible
to determine the effective visibility from just the flags of the bone
collection itself.
The `BONE_COLLECTION_ANCESTORS_VISIBLE` flag is now stored, with the
other flags, in `BoneCollection::flags`. This means that it's stored in
DNA, even though it's derived data and should actually be stored in a
runtime struct. However, `BoneCollection` doesn't have any runtime
struct yet, and I don't feel that the introduction of this flag is a
good enough reason to introduce that just yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/116784
Rename `ANIM_bonecoll_is_visible(armature, bone)` to
`ANIM_bone_in_visible_collection(armature, bone)`, as that reflects the
actual functionality.
No functional changes.
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Simplifies the code in this area, makes it work better with other C++
code. The max length argument isn't used anymore. But at that point we
wouldn't necessarily have a unique name anyway, which opens up for other
failures.
