Loading pre-4.0.20 node groups with sockets using subtypes causes
broken socket identifiers. This is because the node tree interface now
expects sockets to use the base identifiers ("NodeSocketFloat" instead
of "NodeSocketFloatFactor" etc.).
To correct this the conversion code now replaces socket idnames that
include a subtype suffix with their base names. This fix is also applied
to files between versions 4.0.20 and 4.1.10, where the socket types
may have been converted incorrectly.
Pull Request: https://projects.blender.org/blender/blender/pulls/117133
Add `ATTR_WARN_UNUSED_RESULT` to the
`BKE_animsys_eval_context_construct` and
`BKE_animsys_eval_context_construct_at` functions. They are pure
functions, and without using their returned value they are pointless.
No functional changes.
Sharing of the normals cache between copied meshes was missing from
89e3ba4e25, which under-represented the benefits of the
change. In a simple file where geometry nodes causes a re-evaluation
without changing the normals, this increased FPS from 2.6 to 14.
After the replacement of auto smooth with a modifier, sharp edges are
always used, so the "shade smooth", "shade flat", and "smooth by angle"
operators cleared the attribute. However, often users spend significant
time manually tagging edges sharp, and the operators make it too easy to
lose that data.
To keep the old behavior by default, add an option called "Keep Sharp
Edges". Though this can make the operators "ineffective" at their goal
of changing the way the meshes look, or result in redundant data stored
on the mesh, it's a much safer default, especially as users get used to
the new workflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/117069
This is due to `BLI_findstring` returning wrong id from passed name.
Two IDs can have same name before making them unique so it can return
wrong id. To fix this, pass id argument instead of id_name to
`BLI_libblock_ensure_unique_name` and skip the use of `BLI_findstring`
Pull Request: https://projects.blender.org/blender/blender/pulls/116246
Caused by e968b4197b / 67e23b4b29
Since culprit commits, we are not running `MANTA::initGuiding` /
`fluid_alloc_guiding` if guiding is meant to be pulled from other
domains (it does work with effectors though). This is because atm. only
the `FLUID_DOMAIN_ACTIVE_GUIDE` flag sets `mUsingGuiding` to true
(activated in `update_obstacleflags`, so only for effectors).
So to fix this, we have to ensure that `MANTA::initGuiding` runs (also
if guiding is pulled from domains), but also make sure we dont run into
the crashes from T102257.
It seems that the real reason we were getting crashes in T102257 is that
67e23b4b29 made it so that resetting the cache (including a call to
`fluid_modifier_reset_ex`) in `fluid_modifier_processDomain` happens
**after** `FluidDomainSettings.active_fields` have been updated (this
happens in `update_flowsflags` & `update_obstacleflags`).
But `fluid_modifier_reset_ex` also resets
`FluidDomainSettings.active_fields`. If we then update pointers later in
`fluid_modifier_processDomain`, we never get anything in the guiding
related pointers for the new `mCurrentID` (specifically `mPhiGuideIn`
will be a nullptr). This is the real reason `initGuiding()` runs a
second time (it does once for `fluid_modifier_init` then again as a
consequence of the call to `manta_guiding`).
This patch proposes to move the resetting process from 67e23b4b29
**above** the refreshing of the `FluidDomainSettings.active_fields`,
this way these field stay intact, we do get the first run of
`initGuiding()` from `fluid_modifier_init`, manta pointers get updated
with intact fields afterwards (so we then get a valid `mPhiGuideIn`),
which then prevents the second run from `manta_guiding` to actually call
the python script again.
The fix from e968b4197b is then not needed and reverted in this patch.
This should be good for LTS I think.
Pull Request: https://projects.blender.org/blender/blender/pulls/117067
This commit tweaks some unit names:
- Remove `name_alt` for square mile "sq m" and cubic mile "cu m" as
they could easily be confused with meters.
- Correct plural forms for the ton units: rename "ton" to "tonne" for
the metric ton, and "tonnes" to "tons" for the imperial (short) ton.
Identifiers are unchanged.
- Swap `name_short` and `name_alt` for metric ton, hour, and second,
as `name_short` is used for UI display and should use the official
symbol. Keep the other form as `name_alt` for input.
- Use "t" and "tn" respectively as short names for the metric and
imperial (short) ton.
- Rename radian's short name "r" to "rad", keep it as alt name.
- Introduce alt names for km/h (kph), arcminutes (amin),
arcseconds (asec), for convenience.
References:
- https://en.wikipedia.org/wiki/Ton
- https://en.wikipedia.org/wiki/Tonne
Ref: !116762
- Move functions to C++ namespace
- Use two functions with simpler responsibilities instead
- Use C++ math functions
- Remove arguments structs left over from before C++ transition
- Return ray distance precalculation by value
In particular, while Object (un)linking was already tagged in relevant
BKE code, collection (un)linking was not in several cases.
This was (partially) done by user code, though almost never for the
whole hierarchy of parents.
Technically, the tag is done as part of
`collection_object_cache_free_parent_recursive`/`collection_object_cache_free`,
since currently clearing this cache is done everytime to collection
hierarchy or their content is modified.
It also removes `collection_tag_update_parent_recursive`, which was
already doing something similar, but was only called from code
adding/removing objects to collections, and was walking the same parent
hierarchy as `collection_object_cache_free_parent_recursive`.
This commit implements the decision made in #116601, to tag modified
data as close as possible from the code modifying it.
---------------------
This has an impact on deg tagging, which takes over twice as much cycles
with this commit compared to previous code when opening a Pets production
file with several liboverrides (`deggraph_id_tag_update_single_flag` goes
from less than 0.03% to over 0.06%).
The overhead remains extremely low though, and is totally unmeasurable in
global execution timing. Timing of the liboverride processing on opening
the production file also did not show any measurable differences.
Pull Request: https://projects.blender.org/blender/blender/pulls/116986
In the end it was a dummy mistake in own 94e6ab6d71 refactor, which
broke the 'restore on undo' case for ID pointers when the old and new
pointers remain exactly the same.
Many thanks to Campbell (@ideasman42) for investigating and identifying
the actual issue.
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
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
