The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136134
The operator refused to pack libraries with absolute paths (wasnt the
case in its original implementation 16411da41e, but was added in
129fb516f4 -- for the reason of preventing "bad things happen on
unpacking" without an explanation of what these exactly are). It did so
by cancelling as soon as **one** library with ab absolute path was
found.
Now with the introduction of essential assets, we have those absolute
path linkages more or less "by default" as soon as e.g. a brush is
used, so the operator is more or less unusable now. NOTE: these absolute
essential asset library paths seem to be converted to relative on save?
Upon reload, these are then gone... (might be another hint for an
alternative fix, see below)
By "bad things happen on unpacking" I would assume the scenario of
folders being created in unwanted locations (e.g. when moving from one
OS to another), but the same thing is also true for packing **files**
instead of libraries (there, absolute paths are allowed, and unpacking
in original locations can equally fail or create folder structures that
are "unexpected"). NOTE: for files though we have the choice of
unpacking to a relative folder (which wouldnt really be possible since
libraries can be nested and we would have to correct paths all over the
place). NOTE: the chance of creating "unwanted" folder structures with
relative paths might be slimmer, but if you have a lot of "upwards"
parent folders, relative can easily "break" as well.
Possible ways to resolve this:
### [1] skip libraries identified as essentials assets (still cancel on all other absolute paths)
Can check a library path to be contained in `EssentialsAssetLibrary`
`essentials_directory_path`. This would be the safest imo since it is a no-behavior change.
### [2] lift the limitation of absolute paths alltogether
Like mentioned above, things could break with "relative" almost as
easily as with "absolute", there might even be scenarios where
"absolute" is wanted. It is a more behavior-changing fix that we might
explore more after 4.4 is out.
### [3] skip absolute libraries (but continue with non-absolute libraries)
This does change behavior as well (it does not cancel as soon as **one**
library with ab absolute path was found anymore, but the worst case
scenario is that you end up with an "incomplete" file if you really
mixed absolute and realtive lib linking).
This PR implements [1] for now, [2] or [3] can follow for 4.5.
Fixes#134665
Pull Request: https://projects.blender.org/blender/blender/pulls/134839
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
Previously, it was only possible to bake to disk with geometry nodes. This patch
adds support for storing the baked data directly in the .blend file.
By default, new bakes are stored in the .blend file now. Whether a new bake
should be packed or stored on disk can be configured in two places: in the
properties of the bake node and in the bake panel of the modifier. These
settings don't affect existing bakes, only the next bake.
To unpack or pack an individual bake, there is a new operator button next to the
bake button. The icon and the label below indicate where the bake is currently
stored. The label now also contains the size of the bake.
To unpack or pack all bakes, the `File > External Data > Pack Resources / Unpack
Resources` operators can be used. The unpack operator also has a new title that
mentions the number if individual files separate from the number of bakes. This
works better than just listing a number of files because a bake can consist of
many files.
Pull Request: https://projects.blender.org/blender/blender/pulls/124230
Over the year, changes in how image packedfiles were handled broke the
fallback case of missing packed data in a few places, this commit fixes
proper cleanup of invalid packed files in the Image's list of
packedfiles.
In addition, also do not create inplicit sharing info when the read data
is `nullptr`.
All of these changes should be trivial, like using `string` read/write
code for strings, and a convert a few usages of 'raw data' read/write
calls to the 'struct' ones.
No behavioral changes expected here.
I found that `packedmap` is effectively unused when I worked on #123243.
The only function that wrote to it was `blo_make_packed_pointer_map`
and that is never called. Packed data already used the normal `datamap` as fallback.
Pull Request: https://projects.blender.org/blender/blender/pulls/123244
These remain linked, so data remains to be read/loaded from the packed
version from the library (making this a useless and wasteful
duplication, also changes could be perceived as lost). Tooltip was also
reading "Unpack all files packed **into this .blend** to external ones",
so that bring it in line with the tooltip.
This came up in #122033
Pull Request: https://projects.blender.org/blender/blender/pulls/122092
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Accessing the file size returns -1 on error, for file packing this
was passed directly to an allocation which would wrap around to
SIZE_T_MAX and fail to allocate. In other cases zero was treated
as an error value but -1 wasn't.
Add checks for the error return value, also warn that packing files over
2gb isn't supported.
Also see #103343.
Couldn't move two files yet:
* `softbody.c`: The corresponding regression test fails. It seems like the
conversion to C++ changes floating point accuracy, but it's not clear where that happens exactly.
* `writeffmpeg.c`: Is a bit more complex to convert because of the static array in `av_err2str`.
Pull Request: https://projects.blender.org/blender/blender/pulls/110182
