For text objects, current code will use another font if you ask for
a character that is not found in the selected font. But what if the
selected font is invalid? This can happen with a saved Blend that uses
a non-packed font that is since deleted. Current behavior will show
nothing. This PR restores earlier behavior where we use the built-in
font in this case. This does not make any changes to error reporting.
Pull Request: https://projects.blender.org/blender/blender/pulls/124184
Regression from fb8bf8b0c8: Now that the 'automatic override'
relationships between IDs are much more strict, re-creating
sub-hierarchies of overrides as part of the partial resync may not be
able to 'find' all previously used overrides anymore. An additional
remapping from linked (reference) data to existing, unchanged 'old'
overrides is needed.
In the report case, the root of the partial resync is the Curve obdata
itself, which will imply resync of its material. But the Armature object
used as dependency of the material (through the driver target) has
already been checked as not needing resync, so it is not included as
part of this partial resync sub-hierarchy anymore.
However, it means that the newly resync material override will have a
pointer to the linked armature object, which then needs to be remapped
to the matching existing (unchanged) override.
NOTE: this likely means that too many override IDs are still being
resynced currently. In the report-s case e.g., the Material ID likely
does not need to be resynced either.
- Do not translate a label containing the name of the active NLA
action.
- Translate default action name when created by inserting a keyframe.
- Translate "<NoAction>" and other default NLA strip names.
- Translate "<NoAction>" displayed in the UI when no action exists in
the NLA.
- Translate the temporary meta-strip created when moving an NLA strip
around. This uses DATA_() for consistency, even though it is not
really user data.
Issues reported by Gabriel Gazzán.
Pull Request: https://projects.blender.org/blender/blender/pulls/124113
This patch supports the Cryptomatte picker in the 3D viewport. Instead
of picking a color from the viewport GPU texture, we instead sample the
scene directly to get the object or material under the cursor, then hash
their names to get the Cryptomatte hash value. We do this because the
viewport texture have limited precision, so it can't store the
Cryptomatte hash values.
Additionally, we adjust the Cryptomatte session code to extract the
Cryptomatte manifest from the scene directly, as opposed to the
RenderResult. This is done to make it work even when no RenderResult
exist, as is the case for the viewport compositor, which is needed
especially after #123378.
Pull Request: https://projects.blender.org/blender/blender/pulls/123815
For text objects, current code will use another font if you ask for
a character that is not found in the selected font. But what if the
selected font is invalid? This can happen with a saved Blend that uses
a non-packed font that is since deleted. Current behavior will show
nothing. This PR restores earlier behavior where we use the built-in
font in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/122851
- 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.
Setting this option to a value above zero replaces the lambertian Diffuse term
with the modified energy-preserving Oren-Nayar BSDF, which matches the OpenPBR
behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/123616
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.
This patch adds two theme entries for data before/after the current frame.
Those entries control what color to use when displaying
reference data from a different point in time (motion path, onion skins).
They are under the `3D Viewport` section of the theme in the user preferences.
## User Facing Changes
### Grease Pencil
When `Custom Colors` is disabled it will now use the theme instead of the layer default color.
Currently this setting is enabled by default. Disable it to get Blender to use the theme.
### Motion Path
If Custom Color is disabled, read from the Theme.
### Annotations
If onion skin is enabled, and custom onion skin colors is disabled, read from the theme.
**Grease Pencil**
* previously the color used for onion skinning (without custom colors) was `U.gpencil_new_layer_col`. This is used in other places as well so it cannot be removed with this PR
* By default, custom colors are enabled with Grease Pencil objects. I specifically did **not** change that with this PR. I will instead let the GP module handle that on their terms.
This PR has been discussed in the Grease Pencil module meeting
https://devtalk.blender.org/t/2024-05-21-grease-pencil-module-meeting/34755#meeting-notes-2
and in the A&R module meeting
https://devtalk.blender.org/t/2024-05-24-animation-rigging-module-meeting/34813#patches-review-decision-time-4
Pull Request: https://projects.blender.org/blender/blender/pulls/120558
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
