FreeStyle line styles were not part of the dependency graph, and
blacklisted from the Copy-on-Write system. As a result, animated
FreeStyle properties would not be updated by the animation system,
resulting in T72213. There was an explicit call to run the animation
system on the original datablocks, but that was (for good reasons)
removed in D5394.
This commit adds the FreeStyleLineStyle datablocks to the dependency
graph and allows them to be handled by the CoW system. As a result
- the UI now updates properly when properties are animated, and
- animated property values are actually used when rendering.
This commit includes @Sergey's patch P1222, which unifies two bits of
code that did the same thing: check whether datablock type is covered by
copy-on-write.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D6609
Related to T62882
When the SupportsMapping modifier flag was added to the dynamic paint
modifier it was added commented out. It may have not worked back then,
but it seems to work fine now.
MOD_weightvgedit.c was already updated similarly.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6072
This would happen if a tile is found on disk, painting would actually
request that tile (because corresponding uvs were in that range), but
that tile was not added in blenders list of tiles in that Image.
Need to also check tile in `image_quick_test` (regardless of iuser
having passed).
thx @lukasstockner97 for additional input!
Maniphest Tasks: T73110
Differential Revision: https://developer.blender.org/D6578
selection
False positive when a sequences end would be the same as active
sequences start.
Also thx @sybren for the heads up to make this more readable.
Maniphest Tasks: T72546
Differential Revision: https://developer.blender.org/D6451
I doubt we can do much better. Most of the aliasing comes from the edge
detection which does not use a lot of samples. We could use more samples
but then the detection becomes way more complex and expensive.
The second issue comes from the reconstruction (AA pass) that only bleed
adjacent pixels in if their line direction is perpendicular to the offset.
This makes corner gaps on certain diagonals.
'Straight Cut' is actually documented as creating N-Gons. However, the
code was disallowing this. This is probably a mix-up as the "allow N-Gons"
option is documented as a "force quad/tri" option.
There is already code for this, it just wasn't working. Now add the
slash after checking for an empty string.
Differential Revision: https://developer.blender.org/D6568
We can't use the fast path when the mesh is used by mulitple objects and so
slower sculpting is expected then. But fake users should not affect this. This
also fixes the same type of error in a few other areas.
Cache file loading for mesh and particle files now works through the direct update_structures functions. The final cache mode now also only bakes the most essential files and is therefore not resumable anymore.
When computing the roll value coming from the handle bone, the code
was using some strange unexplained math. It probably works fine when
the difference with the 'zero roll' orientation is pure twist, like
is the case when called from mat3_to_vec_roll. However, it appears
to break when significant swing is involved.
The issue is fixed by using the proper Swing+Twist decomposition
utility function that was added in a recent version for drivers.
This improves performance by reducing the amount of false positives.
A self overlap is made, so the distance from the vertices in the
overlap nodes is actually added.
Blender supports locking vertex groups to prevent changes to the
weights. However, as mentioned in comments for D3837, it is hard
to use this because there is no interface for locking in 3D View.
This adds a red shade to bones that are associated with a locked
weight group during weight paint mode, as the first step to adding
such interface. The next step is adding a pie menu for lock/unlock.
Differential Revision: https://developer.blender.org/D6533
Once again, am not exactly sure why that was working before, and not
anymore - but in any case, doing that kind of update here is not only
useless (since we have to do it at the end of the whole
collections/objects duplication and remapping anyway), it is also rather
dangerous, as collections are currently in rather invalid states at that
point of the code...
Note that in ideal world, `BKE_main_collection_sync()` & co would be
lazy (setting only a flag, then code actually needing this to be valid
again should call some sort of `BKE_main_collection_sync_ensure()`).
Then we would not have to worry about such things (and we'd get nice
performance improvements in some cases, also in main remapping code,
etc.).
Food for some refactoring, some day...
Simplify a bit, and remove some now redundant remappings.
As a side note, rBac723db57fd8ba5 actually also fixed some unreported
issues (missing remappings to new objects/collections in new copied
scene, that were not previously handled by the 'custom' code).
There are almost certainly still some missing remappings around,
though...
