The `resolution` and `nurbs_order` attributes of curves are expected to be `>=
1`. Due to a bug, it was possible that they are initialized to zero: #124534.
This fix adds versioning code to fix the curves that have been written
incorrectly.
Pull Request: https://projects.blender.org/blender/blender/pulls/124539
Unlike most versioning helper functions, version_mesh_crease_generic
takes care of all meshes in the blend file. However, the versioning
code was looping over all meshes and calling it for each one anyways.
This doesn't do anything after the first iteration, but it results
in quadratic time complexity w.r.t. number of meshes and manages to
waste e.g. 600ms when loading the Spring benchmark file.
The call to `GHOST_DisposeSystemPaths` was done in `WM_exit_ex` and
_some_ of the tests' 'teardown'. But some more where missing. Issue was
only reproducible when defining `WITH_CXX_GUARDEDALLOC` cmake option.
There are several layers of issues here, this commit addresses the
first, simplest one: since `BKE_appdir` API will indirectly create the
GHOST SystemPaths data, it is simpler and more logical to move the
deletion of this SystemPaths data in `BKE_appdir_exit()`. This avoids
exposing a fairly low-level implementation detail all over our codebase.
Further more, `WM_init` also does not need to explicitely call
`GHOST_CreateSystemPaths`, since it will be created automatically when
required.
Even if Cycles is not the active render engine, this
versioning code could affect Cycles if a material was
used with Cylces in another file (using linking).
Fix this by spliting the output node into another one
that only affects EEVEE.
Also see 06be295946.
These aren't all cases, but a few that I found by addding a static
assert in `MEM_new` so that it fails for trivially constructible types.
This is the main merge commit of the brush assets project. The previous
commits did some preparing changes, more tweaks are in the following commits.
Also, a lot of the more general work was already merged into the main branch
over the last two years.
With the new design, quite some things can be removed/replaced:
- There's a unified "Brush" tool now, brush based tools and all special
handling is removed.
- Old tool and brush icons are unsed now, and their initialization code
removed here. That means they draw as blank now, and the icon files can be
removed in a follow up.
- Creation of default brushes is unnecessary since brushes are now bundled in
the Essentials asset library. Icons/previews are handled as standard asset
previews.
- Grease pencil eraser options are replaced by a general default eraser brush
that can be set by the user.
More changes are planned still, see task list issue below.
Main Authors: Bastien Montagne, Brecht Van Lommel, Hans Goudey, Julian Eisel
Additionally involved on the design: Dalai Felinto, Julien Kaspar
Blog Post: https://code.blender.org/2024/07/brush-assets-is-out/
Tasks:
https://projects.blender.org/blender/blender/issues/116337
Reviewed incrementally as part of the brush assets project, see:
https://projects.blender.org/blender/blender/pulls/106303
The functionality of the Bone Selection Sets add-on is now integrated
into Blender itself. Rigify has been updated to no longer check for the
add-on, but just assume that the functionality is available.
The keymap is still the same, and so are all the class names. This
ensures that there are no conflicts when people still have the old
add-on enabled somehow. And there is versioning code to remove the
'add-on enabled' state so that Blender won't complain it cannot find it
any more.
Compared to the add-on, the following changes are made:
- The 'bone' icon has been removed from the list of available selection
sets. It was the same for each entry anyway, and thus didn't provide
any information.
- The code has been split up into multiple files, with the UI elements
in `scripts/startup/bl_ui/properties_data_armature.py` and the
operators in `scripts/startup/bl_operators/bone_selection_sets.py`.
- Helper functions and classes are prefixed with `_` to indicate that
they are not part of any public API.
- The `Operator` helper subclasses have been transformed to mix-in
classes. This way the only subclasses of `Operator` are the actual
operators.
- Comments & descriptions have been updated for clarity & consistency.
This commit contains code by the following authors, ordered by number of
commits in the original add-on repository, highest first:
Co-Authored By: Ines Almeida <britalmeida@gmail.com>
Co-Authored By: Sybren A. Stüvel <sybren@stuvel.eu>
Co-Authored By: Campbell Barton <ideasman42@gmail.com>
Co-Authored By: meta-androcto <meta.androcto1@gmail.com>
Co-Authored By: Demeter Dzadik <Mets>
Co-Authored By: lijenstina <lijenstina@gmail.com>
Co-Authored By: Brecht Van Lommel <brechtvanlommel@gmail.com>
Co-Authored By: Aaron Carlisle <carlisle.b3d@gmail.com>
For the full history see the original add-on at:
https://projects.blender.org/blender/blender-addons/commits/branch/main/bone_selection_sets.py
Reviewed On: https://projects.blender.org/blender/blender/pulls/124343
Adds snapping in the VSE preview area.
Source points are the four corners and origins of all selected, visible
image quads. Targets can be preview borders, preview center, or
corners/origins of other strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/122759
Retiming versioning used incorrect source for strip length, so produced
inverted strips. Also it tried to scale sound strips by `speed_factor`,
but sound strips did not change length when retimed.
Finally, the original versioning code was in versioning_300.cc file,
even though it was released with 4.0 version.
Pull Request: https://projects.blender.org/blender/blender/pulls/123144
Only apply EEVEE-Next material shadow versioning to materials with
surfaces. Otherwise this will break the rendering of some materials
(E.g. Volumetrics) by making the surface opaque to the camera.
Pull Request: https://projects.blender.org/blender/blender/pulls/124076
This is a workaround to allow user to keep working without loss of data
when an issue like #124049 happens.
This commit also expose again the `use_all_linked_data_direct` debug
option, no idea why that one was removed.
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 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
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 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 versioning code was introduced in 4.1 release cycle when
we were planning to release EEVEE next in 4.1. This means that
the versioning was not applied to files created in 4.1 using
EEVEE-Legacy and loaded into 4.2.
Moving the code just before the EEVEE-Legacy removal make
the versioning work as expected. There is no side effect
inside the versioning code.
Fix#123500
Calling `MEM_freeN` on data allocated with `MEM_new` is bad, since it
will not call a destructor matching the one invoked as part of
`MEM_new`.
While in practice cases fixed below were 'not a problem' currently, as
they are trivial Cpp types (and therefore their destructor is doing
nothing), `MEM_freeN` has no way to ensure it is dealing with such a
trivial data type, so allowing such mismatch is dirty and dangerous.
Note that almost all fixed cases look more like unintentional mistakes
(mis-usages of `MEM_new` instead of `MEM_cnew`).
NOTE: There is one more (known!) case in the asset code, which fix is
slightly less trivial, and will go through a separate PR.
NOTE: This is a by-product of some work to detect such invalid usages of
`MEM_freeN` on memory chunks allocated with `MEM_new`.
Pull Request: https://projects.blender.org/blender/blender/pulls/123691
Make half-size waveforms default in new files and Video Editing template.
They are more space efficient and display more detail at small sizes.
This does not change existing files.
Pull Request: https://projects.blender.org/blender/blender/pulls/123511
Some of the existing colors were hard to read with the new
strips design.
Tried following the concept from 2.83 redesign rationale:
* Same saturation for regular strips.
* Lower saturation for effect strips.
* Tried to reduce the hue shift between certain similar effects.
Other changes:
* Match saturation of all regular strips.
* Reduce value and saturation (mostly value) of color tags so
they are readable in both light and dark text.
* Image: Follow node editor Image node socket color.
* Color: Use the same hue as the color node socket.
* Text: Change it so it doesn’t use the same as Image.
* Sound: Use a greener color, less movie-like blue.
* Scene: Light gray, similar fashion to Collections.
* Other strips had minor adjustments.
Images and details in the pull request.
Pull Request: https://projects.blender.org/blender/blender/pulls/123446
EEVEE stores light probes using octahedral mapping. Compared to the previous
cubemap storage octahedral has less pixels. The 64x64 is becoming useless
and can be removed. This PR also enables generating light probe maps upto 4k.
Some issues were found: the offset of the sphere inside the atlas
was always set to mipmap level 0 offset. This was hidden because of the texture
wrapping. Also the offset was substracted from the local texture
coordinate when calculating the direction of the pixel. Might be that due
to the incorrect offset (mipmap level 0), the latter issue was never detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123074
EEVEE stores light probes using octahedral mapping. Compared to the previous
cubemap storage octahedral has less pixels. The 64x64 is becoming useless
and can be removed. This PR also enables generating light probe maps upto 4k.
Some issues were found: the offset of the sphere inside the atlas
was always set to mipmap level 0 offset. This was hidden because of the texture
wrapping. Also the offset was substracted from the local texture
coordinate when calculating the direction of the pixel. Might be that due
to the incorrect offset (mipmap level 0), the latter issue was never detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123074
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
The previous approximation lead to values that were a bit too large.
Generally, there won't be a perfect conversion value, but at least the
defaults from GPv2 should give reasonable results.
This fixes#121695. `float4x4` matrices are generally expected to be 16 byte aligned.
Currently, there is no mechanism (afaik) that allows allocating these overaligned types
when loading files from disk. This patch adds an array with alignment information for
each type in `SDNA`. Currently, the alignment is just `__STDCPP_DEFAULT_NEW_ALIGNMENT__`
for all types and is manually set for the `mat4x4f` DNA type. The .blend file format is
not changed at all. The alignment information is purely runtime data.
In the future it would probably be good to generalize this a bit more instead of
hardcoding the alignment for `mat4x4f`, but would make it unnecessarily complex for
now because this is intended for the release branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/123271
This adds a "Legacy Behavior" option to the Limit Rotation constraint that makes
it behave how Limit Rotation constraints did prior to
ed2408400d. Newly created constraints have this
option disabled, but versioning code enables the option on constraints from
older files to ensure that the behavior of e.g. existing rigs is not altered.
This is one part of a two-part fix for #123105. The other part is in PR
extensions/rigify#4.
Pull Request: https://projects.blender.org/blender/blender/pulls/123361
