This reverts commit c6497dd9f7.
This wasn't working the way I expected, it seems the LIB_TAG_NEW isn't
set here. Better to address the fundamental issues anyway. Sorry for
the noise.
When appending objects from an older file, versioning needs to run to add
an auto smooth modifier if necessary. However, this was running for all
objects rather than just the newly appended objects. It's quite wrong to
modify existing objects here, so add an explicit check for that. This could
improve performance as well, but skipping checks for objects when
the work is unnecessary.
The crash will hopefully be resolved by other improvements to the auto
smooth versioning (making it properly idempotent and running it again
should fix the problem with the hidden legacy flags still set). But I still think
this PR is worth committing, to be very explicit about only modifying new
objects in versioning code.
Pull Request: https://projects.blender.org/blender/blender/pulls/119467
Previously I misunderstood the subsurf modifier's handling of custom
normals. The "use custom normals" check in 4.0 checked if there were
custom normals and whether the auto smooth flag was checked. I wrongly
changed that to check the mesh normals domain instead of whether there
was custom normals. In 4.1, auto smooth isn't required to use custom
normals, but that should be the only change here.
In this PR, that change is done for CPU and GPU subdivision, and for
the versioning which adds a modifier. The versioning now only puts the
new modifier before the subsurf modifier if it would have used the
custom normals interpolation in 4.0.
The last change causes two test failures which I also misunderstood
before. The previous results were arguably incorrect, because the
Cycles experimental adaptive subdivision ignored the auto smooth
angle, which was 5 degrees. It should have been 180 degrees.
I will modify those test files to remove auto smooth from the meshes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119485
The Weighted Normal modifier has a "Keep Sharp" option that used to
recalculate the sharp edge tags based on the mesh's smoothing angle.
To keep the same behavior, an auto smooth versioning modifier has to
be added before that modifier when the option is on.
Pull Request: https://projects.blender.org/blender/blender/pulls/119400
Unfortunately the only versioning code that can "properly" add data-
blocks is not run when linking or appending (`do_versions_after_setup`
has details). The versioning has to be done manually for this case.
Fortunately that is simple since the versioning function already just
operators on a main database.
With some data-type conversions we can do a best-effort conversion of
UI data like default values and min and max to the new data type.
This can help to make Python scripts simpler and to avoid bugs like
#105965.
Pull Request: https://projects.blender.org/blender/blender/pulls/106161
The core of the issue was that `sculpt_flag` was used by three different enums (`eGP_Sculpt_Flag`, `eGP_Sculpt_Mode_Flag`, and `eBrushFlags`). This resulted in the flag getting overriden because `ENUM_OPERATORS` expected the maximum value of `eGP_Sculpt_Flag` to be `(1 << 3)` which it wasn't.
The `sculpt_flag` was exposed through python as `"direction"`.
In the UI this meant that it was effectively used as `brush.direction`. This fix replaces `brush.gpencil_settings.direction` with `brush.direction`.
It also makes sure `sculpt_flag` is only ever used with values from `eGP_Sculpt_Flag`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119373
There seems to be an integer overflow in OpenVDB code. For now just avoid rendering
the volume when the indices are very large, which is an extreme case anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/119279
The issue was that calling `ensure_geometry_instances` converts all instances to a
geometry, even the ones that can't be converted. The comment already says that
non-geometry instances should stay intact, but that didn't work correctly yet:
```
/**
* If references have a collection or object type, convert them into geometry instances
* recursively. After that, the geometry sets can be edited. There may still be instances of
* other types of they can't be converted to geometry sets.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/119324
"r_map" is null for the generate layers operator (rather than the modifier
evaluation). It should disable the creation of the "CD_NORMAL" layer too,
like the crease, bevel weight, sharp edge, and uv seam attributes above.
As mentioned in new code comments, the auto smooth behavior in 4.0 was
to skip sharp angle tagging when the evaluated mesh had custom normals.
There was already a check for custom normals on the original mesh (we
can't access the evaluated mesh from versioning code). But that didn't
handle cases where custom normals were created by modifiers (the normal
edit and weighted normal modifiers). Now skip adding the new modifier
when those modifiers come last in the stack. Alternatively we could
check if they existed in the stack at all, but that seems a bit more
risky.
When linking a collection from library, it can be linked inside another
linked/overrided collection if it is selected in outliner. This can be
prevented by linking with editable parent collection.
Pull Request: https://projects.blender.org/blender/blender/pulls/119144
Caused by 9c1da81a4c.
This happened in the case where objects shared the same data and slots
are assigned to object and receiving object did not have a material slot
yet.
Then, `ob->matbits` may be NULL, now just check for this, too.
Pull Request: https://projects.blender.org/blender/blender/pulls/119161
For example, creating the "position" attribute with the wrong name or type
could crash Blender when exiting edit mode. This is because some data isn't
stored as attributes in Blender, and the attribute API doesn't work very well
with BMesh.
Two parts to the solution:
- Remove builtin attributes with incorrect domains or names when
converting from BMesh to Mesh.
- Add error messages when creating builtin attributes in edit mode. It's still
possible to create name-convention attributes, because Blender should be
able to handle different types and domains for them.
Pull Request: https://projects.blender.org/blender/blender/pulls/119110
The "capture field on geometry" utility is used in many places to store
the result of field evaluation as an attribute. There is a special case
for when an attribute already exists with the same name, data type, and
domain. But when exactly the same attribute was stored, it would assert
because it ended up copying an array to itself. Arguments for those copy
functions aren't supposed to alias each other.
As a fix, clarify the logic a bit to return earlier in this case.
Also remove a redundant case handling the same thing later on
in the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/119063
It's possible that multiple custom data layers share the same underlying data.
This data is only written once (per data-block) currently. However, when reading
the data again, two separate `ImplicitSharingInfo` were constructed which
referenced the same underlying memory. The fix is to reuse previously created
`ImplicitSharingInfo` that manage the same data.
Pull Request: https://projects.blender.org/blender/blender/pulls/118991
Second issue reported in the comment was caused by some shapekeys
flagged as embedded liboverride data, when their owner ID (Mesh e.g.)
is not a liboverride at all.
The `BKE_lib_override_library_validate` called on file read was only
covering real liboverride IDs, which where then supposed to take care of
their own embedded data. But since the owner ID is already a full
non-override ID, its embedded data ended up never being properly
sanitized.
Most likely more corruption data from quite old files and/or deprecated
experimental features.
- Skip leading forward slashes when setting the temp directory.
- Add a utility function to set the temporary directory
which is used for the user preferences & environment variables.
This issue was raised by #95411 where "//" resolves to "/",
then asserts when passed to Blender's file-system functions.
However the crash referenced in this report looks to be caused
by Collada failing to write to the temporary directory which
can be handled separately.
Ref !118872
Internal link is not created for a node when it has rotation output
socket. This is because the missing case for `sock_rotation` in
`get_internal_link_type_priority()` which fails to find input_socket
priority in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/118735
Crash happens in `action_group_colors_set_from_posebone` /
`ANIM_bonecolor_posebone_get` on a `bPoseChannel` without a `bone`.
If I am not mistaken a new `bPoseChannel` (e.g. after duplication) will
only get its `bone` after leaving editmode.
So in a way the situation is similar to 2a8ce1f121
Behavior of `animchan_sync_group` is not reliable in a way that getting
a `bPoseChannel` from an `bActionGroup` will guarantee these are really
corresponding. So usually, if you dulplicate/symmetrize a bone, there
would be no corresponding `bActionGroup` and nothing would happen
really. But you could for example group fcurves from `Bone` under a
group called `Bone.001` and vice versa. This is totally allowed to do.
In this case, `animchan_sync_group` is doing nothing totally helpful, so
it could find the "wrong" `bPoseChannel`. And it could try
`action_group_colors_set_from_posebone` with that `bPoseChannel` which
still does not have a `bone` and then crash.
So now only do this if we have a valid `bone`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118676
Oversight in e3d31b8dfb
While most situations would have other vertexgroups set anyways (so this
probably wasnt noticed, it was only ignored if it is the only
vertexgroup used), at least theoretically it could happen that
`cloth_uses_vgroup` would return false even then `vgroup_shear` is set
(thus skipping actually setting these weights later).
So far, when deleting a library (either explicitely, or through e.g.
relocation), its dependencies would get a `nullptr` parent, and
therefore become 'directly used' libraries.
This commit adds a new util to rebuild the libraries hieararchy, and
calls it when a Library ID is deleted.
NOTE: While logic is somewhat similar to what liboverride resync does to
sort the libraries by indirect levels
(`lib_override_libraries_index_define`), there are some key differences
here, notably the fact that if a library has a valid `parent` pointer,
it is not replaced, even if a 'better' parent (less indirect library)
could be found.
The issue described was that the motion path didn't display the last frame
of a scene.
This PR makes the user facing motion path range inclusive on both ends.
E.g. when the user specifies a motion path from 1-24 the will now get all 24
frames, whereas previously the motion path would end at frame 23.
This also makes the `Scene Frame Range` option work properly since that
had the same issue. Now it displays the actual full scene range.
Internally, the `bMotionPath` is still exclusive on the upper bound.
It is just the `bAnimVizSettings` range that has been modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/118611
The issue here is that the `parent` pointer of indirectly linked
libraries would not be propoerly cleared when their current parent was
deleted.
Note that this fix will leave effectively indirectly linked libraries
shown as directly used ones in the UI, until the blendfile is saved and
reloaded. This is not a new issue though, deleting a parent library in
the Outliner has the same effect.
Fairly straightforward.
Note that only the Noise modifier is handled in this commit, for demonstration/testing purposes.
The other modifiers remain TODO and will be handled in later commits.
Pull Request: https://projects.blender.org/blender/blender/pulls/118415
This is generally more flexible and less error prone. The struct
implements a proper descructorfor this anyway. That also makes the
separate free function unnecessary-- it's redundant with the destructor.
This converts the "Layer Adjustments" from GPv2 into modifier setups in GPv3.
They include:
* Layer tint
* Layer thickness offset
* Thickness factor (for the entire object)
Both the "layer tint" and the "thickness factor" are converted using the existing modifiers.
Because the thickness modifier uses a factor instead of an offset, the "layer thickness offset" is converted to a geometry nodes modifier setup for each layer that adds an offset value to the radii instead of multiplying by a factor.
Pull Request: https://projects.blender.org/blender/blender/pulls/118149
In GPv2, strokes could be edited using bézier curve handles. This was implemented by creating an `editcurve` for a stroke that would store the handles and other attributes.
In GPv3, we can directly make use of the `CURVE_TYPE_BEZIER` and store the curve as a bézier curve.
Note: This PR only handles conversion. Not rendering or anything else.
Pull Request: https://projects.blender.org/blender/blender/pulls/118386
Essentially move the Object-handling logic also into
`bke::greasepencil::convert::`. This code will also be needed for
automatic conversion on fileread etc.
It also helps to keep all the conversion logic in one place (especially
since there is going to be way more done at object level - modifiers,
animation, etc.).
Pull Request: https://projects.blender.org/blender/blender/pulls/118384
This reverts commit 31b8323b93.
Allocating memory in parallel is fine as long as each threads only
writes to the memory it allocates, which is the case here.
