| Age | Commit message (Collapse) | Author |
|---|
|
Two issues addressed here:
I) `asset_type_info` is sub-data, not a callback. Therefore, move it
before the callbacks in the `IDTypeInfo` struct.
II) More important, initialize this new attribute in *ALL* `IDTypeInfo`
instances. No member of this struct should ever be left implicitely
uninitilazed, ever.
Aftermath of rBa84f1c02d251.
|
|
to C++.
rB6002914f141f totally lost those info, in C++ we use comments by
convention.
|
|
|
|
The problem was that we forgot to actually remove the vertex group when
it should be deleted. We only removed all the data that was attached to it.
Differential Revision: https://developer.blender.org/D13326
|
|
|
|
Add an operator "Copy to Asset Library" for installing asset bundles
into already-existing asset libraries.
The operator is shown when:
- the "Current File" library is selected,
- the blend file name matches `*_bundle.blend`, and
- the file is not already located in an asset library.
The user can select a target asset library, then gets a "Save As"
dialogue box to select where in that library the file should be saved.
This allows for renaming, saving in a subdirectory, etc.
The Asset Catalogs from the asset bundle are merged into the target
asset library.
The operator will refuse to run when external files are referenced. This
is not done in its poll function, as it's quite an extensive operator
(it loops over all ID datablocks).
Reviewed by: Severin
Differential Revision: https://developer.blender.org/D13312
|
|
context items.
Will be required for python's `bpy.data.libraries.load()` refactor.
|
|
This enables calling code to deal with the blendfile handle themselves,
BKE_blendfile_link then just borrows, uses this handle and does not
release it.
Needed e.g. for python's libcontext system to use new
BKE_blendfile_link_append code.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
|
|
|
|
This enables calling code to deal with the blendfile handle themselves,
BKE_blendfile_link then just borrows, uses this handle and does not
release it.
Needed e.g. for python's libcontext system to use new
BKE_blendfile_link_append code.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
|
|
|
|
This was broken by rB0c3b215e7d5456878b155d13440864f49ad1f230.
The caching of loaded exr files needed some special treatment.
Differential Revision: https://developer.blender.org/D13313
|
|
There was a missing normals layer that was requested by the data transfer
modifier from the target object. The normal layer was correctly added to
the target object. However, it never reached the data transfer modifier
because the mesh was copied in `BKE_object_get_evaluated_mesh`
(in the call to `get_mesh_for_write`) and the copy does not include the normals
layer.
The solution is to not use `get_mesh_for_write` here which was only used
because `BKE_object_get_evaluated_mesh` returns a non-const `Mesh *`.
Mid term, it should actually return a `const Mesh *` to avoid the confusion.
Differential Revision: https://developer.blender.org/D13319
|
|
|
|
Mistake in e7bea3fb6ed0.
We should only skip preview generation for objects that don't support
preview rendering, not completely forbid accessing preview data of such
IDs.
|
|
Add the following methods to the CurveEval class:
total_length() : returns the total length of the curve without needing to
allocate a new array
total_control_point_size() : returns the total number of control points without
needing to allocate a new array
|
|
This allows to reduce signature of several functions, and make it eaiser
to integrate more higher-level usages later on.
This should be a non-behavioral-change commit.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
|
|
in BKE.
This removes the last main usage of BLO's instantiation code.
Also required some limited refactoring of BKE_blendfile_link_append's
instantiation to make it more modular, and usable by both linking and
appending code paths.
NOTE: This should be a non-behavioral change commit.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
|
|
`BKE_blendflie_link_append` module.
This will allow to expose all those advanced features of the WM
operators to other parts of the code, like the python library context
manager, copy/paste code, etc.
This is expected to be a strictly no-behavioral-change commit.
Part of T91414: Unify link/append between WM operators and BPY context
manager API, and cleanup usages of `BKE_library_make_local`.
Maniphest Tasks: T91414
Differential Revision: https://developer.blender.org/D13222
|
|
|
|
This really doesn't have to be a callback currently, since it is always
the same `CPPType` for a socket type.
|
|
Adds an attribute provider for instance attributes.
A new domain `ATTR_DOMAIN_INSTANCE` is implemented.
Instance attributes are not yet realized correctly.
Differential Revision: D13149
|
|
|
|
Conflicts:
source/blender/blenkernel/BKE_blender_version.h
source/blender/blenloader/intern/versioning_300.c
|
|
Asset libraries should be directories on disk. By manually entering a
file path it was possible to have a single blend file as asset library,
but that was not a designed-for situation, and it doesn't play well
with the asset catalog system.
|
|
|
|
Original implementation was a quick prototype which should have never
landed as-is in master. It had very limiting constraints and did not
allow for any real further development.
This commit fixes the internal implementation to make more sensible,
maintainable and evolutive.
NOTE: This commit introduces another forward-incompatibility in the
Blender file format: Files saved after this commit won't open properly
in older versions of blender regarding local inserted constraints or
modifiers into overrides of linked data.
NOTE: Technical details: The 'anchor' item name/index is now stored in
`subitem_reference_` members, and the actual 'source' item name/index is
stored in `subitem_local_` members of the override property operation
data.
Previously, only the `subitem_local_` members were used, storing the
anchor item name/index, and assuming the 'source' item was always the
next in the list.
Milestone I of T82160.
Maniphest Tasks: T82160
Differential Revision: https://developer.blender.org/D13282
|
|
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
All constraints were 'made local', including the ones comming from the
reference linked object.
|
|
|
|
The Cycles accurate mode was removed, but the Eevee option for this has
a different meaning and should not have been removed. The Eevee accurate
makes cryptomatte accumulate for every sample, which Cycles has always
done regardless of any option.
|
|
Differential Revision: https://developer.blender.org/D13271
|
|
Previously, node types had a callback that creates internal links. Pretty
much all nodes used the same callback though. The exceptions are the
reroute node (which probably shouldn't be mutable anyway) and some
input/output nodes that are not mutable.
Removing the callback helps with D13246, because it makes it easier
to reason about which internal links are created and when they change.
In the future, the internal links should be part of the node declaration.
|
|
This cleans up part of the code that still set the flag manually. Also, this
change helps with D13246 because it makes it easier to tag the node
tree as changed when the availability of a socket changed.
|
|
This seems to be oversight in 271231f58ee3 where strip color was
defined only for light theme.
|
|
|
|
|
|
|
|
The spline code, especially Bezier splines, often make use of lazily
evaluation and caching. In order to do that, they use mutex locks.
When multi-threading, this can lead to problems. Further detail
can be found in rBfcc844f8fbd0d1.
To fix the deadlock, isolate the task before multi-threading
when holding a lock.
Differential Revision: https://developer.blender.org/D13229
|
|
|
|
Fix a crash when a hair system's `ParticleSettings` ID datablock was
linked from another file but couldn't be found. This results in default
settings, with `type = PART_EMITTER`, where the particle data still has
a non-NULL `hair` pointer. Previously, copies of such a particle system
would NOT copy hair data for non-hair particle systems, hence the
pointer of the copy pointed to the original data, which got freed (at
least) twice upon closing the blend file.
This is now fixed by always copying the hair data, regardless of the
particle system type.
Reviewed by: mont29
Differential Revision: https://developer.blender.org/D13245
|
|
|
|
Dispose of GHOST system paths when tearing down `BlendfileLoadingBaseTest`
and some other test cases. This prevents a memory leak.
A better solution would be to rework Blender's initialisation & teardown
structure, but that's outside the scope of this fix.
No functional changes to Blender.
|
|
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
|
|
|
|
|
|
When proxy size lower than 100% is used, clip strips are rendered with
incorrect image size.
This is because if proxies aren't enabled in movieclip, it automatically
falls back on rendering original media. Sequencer doesn't have knowledge
about this and since 9c99292a16df it assumes that image is proxy,
because it explicitly requested this size.
Check movieclip flag to see if proxies are enabled.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D13080
|
|
Those functions were more useful when `FieldInferencingInterface`
was still declared further down in `node.cc`.
|
|
|
