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
This patch removes the Auto Render option from the compositor. This is
done for the following reason:
- The option didn't really work except in the case of transforming an
object. So it wasn't really reliable.
- It made little sense to use since the introduction of the Viewport
Compositor.
- It had a number of UX issues, including the fact that it can't be used
with animation playback, and the fact that rendering can get in the
way of the UI depending on the preferences for temporary editors.
Pull Request: https://projects.blender.org/blender/blender/pulls/123132
The bloom render pass has been deprecated in Blender 4.2. It was still
visible in the UI in the shading popover and available in the python API.
This PR removes the UI option and deprecated the parts of the python API.
Current add-ons that use this API should still be able to use the API, but
it would not do anything. Add-ons are encourage to remove these calls.
The flags are not cleaned up so they should still work when switching back
to previous Blender versions.
Release notes have been updated to include these changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123059
Previously these were shown as missing add-ons, since they have been
intentionally removed, remove them as part of versioning instead
of showing them as "Missing Add-ons". This is especially important
for X3D & STL which were enabled by default which meant any user
loading 4.1 preferences would have them shown as missing add-ons.
This makes sure to set the legacy properties when setting
the render method and the use transparent flag.
EEVEE-legacy should be able to render these materials
without issues.
Having the sun extracted is mandatory to keep
the same look and avoid too much light
leaking compared to EEVEE-Legacy. But adding
shadows might create performance overhead and
change the result in a very different way.
So we disable shadows in older file.
Add the color for the new keytype 'generated' to the VSE theme settings
as well.
This includes the versioning code that loads the default from the scene.
Without this, the preference would be initialised to black.
Note that the 'Blender Light' theme does not have any colors for any of
the key types, so I also didn't add the 'generated' type there.
Pull Request: https://projects.blender.org/blender/blender/pulls/123005
The attribute API defined in `attribute.cc` was dependent on
the assumption that `ID`s are always the "direct" owners of attributes.
For Grease Pencil drawings, this is not the case. The Grease Pencil ID
stores the attributes for layers, and the attributes for drawings are stored
in `CurvesGeometry` on the drawings themselves.
In order to make use of `rna_attribute.cc`, we need that API to handle
other types of attribute owners.
This adds an `AttributeOwner` which is basically just a type and a
pointer. We replace the `ID` pointers and pass `AttributeOwner`s instead.
For cases where we have to do a switch based on the type, all the
types are handled and the `default` statment is left out. This ensures
that we get a compiler warning when a new `AttributeOwnerType`
is added.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122765
Using unified paint settings for the draw tools as multiple issues.
As an artist, it is expected that changing a draw brush will change
its settings. Sharing the radius between draw brushes only leads
to frustration of having to change the radius back and forth.
Instead, we don't use unified paint settings for the tools in draw
mode and always use the settings on the brush.
Resolves#122157.
Pull Request: https://projects.blender.org/blender/blender/pulls/122886
This fixes a bug that happens when two drawings in the same grease pencil
data-block reference the same array. In this case, the same attribute array
pointer is written to .blend files for both drawings. However, when loading the
.blend file, it was not detected that the data is shared. Instead each drawing
would think that it was the single owner of the array even though it was shared.
The same problem can technically occur for all kinds of shared data, and not
just for grease pencil. However, only grease pencil shows this issue currently,
because it can easily happen that the same attribute is shared between different
`CustomData` within the same data-block. This very rarely happens with meshes or
curves, because different `CustomData` usually have different sizes and don't
share the same arrays.
A previous fix (cc891aa699) solved pretty much the same issues for the case
when two layers in the same `CustomData` share data. This original fix is now
generalized and is integrated with `BLO_read_shared` which makes it less error
prone. For each data-block, the `BlendDataReader` now remembers which shared
data it has loaded before so that it is not loaded again.
In the future this could be extended to support data that is shared between
data-blocks, but that's not as straight forward as one would hope currently. For
various reasons, different data-blocks could store independent data at the same
pointer. I specifically noticed that with a regression test file:
`blender/tests/data/modeling/geometry_nodes/attributes/attribute_statistics.blend`.
To support it, one solution could be to tag `BHead` in .blend files to indicate
that a specific pointer is shared and unique within the entire file. But that's
for another day.
Pull Request: https://projects.blender.org/blender/blender/pulls/122780
Support for "System" extensions as an alternative to the current
"User" extensions repository.
The purpose of this change is to support bundling extensions for
offline work or in environments where users setting up thier own
extensions isn't desirable, see #122512.
Details:
The default "System" repository on Linux will for example use:
- `/usr/share/blender/4.2/extensions/{system}` For system installs.
- `./4.2/extensions/{system}` For portable installs.
- Blender's default startup now has a "System" repository
which users or administrators may populate.
- Repositories can select between User/System paths,
setting a custom path overrides overrides this setting.
- Add "BLENDER_SYSTEM_EXTENSIONS" (matching "BLENDER_LOCAL_EXTENSIONS").
Ref !122832
In GPv2 the brush strength was it's own setting in the
`brush->gpencil_settings`. Now we just use the `brush->alpha`
like all other brushes.
Note: The versioning will be done when GPv3 becomes the default.
Pull Request: https://projects.blender.org/blender/blender/pulls/122565
The Film-like curve mapping option in the RGB Curves node in the
compositor produces bad results when editing its RGB curves. That's
because Film-like curve mapping only works with the combined curve by
definition, since it is a hue preserving mapping. Furthermore, the
Film-like option ignored the white balancing step altogether.
To fix this, we hide the current curve option for the File-like option
and only allow editing the combined curve, handing the same case for
versioning and RNA updates. Further, we port the implementation from the
realtime compositor which is both correct and takes white balancing into
account.
Pull Request: https://projects.blender.org/blender/blender/pulls/122762
This was caused by #122706 which moved the
versioning after linking where the engine is
already changed to EEVEE-Next. This made the
versioning never run.
# Conflicts:
# source/blender/blenloader/intern/versioning_400.cc
Add an overlay option to automatically display a label on reroute nodes.
This automatic label is propagated through chained reroute nodes and
is based on the explicit label of linked reroute nodes.
The automatic label is dimmed to distinguish it from manually set ones.
Pull Request: https://projects.blender.org/blender/blender/pulls/113368
