Straightforward port. I took the oportunity to remove some C vector
functions (ex: copy_v2_v2).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
Remove the use of a separate contiguous positions array now that
they are stored that way in the first place. This allows removing the
complexity of tracking whether it is allocated and deformed in the
mesh modifier stack.
Instead of deferring the creation of the final mesh until after the
positions have been copied and deformed, create the final mesh
first and then deform its positions.
Since vertex and face normals are calculated lazily, we can rely on
individual modifiers to calculate them as necessary and simplify
the modifier stack. This was hard to change before because of the
separate array of deformed positions.
Differential Revision: https://developer.blender.org/D16971
Existing `BKE_main_namemap_destroy` is too specific when a entire Main
needs to have its namemaps cleared, since it would not handle the
Library ones.
While in regular situation current code is fine, ID management code that
may also edit linked data needs a wider, simpler clearing tool.
Current `BKE_id_remapper_add` would not replace an already existing
mapping rule, now `BKE_id_remapper_add_overwrite` allows that behavior
if necessary.
If identity pairs (i.e. old ID pointer being same as new one) was
forbidden, then this should be asserted against in code defining
remapping, not in code applying it.
But it is actually sometimes usefull to allow/use identity pairs, so
simply early-return on these instead of asserting.
The goal is to give technical artists the ability to optimize modifier usage
and/or geometry node groups for performance. In the long term, it
would be useful if Blender could provide its own UI to display profiling
information to users. However, right now, there are too many open
design questions making it infeasible to tackle this in the short term.
This commit uses a simpler approach: Instead of adding new ui for
profiling data, it exposes the execution-time of modifiers in the Python
API. This allows technical artists to access the information and to build
their own UI to display the relevant information. In the long term this
will hopefully also help us to integrate a native ui for this in Blender
by observing how users use this information.
Note: The execution time of a modifier highly depends on what other
things the CPU is doing at the same time. For example, in many more
complex files, many objects and therefore modifiers are evaluated at
the same time by multiple threads which makes the measurement
much less reliable. For best results, make sure that only one object
is evaluated at a time (e.g. by changing it in isolation) and that no
other process on the system keeps the CPU busy.
As shown below, the execution time has to be accessed on the
evaluated object, not the original object.
```lang=python
import bpy
depsgraph = bpy.context.view_layer.depsgraph
ob = bpy.context.active_object
ob_eval = ob.evaluated_get(depsgraph)
modifier_eval = ob_eval.modifiers[0]
print(modifier_eval.execution_time, "s")
```
Differential Revision: https://developer.blender.org/D17185
The merge down operator was sometimes copying the wrong frame, which altered the animation.
While merging the layers, it is sometimes needed to duplicate a keyframe,
when the lowest layer does not have a keyframe but the highest layer does.
Instead of duplicating the previous keyframe of the lowest layer, the code
was actually duplicating the active frame of the layer which was the current frame in the timeline.
This patch fixes the issue by setting the previous keyframe of the layer as its active frame before duplication.
Related issue: T104371.
Differential Revision: https://developer.blender.org/D17214
There were two errors with the function used to convert face sets
to the legacy mesh format for keeping forward compatibility:
- It was moved before `CustomData_blend_write_prepare` so it
operated on an empty span.
- It modified the mesh when it's only supposed to change the copy
of the layers written to the file.
Differential Revision: https://developer.blender.org/D17210
Use the `SharedCache` concept introduced in D16204 to share lazily
calculated evaluated data between original and multiple evaluated
curves data-blocks. Combined with D14139, this should basically remove
most costs associated with copying large curves data-blocks (though
they add slightly higher constant overhead). The caches should
interact well with undo steps, limiting recalculations on undo/redo.
Options for avoiding the new overhead associated with the shared
caches are described in T104327 and can be addressed separately.
Simple situations affected by this change are using any of the following data
on an evaluated curves data-block without first invalidating it:
- Evaluated offsets (size of evaluated curves)
- Evaluated positions
- Evaluated tangents
- Evaluated normals
- Evaluated lengths (spline parameter node)
- Internal Bezier and NURBS caches
In a test with 4m points and 170k curves, using curve normals in a
procedural setup that didn't change positions procedurally gave 5x
faster playback speeds. Avoiding recalculating the offsets on every
update saved about 3 ms for every sculpt update for brushes that don't
change topology.
Differential Revision: https://developer.blender.org/D17134
The recursion depth was checked for equality with a maximum depth,
allowing leaves with more primitives if a certain depth was reached.
However, a single leaf must always use the same material (including
set_smooth), so if a leaf contained multiple materials it was split
anyway. This meant that in the next recursion step the depth was
larger than the cutoff value and it would go back to recursing until
the number of primitives was small enough, ignoring the recursion
depth for the rest of the process.
In certain edge cases this could lead to a stack overflow.
Even with the check changed from 'equality' to 'larger or equal'
this could still fail in the pathological case where every primitive
has another material. But that can't be helped, and it wouldn't
realistically happen either.
Differential Revsision: https://developer.blender.org/D17188
Straightforward port. I took the oportunity to remove some C vector
functions (ex: `copy_v2_v2`).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
The declaration of group nodes using unavailable linked groups contains
a `skip_updating_sockets` tag, which indicates that the node shouldn't
change. This information was not used properly further down the line.
Versioning code in `do_versions_after_linking_260` inserted new group input
and output nodes. And (reasonably?) expected sockets to exist on those nodes.
However, `nodeAddStaticNode` did not initialize sockets on nodes with that use
`declare_dynamic` yet. This patch changes it so that `declare_dynamic` is used
in more places, which caused issues during file loading when node groups are
updated in somewhat arbitrary order (not in an order that is based on which
groups use which).
Differential Revision: https://developer.blender.org/D17183
n versioning, when converting CD_SCULPT_FACE_SETS to CD_PROP_INT32
the layers were not kept properly ordered by type.
This was discovered while investigating T104053
Differential Revision: D17165
Previously, having the "Encoding speed" set to "slowest" would choose
libaom-av1 first and librav1e second. This change makes Blender choose
librav1e first (and has a fallback to whatever other AV1 codec is
available if librav1e is not installed).
Addresses /T103849 on systems where librav1e codec available.
Reviewed By: sergey, ISS
Maniphest Tasks: T103849
Differential Revision: https://developer.blender.org/D17002
Also minor changes in comments:
- Reference BLENDER_HISTORY_FILE instead of the literal file-name
(simplifies looking up usage).
- Use usernames in tags, as noted in code-style.
Allow to explicitly swap node links by pressing the alt-key while
reconnecting node links. This replaces the old auto-swapping based on
matching prefixes in socket names.
The new behavior works as follows:
* By default plugging links into already occupied (single input)
sockets will connect the dragged link and remove the existing one.
* Pressing the alt-key while dragging an existing node link from one
socket to another socket that is already connected will swap the
links' destinations.
* Pressing the alt-key while dragging a new node link into an already
linked socket will try to reconnect the existing links into another
socket of the same type and remove the links, if no matching socket
is found on the node. This is similar to the old auto-swapping.
Swapping links from or to multi input sockets is not supported.
This commit also makes the link drag tooltip better visible, when using
light themes by using the text theme color.
Reviewed By: Hans Goudey, Simon Thommes
Differential Revision: https://developer.blender.org/D16244
Simplify `BM_uv_element_map_create` by using `BM_face_calc_area_uv_signed`.
Remove unused UV winding code in `BM_uv_vert_map_create`.
Fixes unlikely memory leak in `BKE_mesh_uv_vert_map_create`.
No functional changes.
Differential Revision: https://developer.blender.org/D17137
BKE blendfile should not be allowed to deal with DNA deprectaed data, so
move recent check in rB138b3815e528 into BLO readfile, in a new
`blo_read_file_checks` util that is being called at the very end of main
readfile code (`blo_read_file_internal` and `library_link_end`).
rB7f564d74f9ed (6 years ago!) forgot to clear the deprecated
`Window->screen` pointer on file read for recent-enough .blend files.
This is required since a valid value is always written in .blend files
for that pointer, to ensure backward compatibility.
The issue was never detected so far because that pointer is explicitely
reset to NULL after filewrite, which includes any memfile undostep
write, and usually existing UI data is re-used instead of loading the
one from the .blend file, so thedden assert in `blo_lib_link_restore`
would never be triggered.
Now moved the assert at the end of `setup_app_data` to ensure it always
get checked.
This addressed feature request T99811.
Added the following features to fully support importing USDZ archives:
- Added .usdz to the list of supported extensions.
- Added new USD import options to copy textures from USDZ archives. The
textures may be imported as packed data (the default) or to a directory
on disk.
- Extended the USD material import logic to handle package-relative texture
assets paths by invoking the USD asset resolver to copy the textures from
the USDZ archive to a directory on disk. When importing in Packed mode,
the textures are first saved to Blender's temporary session directory
prior to packing.
The new USD import options are
- Import Textures: Behavior when importing textures from a USDZ archive
- Textures Directory: Path to the directory where imported textures will
be copied
- File Name Collision: Behavior when the name of an imported texture file
conflicts with an existing file
Import Textures menu options:
- None: Don't import textures
- Packed: Import textures as packed data (the default)
- Copy: Copy files to Textures Directory
File Name Collision menu options:
- Use Existing: If a file with the same name already exists, use that
instead of copying (the default)
- Overwrite: Overwrite existing files
Reviewed by: Bastien
Differential Revision: https://developer.blender.org/D17074
Only one point should be used to create a reference rotation for other
points to follow. Using two caused the resulting twist to be
asymmetric, especially noticeable on symmetrical, cyclic curves.
An update to [0] which broke curve_to_mesh & deform_modifiers tests,
now this change only applies to cyclic curves as the final result was
much greater for non-cyclic curves because of a difference between how
end-point directions are calculated (see code-comments for details).
Alternate fix to D11886 which caused T101843.
[0]: 36a82314a0.
This reverts commit 36a82314a0.
as it has broken tests for the last day and a half, it likely just
needs a test file update, but we can't keep this failing longer
than it already has.
We should always have an active vertexgroup (making sure this is the
case was just not happening on the greasepencil side).
Now do this (similar to what is done for other object types in
`object_defgroup_remove_common`).
Maniphest Tasks: T104089
Differential Revision: https://developer.blender.org/D17091
