This pull request adds the ability for the `Limit` and `Falloff` values for the View and Normal automask modes to be applied per-brush instead of modifying the global tool value.
Previously, while the flag settings were stored at the brush and global level, the values would always change the global value even when using the advanced tab of the brush menu.
## Testing
* `make test` results in 3 failures (49 - io_wavefront, 134 - compositor_distort_cpu, 323 - imbuf_save), but these tests appear to fail even prior to any changes being applied when running locally
* Manual testing with older version blend files to ensure that the value is defaulted correctly.
* Visual testing to verify that brush values are favored over global values.
Addresses #115174
Pull Request: https://projects.blender.org/blender/blender/pulls/117433
If the mix factor means the old values won't be used at all,
the existing corner normals from before the modifier don't
matter and we can skip computing them.
There are still node versioning bits running after linking, for example
`version_geometry_nodes_replace_transfer_attribute_node`. This code
relies on node types being untouched at that point.
Move the unknown node type replacement from `ntreeSetTypes` into the
`ntreeUpdateAllNew` function. This is called _after_ late versioning.
Pull Request: https://projects.blender.org/blender/blender/pulls/117441
Rename: anim -> ImBufAnim
Rename: anim_index -> ImBufAnimIndex
There were cases where removing redundant "struct" qualifier caused
a warning since the name of the struct member was also anim.
Use uppercase type name to conform with other types names.
Ref !117394
This has been broken since 2.8.
The highlevel reason for this is that the "info file" (saved as frame
zero) was not written anymore.
Reason for that in turn is that when calling BKE_ptcache_write outside
the bake job, the PTCacheID calldata (a psys in our case) is not the
evaluated particle system, causing a check for totpoint to fail (these
were always zero).
Deeper reasoning is unclear, no further investigations were done as to
why/when this happened.
The solution proposed here is using the evaluated psys when writing the
info frame (and this is isolated to just this spot and only to particle
systems). File then gets
written and can/will be read when using this as an external disk cache
in another file.
Pull Request: https://projects.blender.org/blender/blender/pulls/117401
GreasePencil v3 requires some additional processing on its data before
writing to blendfile, and after reading from it.
Extract this from generic `read/write` code, and put it into dedicated
callbacks in Cpp classes that need it (layer groups and leaves
currently).
NOTE: Work done while exploring possibility to use 'memfile' read/write
code for GP editmode undo (!117072), but ended up taking a different
approach for it, so this PR is purely a 'no expected changes in behavior'
refactor at this point.
Pull Request: https://projects.blender.org/blender/blender/pulls/117413
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
Previously, `frame_key_at` would return `-1` for when it couldn't find
a key for the given frame.
This could lead to issues though, because `-1` is a valid key (it is a valid scene frame number).
This changes the API to return an optional instead. This makes it very clear
when no key was found, and should make it less error prone.
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
When using the MapUV node for certain NPR workflows (for example palette
based remapping of colors) it can be useful to not use the default
anisotropic filtering.
In preparation of potentially adding more filter modes at a later stage
and to keep things consistent with the 'transform' node we use the full
set of interpolation modes in the enum, but expose only the implemented
ones in RNA..
This has been broken since 2.8.
The highlevel reason for this is that the "info file" (saved as frame
zero) was not written anymore.
Reason for that in turn is that when calling `BKE_ptcache_write` outside
the bake job, the `PTCacheID` `calldata` (a psys in our case) is not the
evaluated particle system, causing a check for `totpoint` to fail (these
were always zero).
Deeper reasoning is unclear, no further investigations were done as to
why/when this happened.
The solution proposed here is using the evaluated psys when writing the
info frame (and this is isolated to just this spot). File then gets
written and can/will be read when using this as an external disk cache
in another file.
Pull Request: https://projects.blender.org/blender/blender/pulls/117291
This was caused by the introduction of the generic `SocketValueVariant` type.
Now it's not enough to simply default-construct the value anymore, but it has
to be constructed with the correct type.
This allows modifiers to have cache pointers that are preserved over undo steps.
I intend to use this for the baked data cache for the geometry nodes modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/117307
The name `offset_in_ID` is very misleading since it does not have to be an offset at all,
it just has to be some unique value. Often it's also a hash or a constant value depending
on the use.
Pull Request: https://projects.blender.org/blender/blender/pulls/117306
Exceptions:
* Links to personal wiki pages
* Pages that are not in the new developer docs yet (like Human Interface Guidelines)
* tools\check_wiki\check_wiki_file_structure.py needs a refactor
When there is no default color attribute yet, when creating a new color
attribute with the store named attribute node, set the default. Though
we generally try to avoid this more magical behavior, there's little
downside in this case, and it's probably what users expect.
Don't set the active attribute though, since that's UI data that generally
shouldn't be changed procedurally. It's okay if there's no active color
attribute.
Pull Request: https://projects.blender.org/blender/blender/pulls/117249
The function for retrieving a shape key by its index is named
somewhat confusingly, and effectively reimplements BLI_findlink.
However, more importantly, for some reason it is coded to return
null for the index 0 instead of the basis shape key. This severely
limits its usability in some cases.
This refactor replaces the function with a simple strongly typed
wrapper around BLI_findlink, using a different name, and updating
the call sites to check that the index is not 0 where necessary.
The FPS menu was using a cached value which wasn't being refreshed
when translation changed.
Add `bpy.app.handlers.translation_update_post` handler which runs
when translation changes, this can be used to clear any cached UI
values.
Ref !117049
We don't actually protect against interface sockets with empty
names elsewhere. This assert was triggered when trying to group
a `Bake` node, because it tried to create an interface socket of
the extend socket. This case is handled by the check below.
This adds a cache to read a normal vector for a plane that (roughly) fits a curve.
If the curve lies on a plane, the vector always point along this plane normal, otherwise it's an approximation.
The cache is lazily calculated and invalidated when the positions are tagged for a change.