- Skip leading slash from drive letters.
- Use back-slashes.
While these weren't exactly bugs, it seemed like an error when the
path name wasn't what users would expect. Relates to #123994.
This commit introduces a new `PartialWriteContext` class, which wraps
around a regular Main struct. It is designed to make writing a set of
IDs easy and safe, and to prepare for future 'asset library editing'
low-level code.
The main goal of this refactor is to provide the same functionalities
(or better ones) than existing partial write code, without the very
bad hacks currently done.
It will replace within the coming weeks all current usages of the
`BKE_blendfile_write_partial` API.
Essentially, it allows to:
* Add (aka copy) IDs from the G_MAIN to the partial write context.
* This process handles dependencies and libraries automatically.
* A refined handling of dependencies is possible through an optional
'filtering' callback.
* Keep track of added IDs, to allow de-duplication in case data is added
more than once.
* Cleanup the context (i.e. remove unused IDs).
* Write the context to disk as a blendfile.
Since the context keeps information to find matches between its content
and IDs from the G_MAIN, its lifespan is expected to be _very_ short.
Otherwise, changes in G_MAIN (relationships between IDs, their session uid,
etc.) cannot be tracked by the context, leading to inconsistencies.
A partial write context should typically be created, filled, written and
deleted within a same function.
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
Also make ID pointer parameter passed to `BKE_main_idmap_remove_id`
const.
There is no behavioral changes expected from that commit.
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
This commit allows to initialize and clear a Main struct which
allocation is handled separately.
There is no behavioral change expected from this commit.
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
The new `LIB_ID_MAKELOCAL_INDIRECT` option will force indirectly linked
data to also be made local. Note that this was already the case when a
whole library was made local.
Also some cleanup of options for 'make local', and pass
`IDWALK_IGNORE_MISSING_OWNER_ID` to the ID copying code for ID
management, since typically the owner pointer of embedded IDs at that
point is not yet set to its valid value.
There is no behavioral changes expected from this commit (even though
technically it does affect existing ID copying's behavior, there should
be no change in practice).
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
Avoid looping over all F-Curves in `bke::action_foreach_id()`. This was
only necessary to support the possible ID* in custom properties on the
Python F-Curve modifier, but that modifier has been removed in the
preceeding commit.
Even though `BKE_fcurve_foreach_id()` exists, it is only relevant for
drivers, but the F-Curves stored in an Action are always just animation
data, not drivers.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Remove all traces in the source code of the never-properly-implemented
'Python' F-Curve modifier type. It was introduced in 44e5b7788b.
This modifier was never coded to completion, couldn't be created, didn't
have a GUI, and probably would have caused severe performance issues if
it were ever implemented.
Not only that, but the modifier had space for custom properties
(IDProperties), which means that it could point to any ID. This in turn
means that `bke::action_foreach_id()` would have to loop over every
F-Curve and every F-Curve modifier to handle such relations. By removing
this modifier type, that loop can also be removed from that function.
Note that F-Curves can only refer to other IDs when they are used as a
driver. However, the F-Curves stored in an Action as animation data are
never drivers.
`BKE_fcurve_foreach_id()` is now only relevant when the F-Curve is a
driver, which I've added to its documentation.
The enum entry `FMODIFIER_TYPE_FILTER` in `DNA_anim_types.h` is kept, so
that it's clear that this once existed (which explains what would
otherwise be a hole in the values of the enum entries).
No functional changes should be observable by Blender users, as this
feature doesn't seem to have ever existed in a way that could be used.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Instead of using hard-coded array indices that happen to match the
`FMODIFIER_TYPE_...` enum values, actually use the enum items.
Also add some assertions that those indices actually match the type
numbers declared by the `FModifierTypeInfo` structs.
To avoid rewrapping long lines, remove comments that basically repeat
the code anyway.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
The code which is responsible for applying data from coordinate grids to
displacement grids could be run as part of modifier evaluation, hence
using the safe version of accessing mesh data was returning a nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/123907
Remove the `pbvh_colors.cc` file, since dealing with color attributes should
generally not be the responsibility of the PBVH. Move the color API functions
to the `color` namespace, replacing the two existing `SCULPT_color`
functions. Also replace `SCULPT_has_colors` and `SCULPT_has_loop_colors`
which are redundant with checking the easily accessible attributes directly.
Remove `PBVH::color_layer`, `PBVH::color_domain`, and remove `vcol`, `mcol`,
`vcol_domain`, and `vcol_type` from `SculptSession`. Instead, retrieve attributes
and other arrays from the mesh as necessary and pass them around separately.
This adds more arguments to some functions but it makes their responsibilities
clearer.
Part of #118145.
Use vertex indices instead of `PBVHVertRef`. This doesn't lose functionality
because color attribute painting is only supported for base meshes anyway.
The next steps are refactoring the code to have the same structure as the
new brushes and using the same methods to add code paths for the other
data structures.
Keep track of which IDs are animated by which Action Binding. This will
be necessary for display in the Action editor, where animation data that
is unrelated to the active object can be shown (when "show all bindings"
is on).
Note: animation evaluation will not be using this cache, at least not in
the near future. Potentially when we introduce animation-level
constraints this will change, but that's for the future.
The user cache isn't actually used in this commit. It will be used soon
in !122672.
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
Add a function to get the `Main *bmain` pointer from a
LibraryForeachIDData struct. Since the struct is opaque to the
`..._foreach_id` functions, a separate function like this is necessary
to get that pointer.
Not used yet, but will be in a followup commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
Pass a non-`nullptr` `bmain` to `BKE_library_foreach_ID_link()` wherever
that `bmain` is known at the call site. This will be used in a followup
commit.
This should not introduce any functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
This was the case when the slot index in the active object is greater
than the available slots of other selected objects.
Code was trying to avoid searching all materials by using
`BKE_object_material_get` to get an appropriate index (an addition to
D4441 added in 6b39dc7672). That function has the behavior of clamping
if a target index is greater than the available slots (for good
reasons), so we cant rely on the slot index being the same if
`BKE_object_material_get` finds a material. So in essence, this is not
what we want to use in this case.
Now use the much simpler `BKE_object_material_index_get` to get the
index [this might be less performant in certain scenarios, dont think
this is critical though and correctness should beat performance here]
Pull Request: https://projects.blender.org/blender/blender/pulls/123718
This implements a von-Kries-style chromatic adaption using the Bradford matrix.
The adaption is performed in scene linear space in the OCIO GLSL shader, with
the matrix being computed on the host.
The parameters specify the white point of the input, which is to be mapped to
the white point of the scene linear space. The main parameter is temperature,
specified in Kelvin, which defines the blackbody spectrum that is used as the
input white point. Additionally, a tint parameter can be used to shift the
white point away from pure blackbody spectra (e.g. to match a D illuminant).
The defaults are set to match D65 so there is no immediate color shift when
enabling the option. Tint = 10 is needed since the D-series illuminants aren't
perfect blackbody emitters.
As an alternative to manually specifying the values, there's also a color
picker. When a color is selected, temperature and tint are set such that this
color ends up being balanced to white.
This only works if the color is close enough to a blackbody emitter -
specifically, for tint values within +-150. Beyond this, there can be ambiguity
in the representation.
Currently, in this case, the input is just ignored and temperature/tint aren't
changed. Ideally, we'd eventually give UI feedback for this.
Presets are supported, and all the CIE standard illuminants are included.
One part that I'm not quite happy with is that the tint parameter starts to
give weird results at moderate values when the temperature is low.
The reason for this can be seen here:
https://commons.wikimedia.org/wiki/File:Planckian-locus.png
Tint is moving along the isotherm lines (with the plot corresponding to +-150),
but below 4000K some of that range is outside of the gamut. Not much can
be done there, other than possibly clipping those values...
Adding support for this to the compositor should be quite easy and is planned
as a next step.
Pull Request: https://projects.blender.org/blender/blender/pulls/123278
The `create_liquid_geometry` still used the older attributes
API to write the velocities.
This replaces the use of `BKE_attribute_new` with
the newer attribute API.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123854
It is possible that the file does not have Grease Pencil paint
yet, leading to a crash in the BKE_paint_init().
The simple fix is to swap the order of acquiring the paint
pointer and the code which ensures that this paint exists.
This reverts commit cb76781be7, and fixes
the issues from original da05bff96c commit (missing initialization
of a pointer in copy constructor in some cases, and forgot to handle
one allocated string in the move constructor).
Many thanks to @julianeisel for finding the actual issues here.
This one was a bit more involved than the previous ones, since the
mismatch was intentional here, and happened on a non-trivial type.
It was done because the new object (managed by the `unique_ptr`) steals
the internal data of the original object. Calling `MEM_delete` (and
therefore the destructor of the `AssetMetaData` object) would then lead
to access-after-free and double-freeing errors.
This is addressed by adding two new 'copy' and 'move' constructors to this type.
The copy one ensures that deep-copy of internal data happens as expected, and
allows to simplify greatly the code in `BKE_asset_metadata_copy`, which
becomes a mere wrapper around it.
The move one allows `make_unique` to properly steal (and clear) the internal
data of the source object, which can then safely be deleted.
Pull Request: https://projects.blender.org/blender/blender/pulls/123693
Part of #118145.
Rewrite the application of brush hardness, filtering for 3D view clipping
and brush distance factor calculation to operate on arrays of data rather
than a single element at a time.
In the benchmark file from the task above, this improves performance by
5%, from 0.58s to 0.55s. I expect that's mainly because constant checks
have been moved out of the hot loops, avoiding function call overhead,
and because in some cases we avoid doing division for every element.
Pull Request: https://projects.blender.org/blender/blender/pulls/123671
The function `CurvesGeometry::offsets()` would return a span pointing to
`nullptr` with a size of `1` if there were no curves in the geometry.
This was already changed for `offsets_for_write()` in
c3365666e5, which retuns an empty span.
Do the same for `offsets()` now.
Pull Request: https://projects.blender.org/blender/blender/pulls/123772
Provide a convenient way to access a writable directory for extensions.
This will typically be accessed via:
bpy.utils.extension_path_user(__package__, create=True)
This API is provided as some extensions on extensions.blender.org
are writing into the extensions own directory which is error prone:
- The extensions own directory is removed when upgrading.
- Users may not have write access to the extensions directory,
especially with "System" repositories which may be on shared network
drives for example.
These directories are only removed when:
- Uninstalling the extension.
- Removing the repository and its files.
When removing a repository & files a valid module name was assumed.
While this should always be the case, add an additional check so in
the unlikely event of memory/file corruption (especially `..`)
recursively removing files outside the repository is never allowed.
The value was set and transfered to `MeshBatchCache`but never
actually used. Even then, this is clearly not a good solution to the
problem the comments mentioned. If that happens if would be
better to solve it in a different way.
