With the previous fix to the node, 8a11f0f3a2, the new edge
indices are built with the changed corner vertices from a previous step
in the algorithm. That doesn't work for loose edges though, since they
aren't used by any face corners. The best solution I could come up with
was adding a second loop over the split vertices that adjusts the vertex
indices of loose edges. This can be skipped when there are none.
Pull Request: https://projects.blender.org/blender/blender/pulls/109262
This reverts commit ef9d9c6856. Actually probably better to leave
this in, since it may be used by normal computation even if seemed to
work ok in tests.
The root of the bug was wrong edges, but it wasn't necessary to compute
corner edges at all and this was unnecessarily added in 16fbadde36.
Ref #109161
The old subsurf DerivedMesh code creates an edge layer
without initializing it, which makes the proper lazy initialization
of the edge layer later think that it's already finished. To avoid that,
remove the edges when creating the DerivedMesh at first.
Similar to 85bd64ece4
The Select Similar UV operator defined multiple enum item arrays, and
returned one depending on current mode in the enum function
uv_select_similar_type_itemf().
The operator prop's enum items used only the vertex items, which
resulted in several items never being extracted because they were
dynamically generated instead of exposed to the RNA.
This commit groups all items in a single array so that they are
exposed, but uses the enum function to filter them.
Issue reported by Satoshi Yamasaki (@SatoshiYamasaki) in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/108994
The steam environment sets LD_LIBRARY_PATH with a libtbb.so.2 that is
incompatible with our own. This wrapper scripts gives our own library
priority.
There is a more modern "Steam Linux Runtime" that can be used instead of
the "LD_LIBRARY_PATH Steam Runtime" and which launches Blender, but it
fails to detect GPU compute libraries. So that was not an option.
Ref #107385
Pull Request: https://projects.blender.org/blender/blender/pulls/109169
This affected only vector and color inputs. The issue was that those were
expected to be stored as float-array properties. However, when setting them
from python using `modifier["Input_X"] = [1, 2, 3]` the array type becomes
either `int` or `double`, but not `float`. A workaround was to use
`modifier["Input_X"][:] = [1, 2, 3]` as this changes the property inplace.
Now `int` and `double` arrays are also understood by the modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/109203
If accumulated amount of points is zero, next offsets
will be empty too. Instead to expand offsets to create
empty curve, just delete source curve and skip any next steps.
Pull Request: https://projects.blender.org/blender/blender/pulls/109172
Before 17d161f565, the "vec_lnor" stored the automatically
computed normal without any influence from custom normals. But after,
the normals were used from the final output corner normals array, which
did have the custom normal data factored in at the end. This fix is to
revert part of that commit, storing the automatically computed normal
per space like before.
Exposing both the option not to use pinned islands and to skip pinned
islands in the same drop-down was confusing.
Now there is a checkbox "Pin", when disabled, pinned UV's don't
have any impact on the packed result.
When enabled, the pin-method selects how pinned islands are handled.
Also remove the "ignore" option from the UI as this didn't fit well with
other methods of handling pinned islands. Instead, islands to be ignored
can be de-selected by the user.
Ref !108733.
When a Blender material has no nodes, its viewport color,
roughness and metallic values are saved as inputs to a simple
USD Preview Surface. This pull request fixes a bug where
the Blender material's viewport color is also saved as
the USD Preview Surface emissiveColor attribute.
This bug was accidentally introduced in #107947.
To reproduce the issue, open the default Blender scene,
turn off nodes on the material and set the material's viewport
color. Export to USDA and notice that the color is incorrectly
set as the emissiveColor input in the USD shader.
Pull Request: https://projects.blender.org/blender/blender/pulls/109138
The rendering pipeline will re-use dependency graph and request
for re-building its relations for every new view layer, and try
to re-use as much evaluation as possible.
This could potentially run into situation when a content of
collection is changed: due to the difference in the per-view
layer visibility. If the evaluated collection has an object cache
this will make the cache to get out-of-sync with the actual
content. The cache on the evaluated collection might be created
when instancing system iterates over the collection.
This change makes it so the cache is freed when the dependency
graph relations are updated. This might be a bit too intrusive.
There might be ways to somehow ensure the content of the collection
is still the same as it was before the relations update, but this
is much more complicated task. Perhaps the performance is already
good enough.
This is a collaboration with Jacques Lucke, who was looking into
the same report, bouncing some ideas back and forth, and helped
testing the patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/108816
This was broken in 037b3f87bd.
This fix brings the original problem back a bit in that there will be an additional
frame update now, but really only a redraw should be necessary without a
depsgraph update.
The depsgraph update is caused by the `NC_SCENE | ND_FRAME` notifier,
which is checked for in `wm_event_do_notifiers`. Changing that in more depth
is a bit risky for 3.6 now unfortunately.
Replaces vector of allocations with dynamic linked list.
Bug caused by previously freed buffers still having been in the
list. Linked list enables fast removal of already-released buffers.
Also ensured that the memory manager classes are included in
memory tracking.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108940
In this specific code path (recursive reading inside .blend files
containing assets), reading datablocks marked as asset would move
ownership over the asset metadata without indicating that in the source
that owned it previously. This would cause a double free attempt.
There where glitches while weight painting in Grease Pencil with
auto-normalize enabled. This resulted in incorrect weights on vertices.
And sometimes a vertex group not deformed by bones was also affected
by auto-normalize (which should never happen).
This was due to:
- An erroneous line in the auto-normalize function which led to an
index out of bounds (and screwing up the vertex weights).
- An edge case where the active vertex group was de facto the only
group to be normalized.
Also in this patch:
- Removal of unreachable code
- Better names for the auto-normalize functions
Pull Request: https://projects.blender.org/blender/blender/pulls/109036
There is an optimization to avoid creating the attribute if we only
set faces smooth. But since "use_smooth" and "sharp_face" are
inverted, the check for that case needs to be invertex compared
to other similar attribute setters.
`strcpy` could overflow the destination buffer by 768 bytes,
use FILE_MAX for the filepath buffer size.
Also include the size in the functions signature to avoid similar
errors in the future.
Just avoid creating links to outside the group. The original
version worked a little more accurately. But still she was just
making up links (because the inline version of the graph wasn't the same anyway).
For now, this is just a workaround to work around the
problem in the new behavior caused by fa3ca9afdb .
Pull Request: https://projects.blender.org/blender/blender/pulls/108332
Searching for a simulation state at a particular frame was implemented
with a linear loop. The timeline did that for every visible frame,
giving quadratic performance overall when zoomed out. Since the
states are already assumed to be sorted by frame, we can use binary
search instead giving logarithmic performance for each lookup instead.
In the test file from #108097, instead of dropping to 20-30 FPS
after about 4000 frames, I observed the original 70 FPS.
Pull Request: https://projects.blender.org/blender/blender/pulls/109037
Modifiers can use the same bake directory now. If multiple modifiers
using conflicting paths are baked at the same time there is now an
error popup.
Modifiers can also bake to directories that already contain data
(including their own). To give users a heads-up there is now a
confirmation popup in that case. It only comes up once per bake operator
invoke to strike a balance between silently overwriting data and not
being too obnoxious when users want to rebake the same simulation many
times.
Pull Request: https://projects.blender.org/blender/blender/pulls/108288
Fixed an issue where meshes without loose elements or hidden triangle
faces were not taking into account the relevant masks.
From the user's perspective, this might not have seemed like a
significant problem. However, hidden faces in edit mode were
occasionally still snappable.
Duplicating will otherwise keep the same bake directory, which causes
a path conflict and requires manual fixing by users. Clearing the path
on copy makes it so the default path is generated on baking.
This does not change the path when doing internal copies, like
- Depsgraph "evaluated" object vs "original"
- Appending or linking objects
- Making a linked object local
Pull Request: https://projects.blender.org/blender/blender/pulls/109014
The counters for polygons count and face corners count were inverted,
leading to various out of bounds accesses due to wrong data size
allocation.
Not sure where the bug comes from, whether it's original, or a typo from
some refactor.
The Alembic procedural was refrenced here even if USD was loaded.
Now check the CacheFile type and let the user know Render Procedurals
are only supported for Alembic atm.
Pull Request: https://projects.blender.org/blender/blender/pulls/108701
Since we scale the GPU matrix a certain way (in order to draw a round
circle even for different UI x/y scaling), we have to also compensate
with GPU matrix translation (instead of drawing the raw
frame/value as coords untranslated).
There might be ways to solve this differently (e.g. manipulating the passed
coords instead of the GPU matrix or having a version of imm_drawcircball
that can do this in a way that compensates UI view scaling), but this seems
to be the most straightforward.
Thx @mano-wii hinting at the way to do this with GPU matrix alone.
Should probably go into 3.3 LTS as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/108979
As Alembic stores hierarchies as paths separated by a forward slash, such
character cannot be used in a name. This resulted in an uncaught thrown
exception. To fix this, replace '/' with '_' like for other illegal
characters.
