This fixes#121695. `float4x4` matrices are generally expected to be 16 byte aligned.
Currently, there is no mechanism (afaik) that allows allocating these overaligned types
when loading files from disk. This patch adds an array with alignment information for
each type in `SDNA`. Currently, the alignment is just `__STDCPP_DEFAULT_NEW_ALIGNMENT__`
for all types and is manually set for the `mat4x4f` DNA type. The .blend file format is
not changed at all. The alignment information is purely runtime data.
In the future it would probably be good to generalize this a bit more instead of
hardcoding the alignment for `mat4x4f`, but would make it unnecessarily complex for
now because this is intended for the release branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/123271
This adds a "Legacy Behavior" option to the Limit Rotation constraint that makes
it behave how Limit Rotation constraints did prior to
ed2408400d. Newly created constraints have this
option disabled, but versioning code enables the option on constraints from
older files to ensure that the behavior of e.g. existing rigs is not altered.
This is one part of a two-part fix for #123105. The other part is in PR
extensions/rigify#4.
Pull Request: https://projects.blender.org/blender/blender/pulls/123361
The issue was that we used `from_orthonormal_axes` which obviously expects that
the axes are orthonormal. However, with custom curve normals this is not always the
case. Math wise, an additional normalization is necessary because the cross product
is not automatically normalized anymore.
This change also means that `point_matrix` may have a shearing component. But I
think that's fine here because the matrix is only immediately applied on vertex positions.
This shouldn't affect any case where the normal and tangent are orthonormal.
Pull Request: https://projects.blender.org/blender/blender/pulls/123238
The issue was a floating point precision issue
between the number of the cycle and the time
within the cycle (`cycle` and `cyct`).
Due to that the `cycle` would advance to the
next whole number while the `cycle time`
is still slightly under that.
This is fixed by calculating the `cycle` with double precision.
This has a measurable performance
impact (for `fcm_cycles_time`)
| Before | After |
| - | - |
| 39ns | 44ns |
For fcurves with a cycle modifier,
this code is run at every evaluate call.
The only time when that would be an issue is
in the graph editor, where there is an evaluate
call for roughly every pixel for curves that have a modifier.
However even in that scenario the performance
is the same within run to run variance (for `graph_draw_curves`)
| Before | After |
| - | - |
| 91565ns | 91430ns |
Pull Request: https://projects.blender.org/blender/blender/pulls/123222
This implements (most of) the proposal in #122743:
* Add a new `IDP_FLAG_STATIC_TYPE` IDProperty flag.
* Update `BPy_IDProperty_Map_ValidateAndCreate` and related to never
change an existing property type if statically typed.
The biggest change happens in bpy assignement code, since instead of
replacing the old exisitng property by a newly created one, and copying
over a few settings, now the old property is kept if possible, and a new
one is only created if needed.
And in case the existing property is statically typed, if it cannot be
re-used to store the given value, and error is reported and it remains
unchanged.
`IDP_ARRAY` is also supported for basic numeric types, so 'vector'
properties and such work as expected. Lentgh is considered as part of
the static type (i.e. one can only assign a 3 components py sequence to
a 3-len array property, etc.).
Such in-place update is not yet implemented for `IDP_IDPARRAY` and
`IDP_GROUP` types. While important (especially the group one), they are
not that critical for the current issues related to changing IDProperty
types.
Masks are not updated when edited when using the GPU compositor. That's
because the GPU compositor caches static resources and invalidates them
according to the recalculate flags that the depsgraph flushes to IDs.
The issue is that the flags are not flushed to the evaluated IDs of the
compositor depsgraph, but rather to some other evaluated versions of the
IDs.
To fix this, we make the compositor depsgraph persistent and store it in
the scene runtime. This allows us to reliably track changes to resources
used by the compositor and also reduces the overhead of depsgraph
creation in the compositor job.
Patch originally provided by Sergey.
Fixes#121188.
Pull Request: https://projects.blender.org/blender/blender/pulls/123085
Fixes#116567
The issue was with a flag that skips a particular post-evaluation step
specially for the Child Of constraint. The flag wasn't getting properly
unset when the constraint target was removed, and therefore that
post-evaluation step was getting erroneously skipped in some cases.
This commit fixes the issue by always setting the flag appropriately in
the Child Of evaluation function itself. This is admittedly rather
hacky, but no more hacky than the existence of the flag in the first
place.
Pull Request: https://projects.blender.org/blender/blender/pulls/122881
This changes fixes a wrong mesh as a result of apply base mesh from the Multires modifier
In the previous code some corner vertices where incorrectly assigned to null and skipped form processing as a safety guard
that was only relevant when the mesh had hidden faces in edit mode. The hidden corner vertices bug is handled now when checking
> if (corner_x_index < 0 || corner_y_index < 0) {
> continue;
> }
Since the patch that caused this error was a fix to a previous infinite loop bug,
I also tested and made sure this updated patch still fixes the original issue it was trying to fix.
Note: This PR replaces #122845 due to a large amount of git rebase issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/122859
Mainly correct/update some comments (e.g. missing reference to Boolean
type), and add some notes essentially about issues with current IDProp
String code (see also #86960 ).
No functional change.
This fixes a bug that happens when two drawings in the same grease pencil
data-block reference the same array. In this case, the same attribute array
pointer is written to .blend files for both drawings. However, when loading the
.blend file, it was not detected that the data is shared. Instead each drawing
would think that it was the single owner of the array even though it was shared.
The same problem can technically occur for all kinds of shared data, and not
just for grease pencil. However, only grease pencil shows this issue currently,
because it can easily happen that the same attribute is shared between different
`CustomData` within the same data-block. This very rarely happens with meshes or
curves, because different `CustomData` usually have different sizes and don't
share the same arrays.
A previous fix (cc891aa699) solved pretty much the same issues for the case
when two layers in the same `CustomData` share data. This original fix is now
generalized and is integrated with `BLO_read_shared` which makes it less error
prone. For each data-block, the `BlendDataReader` now remembers which shared
data it has loaded before so that it is not loaded again.
In the future this could be extended to support data that is shared between
data-blocks, but that's not as straight forward as one would hope currently. For
various reasons, different data-blocks could store independent data at the same
pointer. I specifically noticed that with a regression test file:
`blender/tests/data/modeling/geometry_nodes/attributes/attribute_statistics.blend`.
To support it, one solution could be to tag `BHead` in .blend files to indicate
that a specific pointer is shared and unique within the entire file. But that's
for another day.
Pull Request: https://projects.blender.org/blender/blender/pulls/122780
Support for "System" extensions as an alternative to the current
"User" extensions repository.
The purpose of this change is to support bundling extensions for
offline work or in environments where users setting up thier own
extensions isn't desirable, see #122512.
Details:
The default "System" repository on Linux will for example use:
- `/usr/share/blender/4.2/extensions/{system}` For system installs.
- `./4.2/extensions/{system}` For portable installs.
- Blender's default startup now has a "System" repository
which users or administrators may populate.
- Repositories can select between User/System paths,
setting a custom path overrides overrides this setting.
- Add "BLENDER_SYSTEM_EXTENSIONS" (matching "BLENDER_LOCAL_EXTENSIONS").
Ref !122832
Update PBVH GPU argument initialization to prefer using the PBVH mesh
attributes instead of the evaluated mesh attributes for color.
The values can be out of sync due to differences with the evaluated
and original mesh data.
Pull Request: https://projects.blender.org/blender/blender/pulls/122850
Originally this would replace scripts that come bundled with Blender,
but it's unclear how this is useful.
Searching for this online mainly leads to people asking how they can
use it to add scripts. For example in a studio environment you might
want to deploy add-ons and startup scripts for all users.
Even if you wanted to use it for replacement though, it wasn't really
doing that and inconsistent for different types of scripts:
* startup: ignored
* modules: replaces bundled scripts
* presets: adds to bundled scripts
* addons (in 4.1): ignored
* addons_core (in 4.2): ignored
* startup/bl_app_templates_system: replaces bundled scripts
This change makes it add scripts from this path for all. This is a
breaking change, though arguably this feature was just broken to
begin with and not used much in practice because of that.
The alternative would be add a new set of environment variables to
avoid breaking existing behavior. But that also means keeping around the
broken behavior or fixing it in another way.
Supporting multiple paths may be used too, but for now just support
a single one as doing this for all BLENDER_SYSTEM variables is
non-trivial. The main use case for that would be add-ons anyway, and
those will mainly be handled through upcoming
BLENDER_SYSTEM_EXTENSIONS instead.
Ref #122512
Pull Request: https://projects.blender.org/blender/blender/pulls/122689
Seems to be dependent on specific compiler/cmake version.
Is a typical mixture of missing dependencies between libraries,
object files which do not get referenced from other files in the
target, and whole-archive linking of the blender_test target.
Pull Request: https://projects.blender.org/blender/blender/pulls/122801
There is a mechanism to store config files in the same folder as the
Blender executable. The typical use case is putting Blender on a USB
drive and taking the config with you.
However the problem is that this is using the 4.2/ folder, which is fine
for config/ but with e.g. addons, studiolights and now extensions this
is mixing user and system files. This requires exceptions, doesn't
work well in some cases and is just generally not great design.
Instead use a folder named portable/ that is separate.
Pull Request: https://projects.blender.org/blender/blender/pulls/122778
The Film-like curve mapping option in the RGB Curves node in the
compositor produces bad results when editing its RGB curves. That's
because Film-like curve mapping only works with the combined curve by
definition, since it is a hue preserving mapping. Furthermore, the
Film-like option ignored the white balancing step altogether.
To fix this, we hide the current curve option for the File-like option
and only allow editing the combined curve, handing the same case for
versioning and RNA updates. Further, we port the implementation from the
realtime compositor which is both correct and takes white balancing into
account.
Pull Request: https://projects.blender.org/blender/blender/pulls/122762
PBVH_UpdateRedraw was always combined with PBVH_UpdateBB.
The use for the "redraw update" isn't clear anyway, since there are
more specific tags for everything that would require a redraw.
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
By capturing multiple attributes with one node, the user can make sure that those
are evaluated together in the same context. This can be quite a bit more efficient
compared to capturing multiple fields separately (also because we don't optimize
grouping multiple capture nodes together yet).
The change is fully backward compatible. Forward compatibility has been added
for some cases. Especially, files created in older versions that are saved with this
newer version will still work in the older version.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121665
Move the bounding box synchronization to the geometry evaluation component.
This way it is ensured that it is only done when the geometry is actually
evaluated, solving the problem of accessing stale data when object level
flags are modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/122509
The setting adds the "Custom Shape Wire Width"
option to the "Viewport Display/Custom Shape" section of a pose bone.
As the setting says, this controls how thick the wire is drawn in the viewport.
This is done by adding a geometry shader that makes two triangles out of a line.
The Anti-Aliasing is controlled by the setting
Viewport->Quality->Smooth Wires->Overlay in the user preferences.
## Artifacts
When increasing the line width, the lines start to separate at their vertices.
This comes from extruding each edge along the normal of its direction.
This could be solved by adding round caps in a later PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/120176
During the conversion of GPv3 to GPv2, we computed the
time difference between the points. So we we're keeping track
of the time a point was created relative to the previous point.
There doesn't seem to be a good reason to do this.
It can also go very wrong in case the times of two points are
very close to one another (which can result in catastrophic
cancellation).
With this change, the time delta values are now the time
a point was created, relative to the first point.
Pull Request: https://projects.blender.org/blender/blender/pulls/122367
Asserts triggered e.g. by opening Gold production files (like
`pro/shots/220_storm/220_0020/220_0020-anim.blend`). Their root cause
are zero tangent vectors.
The asserts initially came from unormalized normals, but the root issue
is actually using zero vector as axis in calls to
`math::rotate_direction_around_axis`.
While rotating a zero direction vector is possible (though useless),
rotating around a zero axis vector makes no sense?
So this commit adds an assert that the given axis is non-zero in
`rotate_direction_around_axis`. And 'fixes' the found cases triggering
such assert by skipping rotation when the axis (tangent) is null.
Another related issue fixed by this commit is the iterative process in
calls to `calculate_next_normal`, which can accumulate small floating
point errors over time, leading to generating not normalized-enough
normals at some point.
Pull Request: https://projects.blender.org/blender/blender/pulls/122441
This PR adds a new operator: `PAINT_OT_visibility_edit` to support
iteratively expanding or shrinking the visibility of a mesh, similar to
the *Grow / Shrink Mask* actions and the *Grow / Shrink Face Set*
options. This operator is exposed via two new entries in the *Sculpt*
toolbar entry as *Show More* and *Show Less* and have also been
assigned to Page Up and Page Down in the default Blender keybinds for
Sculpt Mode.
### Technical Details
Each of the PBVH types is solved slightly differently, though the
general principle for each is as follows:
1. Make a copy of the current mesh visibility state
2. Iterate over elements (faces & corners if available, otherwise
vertices) to look at adjacency information
3. Apply appropriate visibility change to vertices
4. Sync face visibility
### Limitations
* Currently, like all other operators in the `paint_hide.cc` file. This
new operator is limited to Sculpt mode only.
Based off of [this](https://blender.community/c/rightclickselect/pz4y/)
RCS request.
Pull Request: https://projects.blender.org/blender/blender/pulls/120282
Extract
- Add to Quick Favorites tooltip.
- "Mask", the name of a newly created mask (DATA_).
- "New" in the context of the new mask ID button.
- A few strings using BLI_STR_UTF8_ defines were not extracted.
Take the special characters out of the translation macros.
- "External" menu items from the filebrowser's Files context
menu (right-click on a file). These items were already extracted,
but not translated.
Improve
- Separate formatted error message "%s is not compatible with
["the specified", "any"] 'refresh' options" into two messages.
Disambiguate
- Use Action context for new F-modifiers' names. This is already used
for the "type" operator prop.
- Translate ImportHelper's default confirmation text using the
Operator context, as it uses the operator name which is extracted
with this context.
- "Scale" can be a noun, the scale of something, or a verb, to scale
something. The latter mostly uses the Operator context, so apply
this context to verbs, and the default contexts to nouns.
- "Scale Influence" can mean "Influence on Scale" (tracking
stabilization) and "to Scale the Influence" (dynamic paint canvas).
- "Object Line Art" as type of Line Art to add, as opposed to the
active object's Line Art settings.
- Float to Integer node: use NodeTree context for the node label, as
this is already extracted and used for the enum.
Do not translate
- Sequencer labels containing only a string formatting field.
Some issues reported by Gabriel Gazzán and Ye Gui.
Pull Request: https://projects.blender.org/blender/blender/pulls/122283
Sometimes it is necessary to pass additional data through generic UI entities,
to specific implementations. For example to pass additional options to panel
polling & drawing when instantiating a panel through its panel type. Or storing
additional data in a button, without hardcoding it in the button struct/class.
Passing data via context is a simple solution to this, however so far this only
works using hardcoded context queries or RNA pointers. For passing arbitrary
strings we've used workarounds like creating an RNA type to wrap it already.
For example `RNA_AssetCatalogPath`, which is used to dynamically populate menu
items based on an asset catalog path, via a generic menu type.
type instantiation. This makes it possible to invoke specific asset shelves as
popover panels.
Idea is simply to let `bContextStore` entries hold copies of the string (as
`std::string`), avoiding lifetime issues. Context APIs are extended to support
setting/querying strings via a context member name.
Pull Request: https://projects.blender.org/blender/blender/pulls/122113
