| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
there is no point in warning about files that are not supposed to be
'correct' in that regard.
|
|
Add a dedicated `owner_id` pointer to ID types that can be embedded
(Collections and NodeTrees), and modify slightly come code to make
handling those more safe and consistent.
This implements first part of T69169.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D15838
|
|
This is old code to keep track of an active search element, so you could
step through the search results. This isn't used anymore, and not needed
since searching now filters the tree to only show matches. If we ever
wanted to have support for stepping through elements again, that should be
done via the active element instead.
|
|
|
|
While this was not a critical issue (that lib pointer is only used for
some kind of sanity check that no linked data uses local ID pointers),
better to keep `IDP_BlendReadLib` in sync with all other lib-linking
code.
|
|
libmap.
New `oldnewmap_lib_insert` does nothing special, it just wraps around existing
`oldnewmap_insert`, but it's the logical counter part of `oldnewmap_liblookup`.
It also helps tremendously when debuging complex ID pointers issues in
readfile.c code.
|
|
Crash would happen when a linked ID would become missing, that was
'pre-declared' and used only once as a 'weak link' in another library
stored before the one it came from.
In that case, the place-holder generated in read code would be freed in
`read_library_clear_weak_links`, when handling its 'owner' library, but
since all previous libraries in the list had already been 'lib_linked'
and their filedata (and related libmap) freed, the update of the libmaps
in `read_library_clear_weak_links` would not apply to data from those
previous libraries, leading to ID pointers there pointing to freed
memory.
This fix should also be backported to 2.93.
|
|
|
|
Adds a "Pin Scene" option to the workspace. When activated, the workspace will
remember the scene that was last activated in it, so that when switching back
to this workspace, the same scene will be reactivated. This is important for a
VSE workflow, so that users can switch between different workspaces displaying
a scene and thus a timeline for a specific task.
The option can be found in the Properties, Workspace tab. D11890 additionally
adds an icon for this to the scene switcher in the topbar.
The workspace data contains a pointer to the scene which is a UI to scene data
relation. When appending a workspace, the pointer is cleared.
Differential Revision: https://developer.blender.org/D9140
Reviewed by: Brecht Van Lommel, Bastien Montagne (no final accept, but was fine
with the general design earlier)
|
|
Properly use CLOG to report info or errors in `writefile.c`, instead of
printf's.
And remove some assert when logging error reports and the issue is not
critical.
|
|
Replace some `if/else if` chains by proper `switch` statement.
Replace some `BLI_assert(0)` calls by `BLI_assert_unreachable()` ones.
|
|
GPU code used `sz` as an abbreviation for size, as well as a few other
places. Use size where this represents a size in bytes, see: T85728.
|
|
|
|
Also ensure space around text in C-comment blocks.
|
|
Original rework of caches during undo/redo (see D8183) had a very bad
flaw hidden in it: using the key of a ghash as source of data.
While this was effectively working then (cache pointer itself being part
of the key, and said cache pointers not being cleared on file write),
this is a general very bad way to do things.
Now that cache pointers are more and more cleared on file write (as part
of clearing runtime-data to reduce false-positives when checking if an
ID has changed or not), this has to be fixed properly by:
* Not storing the cache pointer itself in the IDCacheKey.
* In undo context, in readfile code trying to preserve caches, store the
cache pointers as values of the mapping, together with the usages counter
The first change potentially affects all usages of
`BKE_idtype_id_foreach_cache`, but in practice this code is only used by
memfile reading code (i.e. undo) currently.
Related to T97015.
Reviewed By: brecht
Maniphest Tasks: T97015
Differential Revision: https://developer.blender.org/D14559
|
|
|
|
|
|
Even though the size of the map was set back to DEFAULT_SIZE_EXP,
the underlying arrays were left unchained. In some cases this caused
further expansions to result in an unusual reallocation pattern
where MEM_reallocN would run expand the entries into an array
that was in fact the same size.
|
|
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
This change will make handling of liboverrides hierarchies (especially
resyncing) much easier and efficient. It should also make it more
resilient to 'degenerate' cases, and allow proper support of things like
parenting an override to another override of the same linked data (e.g.
a override character parented to another override of the same
character).
NOTE: this commit only implements minimal changes to add that data and
generate it for existing files on load. Actual refactor of resync code
to take advantage of this new info will happen separately.
|
|
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
|
|
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
|
|
This fixes a similar issue as the previous commit, but this time the
continuous notifiers would be sent after redoing. E.g. after moving an
object, and then modifying the transform in the "Adjust Last Operation"
panel.
|
|
|
|
Also add groups in some files.
|
|
Use "filepath" which is the current convention for naming full paths.
- Main use "name" which isn't obviously a file path.
- BlendFileData & FileGlobal used "filename" which is often
used for the name component of a path (without the directory).
|
|
Ref T92709
|
|
Instantiation is now fully handled by BKE_blendfile_link_append module.
Note that this also allows removal of the `BLO_LIBLINK_NEEDS_ID_TAG_DOIT`
flag.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
|
|
Rewrite of ID paste code in rB3f08488244c0 made this function useless,
ID pasting is now handled by the BKE_blendfile_link_append module too.
|
|
Ref D13053
|
|
The drag and drop feature of objects in 3D View has been modified to include:
- Snap the object being dragged.
- Visual feedback through a box and the placement tool grid.
Maniphest Tasks: T90198
Differential Revision: https://developer.blender.org/D12912
|
|
Appended objects could be hidden, making any further operations
potentially skip the newly added objects.
Now FILE_AUTOSELECT asserts when newly added options aren't selectable.
|
|
De-duplicates wm_append_loose_data_instantiate_object_base_instance_init
and object_base_instance_init.
Add BLO_object_instantiate_object_base_instance_init which also adds to
a collection since all callers did this.
|
|
|
|
|
|
Some runtime data that stores which sockets can be fields and which
can't is not stored in the file, but only calculated when necessary.
When opening a file, the node tree update function was called, which
recalculated this data, but that was explicily turned off for undo.
This exposes a fundamental issue with undo, the ID caching system for
undo, and how it relates to node trees in particular. Ideally this call
couldn't be necessary at all. In the future it could be removed by
adding a runtime struct to node trees, and calculating its contents
on-demand instead of preemtively.
Differential Revision: https://developer.blender.org/D12699
|
|
Just a matter of calling `BKE_lib_override_library_main_update` in
`library_link_end`.
|
|
Copy/Paste uses its own code path for ID linking, which was not setting
`LIB_TAG_DOIT` for proper instantiation later on.
Would be nice the make this logic closer to the rest of the link/append
code at some point, but for now this fix will do.
|
|
No idea why this was done that way (it originate from initial paste
commit, rB12b642062c6f).
But the IDs 'selected' as direct paste in `BLO_library_link_copypaste`
should be 'directly' linked, it's similar case to actual append of
selected IDs by the user.
Related to T87189.
|
|
collection.
Related to T87189.
|
|
Flags controlling link/append code are split between two enums, one in
`DNA_space_types.h` and one in `BLO_readfile.h`.
This commit:
- Moves flags exclusively used in WM and BLO code to `eBLOLibLinkFlags`
in `BLO_readfile.h`. Flags in `eFileSel_Params_Flag` from
`DNA_space_types.h` are now only the ones effectively used by the
file browser editor code too.
- Fixes some internal utils in `readfile.c` still taking `short` flag
parameter instead of proper `int` one.
NOTE: there are a few other flags that could probably be moved to
`eBLOLibLinkFlags` (at the very least `FILE_LINK`, probably also
`FILE_AUTOSELECT` and `FILE_ACTIVE_COLLECTION`), since those are not
effectively used by the file browser, and control linking/appending
behavior, not filebrowser behavior.
However for now think it's safer to not touch that.
|
|
This commit adds to ID struct a new optional 'weak reference' to a
linked ID (in the form of a blend file library path and full ID name).
This can then be used on next append to try to find a matching local ID
instead of re-making the linked data local again.
Ref. T90545
NOTE: ID re-use will be disabled for regular append for the time being
(3.0 release), and only used for assets. Therefore, this commit should
not change anything user-wise.
Differential Revision: https://developer.blender.org/D12545
|
|
by linked/appended data.
Do not instantiate obdata when it is not actually loose.
|
|
|
|
|
|
We now use a for_each function with callback to iterate through all sequences in the scene.
This has the benefit that we now only loop over the sequences in the scene once.
Before we would loop over them twice and allocate memory to store temporary data.
The allocation of temporary data lead to unintentional memory leaks if the code used returns to exit out of the iteration loop.
The new for_each callback method doesn't allocate any temporary data and only iterates though all sequences once.
Reviewed By: Richard Antalik, Bastien Montagne
Differential Revision: http://developer.blender.org/D12278
|
|
Compressing blendfiles can help save a lot of disk space, but the slowdown
while loading and saving is a major annoyance.
Currently Blender uses Zlib (aka gzip aka Deflate) for compression, but there
are now several more modern algorithms that outperform it in every way.
In this patch, I decided for Zstandard aka Zstd for several reasons:
- It is widely supported, both in other programs and libraries as well as in
general-purpose compression utilities on Unix
- It is extremely flexible - spanning several orders of magnitude of
compression speeds depending on the level setting.
- It is pretty much on the Pareto frontier for all of its configurations
(meaning that no other algorithm is both faster and more efficient).
One downside of course is that older versions of Blender will not be able to
read these files, but one can always just re-save them without compression or
decompress the file manually with an external tool.
The implementation here saves additional metadata into the compressed file in
order to allow for efficient seeking when loading. This is standard-compliant
and will be ignored by other tools that support Zstd.
If the metadata is not present (e.g. because you manually compressed a .blend
file with another tool), Blender will fall back to sequential reading.
Saving is multithreaded to improve performance. Loading is currently not
multithreaded since it's not easy to predict the access patterns of the
loading code when seeking is supported.
In the future, we might want to look into making this more predictable or
disabling seeking for the main .blend file, which would then allow for
multiple background threads that decompress data ahead of time.
The compression level was chosen to get sizes comparable to previous versions
at much higher speeds. In the future, this could be exposed as an option.
Reviewed By: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D5799
|
