The issue was that the depsgraph was not rebuilt, thus
the driver node still stuck around. This then crashed when the
depsgraph evaluated.
The reason why this wasn't caught in the unit tests, was because the
depsgraph was not updated between creating and removing the data.
Pull Request: https://projects.blender.org/blender/blender/pulls/141272
#138435 was an attempt to fix the issue in #138168 where the Smooth
Operator modifies locked vertex groups. Unfortunately, the fix actually
changed some already-correct code to be incorrect to compensate for the
buggy code in the Smooth Operator.
This reverts that fix and applies a correct fix, which is to exclude
locked vertex groups in the Smooth Operator's code itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/141093
The `StringRef` in `MemoryBlobReader` was referencing data
that was freed under some circumstances. While the actual packed
data is shared between the original object and copy-on-eval object,
the name of the blobs are not.
This check was meant to catch unknown failure cases but instead it
meant any attribute with an empty array (e.g. from a mesh with no
faces) would not be loaded. Instead the failure case should only be
when there is no data when the array is not meant to be empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/141096
When armature is selected for custom shape of a bone, we run into
stack overflow due to recursive calls. To prevent this situation,
exclude armature object type from the custom shape list.
This also clears the `pchan->custom` pointer after loading/linking a
blend file. Otherwise a linked Armature object can still be assigned
indirectly, by renaming objects in the library file.
Fixes: #140747Fixes: #140959
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/140851
Caused by change in `AVCodecID` enum. Our `IMB_Ffmpeg_Codec_ID` enum,
which was stored in .blend file did match `AVCodecID`. But after change
in external library headers it fails to initialize correct codec.
Function `MOV_av_codec_id_get()` was added to map these 2 enums and
the values are no longer hard coded.
Functions, that accepted `int codec_id` argument were modified to accept
`IMB_Ffmpeg_Codec_ID` or `AVCodecID` types.
Because `codec_id` was still stored as integer in DNA, get/set struct functions
were added. This way, compiler always knows what type is used and emit
error/warning when incompatible types are used.
Unfortunately, there is no way to ensure, that DNA `codec_id` field is not
accessed directly in future code other than comment.
Pull Request: https://projects.blender.org/blender/blender/pulls/140745
The metaball selection radius was inside the cube and could only
be selected with wire-frame shading.
Resolve by expanding the radius by the dimensions of the cube.
After a recent commit, multiple drawings were always written using the
same address because we used the same stack memory in a loop. This
causes the blend file reading to not be able to distinguish between the
structs, meaning the file is corrupt. However, we already had the same
problem in some cases because of the inline buffer in `BlendWriteData`.
To resolve this, make all "temporary" data for writing live as long as
the writing is going on for the ID. This is somewhat inefficient since
it makes memory reuse impossible for this temporary data. In the future
we should use a technique like #127706 to address this.
For testing, I saved and loaded multiple production files with Grease
Pencil objects, with and without the "write with attribute storage"
option enabled. The fix still goes to 4.5 though, because the first
mentioned issue is present there, and the `CustomDataLayer` vector
address reuse is potentially a problem too.
Pull Request: https://projects.blender.org/blender/blender/pulls/140667
GreasePencil ID type did not list `ID_OB` as its potential ID dependency
type, leading to lack of remapping of its layers' parents objects
pointers (e.g. on Object deletion), leading to crash from accessing
freed data.
`blend_write_prepare` expects to work on a shallow copy of the
`CurvesGeometry` struct. This is necessary because it changes
the struct to contain only the layers being written. This is
particularly important with writing with the new format enabled,
where attributes are written as part of `AttributeStorage`.
Writing with a shallow copy of the struct also gives us the
flexibility to zero the runtime pointer in the written file which
is generally a good practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/140560
Create a good default name for saving individual frames of a movie file loaded
as an image datablock, instead of the movie file name.
Changes ImBuf to store the frame separate from the filepath, to implement this.
Seems more clear for ImBuf.filepath to be an actual filepath anyway.
Thanks to Jesse and Aras for investigating this bug.
Pull Request: https://projects.blender.org/blender/blender/pulls/140471
Previously `blend_name` was using the same path to get its file name
as `//` used. However, the choice of path for `//` seems to be
bespokely chosen at each call site. There may be a logic to it, but
if so it's not immediately clear what it is.
This PR changes `blend_name` to instead always use the currently open
("global") file path, making it well-defined and predictable for
users.
This also prepares better for PR #139438 for 5.0, which adds
`blend_name_lib`, which always uses the blend file that the ID owning
the path is linked from. Over-all this should be much more predictable
and controllable for users.
Pull Request: https://projects.blender.org/blender/blender/pulls/140474
Auto normalization used to not work on assign/remove vertex group
operator, this was due to `BKE_object_defgroup_validmap_get` and
`vgroup_parray_alloc` did not handle grease pencil type objects. Now
added grease pencil cases in them and auto normalization works as
expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/139912
This patch removes node init functions that currently exist only for
forward compatibility and moves the logic to the forward compatibility
section of node writing. This is to avoid allocating unused data
throughout the 5.x series.
Pull Request: https://projects.blender.org/blender/blender/pulls/140273
This assert added by 321ec72c74 notes that changing the mesh
wrapper type from subdivision to normal mesh data just discards the
potentially-subdivided geometry and doesn't make sense, and possibly
breaks other assumptions.
This wrapper type change was done years ago by 0f89bcdbeb to
fix issues with shared object data during evaluation. It noted that
the mesh drawing data extraction didn't handle BMesh wrappers correctly
when the object isn't in edit mode, but that doesn't seem to be the
case after two trivial changes. The other bugs mentioned by that commit
are still solved after this change.
Pull Request: https://projects.blender.org/blender/blender/pulls/140290
The transition to `AttributeStorage` requires the active and default
UV map status to be stored separately, since currently they're
stored as flags on `CustomDataLayer`. This commit adds forward
compatible reading for when the status is written as attribute names
on `Mesh` instead, which is what we already do for color attributes.
Pull Request: https://projects.blender.org/blender/blender/pulls/140134
Previously, the subdivision level was clamped to 11. While such high subdivision
levels are rare, there are still use-cases for going above those if hardware
resources allow for it.
This patch sets the hard upper limit to 15. When going above that, even
subdividing a single triangle would result in data that's too large to store in
`Mesh` because it has too many face corners for an `int`. Furthermore, instead
of clamping the subdiv level, there is an error when going above that. This
might help when accidentally connecting a value >= 16 to the subdiv level input.
Pull Request: https://projects.blender.org/blender/blender/pulls/140057
In 884ef238c0 line art added a safe guard in depsgraph iterator to
properly handle dupli-objects, but it should check original objects id
for inclusion instead of evaluated objects. Now dupli-objects will show
up correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/140095
This commit effectively reverts the changes introduced in
23951e1b12 that changed how the brush
strength curve calculation works. Since that commit, a number of high
severity regressions have been reported, and the decision to remove
filtering from this method now seems dubious and likely to cause further
problems.
Other interim fixes that were made have not been reverted, as they are
generally correct to do, even if they cause an extra loop over all of
a node's factors & distances. In general, all existing unnecessary calls
to `filter_distances_with_radius` are planned to be removed in 5.0.
Finally, to address the original issue that the mentioned commit was
intended to fix, we now check distance for the constant falloff and
zero out the factor if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/140181
Fixed by not doing async loading and always stage correct
texture reference.
Unfortunately the code is getting a bit messy since the
texture loading is not done at the GPUMaterial level.
So we need one async and one synchronous path inside
`PassBase<T>::material_set`.
`ImageGPUTextures` now contains references to the location
of the future `GPUTexture *`.
Also fix#140001
Pull Request: https://projects.blender.org/blender/blender/pulls/140203
Code selecting objects in collections that have been instanced was only
handling objects directly owned by the collection, not the objects in
the hierarchy of children collections.
The objects from the whole hierarchy need to be hanlded here, since
children collections will not be processed (as they are already
instanced by their parent one).
Pull Request: https://projects.blender.org/blender/blender/pulls/140068
Depending on things like order or processing etc., appending
liboverrides data could generate error message in the console regarding
invalid override hierarchy data.
While this could probably be solved, it feels fairly brittle and risky
to directly make linked liboverride hierarchies locale anyway, so just
alsways make local copies of these on append.
Currently, there is the general rule that outputs must be above inputs in any
given panel. Since internally a panel toggle input is part of the panel that it
toggles and has to be the first item in a panel, it was not possible to have a
panel toggle for a panel with outputs.
This patch relaxes the rule for ordering of inputs and outputs for the special
case of panel toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/140054
This allows to reduce the waiting time caused by
shader compilation on some GPU-driver combo.
A new settings in the User Preferences make it
possible to override the default amount of worker
threads and optionally use subprocesses.
We still use only one worker thread in cases where
there is no benefit with adding more workers
(like AMD pro driver and Intel windows).
It doesn't scale as much as subprocesses for material
shader compilation but that is for other reasons
explained in #139818.
Add some heuristic to avoid too much memory usage
and / or too many stalls.
Also add some heuristic to the default number of subprocess for
the platform that shows scalling.
Historically, multithreaded compilation was prevented by the
need of context per thread inside `DRWShader` module.
Also there was no good scaling at that time. But
nowadays numbers shows different results with
good scaling with reasonable amount of threads on many
platforms.
Even if we are going for vulkan in the next release
most of the legacy hardware will still use OpenGL for
a few other releases. So it is relevant to make this
easy improvement.
See pull request for measurements.
Pull Request: https://projects.blender.org/blender/blender/pulls/139821
Also unifies the min/default/max width of all group nodes. The minimum width
has been increased from 40 to 60 for Geometry Nodes because there was is
an assert when the node was that thin already. The other group nodes already
used 60 as min width.
From what I know, we don't really have a good way to detect whether a material
index is non-sensical in the right places. That's because the same material
index on a mesh may not make sense on one object but can still make sense on
another. This is the issue we fixed in the first place when the regression was
introduced.
What we can do though is to check which exact material indices a mesh is
actually using (not just the maximum). This allows us to skip a lot of work for
unused material indices. This doesn't help when a mesh has thousands of unique
non-sensical material indices, but it should be an improvement in the majority
of cases.
This patch adds a cache of used material indices to `Mesh`. The drawing code
requests that cache if the maximum material index is above some threshold (16
currently). We don't want to compute it all the time, because it requires
iterating over the mesh (at least once, then it is cached). So it's only worth
the extra cost of the there is at least one large material index. The threshold
also ensure that the large majority of scenes is not affected by this patch
performance wise.
Pull Request: https://projects.blender.org/blender/blender/pulls/139781
When constant falloff is used, `BKE_brush_calc_curve_factors` doesn't do
any extra filtering of the given distances. The Plane brush previously
didn't filter the distances, leading to incorrect deformations when the
constant falloff was used.
To fix this, this commit makes a number of changes:
* `BKE_brush_calc_curve_factors` no longer sets the factor for an
element to 0 if it is outside of the provided distance. This is
replaced with an assert.
* The Plane brush and Cloth brush have an explicit
`filter_distances_with_radius` added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139851
This commit enables Blender 4.5 to use (to some extent) blendfiles from
Blender 5.0 and later using 'long' ID names (i.e. ID names over 63 bytes).
On a more general perspective, it also introduces safer handling of
potentially corrupted ID names in a blendfile.
This is achieved by carefully checking for non-null terminated ID names
early on in readfile process, and then:
* Truncating and ensuring uniqueness of ID names.
* Doing similar process for action slot and slot users identifiers.
* In linking (and appending) context, such IDs are totally ignored. They are
not listed, and are considered as missing if some other (valid) linked ID
attempt to indirectly link them).
* Informing users through usual reporting ways.
Technically, this mainly changes two areas of the readfile code related to IDs
themselves:
* The utils `blo_bhead_id_name` that returns the ID name of an ID BHead,
without actually reading that ID, now check for a valid null-terminated
string of `MAX_ID_NAME` max size, and returns a `nullptr` on error.
_This essentially prevents listing and linking such IDs, in any way._
* The actual ID reading code (`read_id_struct`) does the same check, and
truncate the ID name to its maximum allowed length.
* Both of above checks also set a new FileData flag
(`FD_FLAGS_HAS_LONG_ID_NAME`), which is used to ensure that ID names (and
related actions slots identifiers) remain unique, and report to info to the
user.
Implements #137608.
Branched out from !137196.
Co-authored-by: michal.krupa <michal.krupa@cdprojektred.com>
Co-authored-by: Campbell Barton <ideasman42@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/139336
This mainly adds DNA level IDProp storage for system properties, their
handling in data management code, and the forward-versioning code
copying back content from system properties into 'all-in-one' single
IDProperties storage, for data types that will support both in Blender
5.0.
There is no user-facing changes expected here.
Part of #123232.
Pull Request: https://projects.blender.org/blender/blender/pulls/139257
In 5.0, we plan to change the brush size from representing radius to
diameter. This means that for 5.0 files loaded in 4.5, we need to
scale the stored value when reading the relevant brush fields.
Related to #134204
Pull Request: https://projects.blender.org/blender/blender/pulls/139561
Current strategy to deal with operators not supporting custom NURBS
knots is to fall back to calculated knots for curves of the custom mode
but with no `CurvesGeometry::custom_knots` allocated. Such curves are
the result of operators that copy only `Point` and `Curve` domains. This
way the problem is only postponed. It is not possible to add new custom
knot curves to such `CurvesGeometry` as custom knot offsets are
calculated all together and there is no way to distinguish between old
curves with lost knots and new ones. This is more a future problem.
The actual problem in `main` can be shown with an attached blend file
(see PR) by applying `Subdivide` to some points and then adding new
`Bezier` curve to the same object. This particular problem could be
addressed somewhere in `realize_instances.cc` but the actual problem
would persist.
This PR handles custom knots in all places where `BKE_defgroup_copy_list`
is iused, and where `bke::curves::copy_only_curve_domain` is called.
Here the assumption is made that only these places can copy custom knots
modes without copying custom knots. Depending on operator logic knots are
handled most often in one of two ways:
- `bke::curves::nurbs::copy_custom_knots`:
copies custom knots for all curves excluding `selection`. Knot modes
for excluded curves are altered from the custom mode to calculated.
This way only curves modified by the operator will loose custom knots.
- `bke::curves::nurbs::update_custom_knot_modes;`
alters all curves to calculated mode.
In some places (e.g. `reorder.cc`) it is possible to deal with knots
without side effects.
PR also adds `BLI_assert` in `load_curve_knots` function to check if
`CurvesGeometry::custom_knots` exists for custom mode curves. Thus
versioning code is needed addressing the issue in files in case such
already exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/139554
The Movie distortion node crops its data if the movie size differs from
the input size. That's because boundary extensions do not take
calibration size into account. To fix this, we use the same coordinates
range as the distortion grid computation, which computes the distortion
in the space of the calibration size.
Pull Request: https://projects.blender.org/blender/blender/pulls/139822
It would run into using the same frame twice, looking like "freeze
frames"
Apparently we had a similar issue before, see 3f8ec963e3
Just a PoC to show that this looks like a precision/rounding issue when
getting a "working" `UsdTimeCode`.
In the modifier code, we are doing a roundtrip going from frame >> time
(in seconds -- via `BKE_cachefile_time_offset`) and then back to frame
before we store that in `USDMeshReadParams`.
To avoid the precision loss, this PR introduces
`BKE_cachefile_frame_offset` to stay in the "frame" domain and
circumvent going through FPS alltogether.
There might be better ways to let USD handle the "sightly off"
`UsdTimeCode` better though.
Pull Request: https://projects.blender.org/blender/blender/pulls/139793
