Videos files recorded on most phones were coming in sideways; files
recorded on some laptop cameras were coming in upside down. In both
cases the display_matrix metadata of the video stream was not applied.
This required changing internal container format of movie proxies to
be MP4 instead of AVI, since AVI does not support rotation metadata.
File extension kept at ".avi" to not disturb existing expectations.
It might be better to "bake" rotation into proxies while building them,
but right now we do not have a trivial way of doing that.
Note that this is a potential behavior change; if someone
already had manually rotated video strips, they would have
to undo that rotation now.
Pull Request: https://projects.blender.org/blender/blender/pulls/130455
Caused by 7b0ea0f1b4
By default, Color Palettes are only drawn in the UI in the context of
**painting**. UI button code then tries to update an appropriate brush
from edits to the palette.
In the report though, a palette was created and displayed via python,
making changes in Object/Edit/Pose would then crash.
So a valid `Paint` and `Brush` were assumed. `Paint` was already checked
for in a324a19f1b, but since 7b0ea0f1b4, `Paint`(if we actually have
it, e.g.from `ImagePaintSettings` [see a324a19f1b]) only has its
`brush` set once we enter texturepaint once.
Solved by checking we have a valid Brush in corresponding UI code to
begin with.
Pull Request: https://projects.blender.org/blender/blender/pulls/131031
These are converted on startup to the new type. There are still
some references left, mostly where it looked like there still needs
to be changes to properly deal with the new object type.
Two places that were not ready for GPv3:
- armatures were not set to posemode when entering weightpaint
- armatures were not in the object list when OpenGL selecting (thus
their bones were missing)
Both of them because existing code only respected
`eModifierType_Armature` (and not `eModifierType_GreasePencilArmature`
as well).
This is now corrected.
Similar to bdfb3ea6e7
Pull Request: https://projects.blender.org/blender/blender/pulls/130908
Since [0] PyConfig_InitIsolatedConfig was used which disables
Python's signal handlers, re-enable them as they're needed for
Python's own error handling to work properly.
[0]: cd5dd6e454
In legacy overlay the wire/vertex color used to draw grease pencil was
wrong, this means users can't effectively adjust grease pencil specific
wire colors. Currently this shader is used for both legacy and overlay
next, so this fix would be also beneficial down the line.
Pull Request: https://projects.blender.org/blender/blender/pulls/131023
Regression in [0] caused wheels with an older Python version
that used CPython's stable ABI to be considered incompatible.
Resolve using the stable ABI for version checks.
[0]: cfc10b0232565642afbfdc5a867f027640ce8274
Based on #123377 by @brecht, but Gitea doesn't like the rebase these
so here's a new PR.
The purpose here is to switch to fused OptiX programs for OSL execution
on CUDA. On the one hand, this makes the code easier since, but there's
also another advantage - how memory allocation is managed.
OSL shaders need memory to store intermediate values, but how much is
needed depends on the complexity of the shader. With the split program
approach, Cycles had to provide that memory, so we had to allocate a
certain amount (2 KiB, to be precise) statically and show an error if
the shader would need more. If the shader used less (which is the case
for the vast majority), the memory was just wasted.
By switching to fused kernels, OSL knows the required amount during JIT
codegen, so it can allocate only what's required, which avoids this
waste. One still needs to set a maximum, and in theory, OSL would also
support spilling over into a Cycles-provided alternative memory region.
However, we currently don't implement that - instead, we default to the
same 2048 limit as before and let advanced users override it via the
CYCLES_OSL_GROUPDATA_ALLOC environment variable if really needed.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130149
Previously, only one level of panels was supported. Now, they can be nested arbitrarily.
Panels still have to come at the bottom though.
The panel color used to be just the node color darkened a bit. Now it uses the
`TH_PANEL_SUB_BACK` theme setting which is also used by panels in other places
in Blender. However, the contrast of that is a bit weaker than what we had in nodes before.
Therefore I increased the contrast a bit.
Pull Request: https://projects.blender.org/blender/blender/pulls/128886
This is a leftover from an earlier version of overrides, but is effectively dead
code currently. It was used when there were proportional diffing capabilities.
However, Bastien mentioned that this would be implemented differently nowadays
anyway if it becomes necessary again.
This simplifies the write ID loop quite significantly.
Pull Request: https://projects.blender.org/blender/blender/pulls/130928
`AnimData`, NLA strips, and action constraints all have an `action_slot_name`
field in RNA. The purpose of this field is to store the identifier of the most
recently assigned slot, so that it can be used for auto-assignment when later
assigning different actions.
However, this field name is misleading in two ways:
1. In accordance with #130740, it's actually the slot *identifier*, not name.
2. It could be mistaken as a way to rename the currently assigned slot, which it
is not.
To resolve both of those issues, we're renaming the field to
`last_slot_identifier`, which better communicates its actual nature.
As a bonus, this also ends up decluttering Python autocomplete when looking
for things related to action_slot.
Ref: #130892
Pull Request: https://projects.blender.org/blender/blender/pulls/130911
When using texture painting Blender could freeze, crash or not showing
any results depending on the platform being used.
There were several issues:
- texture painting could send a layer offset of -1, which would select
an incorrect layer
- source data wasn't copied correctly in the staging buffer as it
ignored `texture_unpack_row_length`
Pull Request: https://projects.blender.org/blender/blender/pulls/130973
When in grease pencil drawing mode, user could pin material or vertex
color to a specific brush or fill tool, but when switching tools, the
display and the logic of how those pinned material/vertex color are used
is inconsistent, leading to confusion.
The main cause of such problem is that the new GPv3 brush/fill tool is
not respecting pinning status, on top of that, user interface display
logic is also wrong. This PR makes sure that:
- Brush/fill tools respect pinning status.
- Buttons on the tool bar always display correct pinning status.
- Brush cursor will use correct color based on pinning status.
Pull Request: https://projects.blender.org/blender/blender/pulls/130968
