Add the 'solo' flag to bone collections, effectively adding another
layer of visibility controls.
If there is _any_ bone collection with this flag enabled, only this
collection (and others with this flag enabled) will be visible.
In RNA, the following properties are exposed:
- `bone_collection.is_solo`: writable property to manage the solo flag.
- `armature.is_solo_active`: read-only property that is `True` when any
bone collection has `is_solo = True`.
The RNA property `bone_collection.is_visible_effectively` now also takes
the solo flag into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/117414
Rename `BoneCollection::is_visible_effectively()` to
`is_visible_with_ancestors()`. Soon a "solo" flag will be introduced,
and the effective visibility of the bone collection will depend on that
too. This particular function doesn't take that into account, though,
and thus needs a rename.
Note that this does NOT rename the RNA property
`is_visible_effectively`. That will be updated when the "solo" flag is
introduced to also take that into account.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/117414
Boolean ID property support was added in ef68a37e5d, but the JSON
serializer for ID properties was not updated for it. This would be a
forward compatibility issue, if future json files containing boolean
properties would be read with old versions. Such properties are added
in #106303, for example.
The CPU implementation had the following downsides:
- The kernels sizes below 3 did not make much sense, often leading
to a full white image.
- The way how the total number of pixels in the kernel was calculated
quite strangely.
From these points of view the GPU compositor behaves more user friendly.
There is a versioning code which lowers the kernel size, to match the
result prior to these tweaks.
Pull Request: https://projects.blender.org/blender/blender/pulls/117505
There exist a bunch of "give me a (filtered) image pixel at this location"
functions, some with duplicated functionality, some with almost the same but
not quite, some that look similar but behave slightly differently, etc.
Some of them were in BLI, some were in ImBuf.
This commit tries to improve the situation by:
* Adding low level interpolation functions to `BLI_math_interp.hh`
- With documentation on their behavior,
- And with more unit tests.
* At `ImBuf` level, there are only convenience inline wrappers to the above BLI
functions (split off into a separate header `IMB_interp.hh`). However, since
these wrappers are inline, some things get a tiny bit faster as a side
effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X):
- Nearest filter: 2.33 -> 1.94ms
- Bilinear filter: 5.83 -> 5.69ms
- Subsampled3x3 filter: 28.6 -> 22.4ms
Details on the functions:
- All of them have `_byte` and `_fl` suffixes.
- They exist in 4-channel byte (uchar4) and float (float4), as well as
explicitly passed amount of channels for other float images.
- New functions in BLI `blender::math` namespace:
- `interpolate_nearest`
- `interpolate_bilinear`
- `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function,
this one no longer requires the caller to do their own wrapping.
- `interpolate_cubic_bspline`. Previous similar function was called just
"bicubic" which could mean many different things.
- Same functions exist in `IMB_interp.hh`, they are just convenience that takes
ImBuf and uses data pointer, width, height from that.
Other bits:
- Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf`
and `floored_modulo` that exist elsewhere), made it branchless and added more
unit tests.
- `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead,
moved the clamp to be outside of the call in `paint_image_proj.cc` and
`paint_utils.cc`. Though the need for clamping in there is also questionable.
Pull Request: https://projects.blender.org/blender/blender/pulls/117387
Broken from 72ab6faf5d
Because the `IMA_GEN_TILE` flag was not cleared during the memory pack,
the tile was regenerated on reloading. Mimic what is done during save
and clear the flag if all tiles pack successfully.
Pull Request: https://projects.blender.org/blender/blender/pulls/117472
Cycles can use a per face flag to determine if a face is smooth or flat,
and there is no need to use corner normals in such cases. So revert to
not doing that as before, which also saves a bit of memory.
There is a pre-existing issue where faces are split by sharp edges and
autosmooth, which is not solved by this. It's only fixing the regression.
This simplifies code using these functions because of RAII,
range based for loops, and the lack of output arguments.
Also pass object pointer array as a span in more cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/117482
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
