This check is done before the filter of non deformation bone.
So when we want to get this list, as it's cached, we get the list with non deformation bones, so try to access a bone that is filtered
Additional bug when we want to export only DEF bones :
the check is done on all bones, not only deformation bones, if we want to get only def bones.
So having at root a DEF and a nonDEF bone => Check will failed and said we can't remove armature
Solution: When checking if we can remove armature, indicate that we don't want to cache the result
Python 3.12 no longer supports calls to PyImport_AppendInittab
once initialized.
The call was redundant as Blender's `bpy_internal_modules` already
includes the "manta" module.
Resolve by disabling the call when Python's lifecycle isn't being
managed by manta-flow.
Regression in [0] attempted to access EditBones from the Bone list,
causing bone constraints fail to reference the sub-targets when
the bone and its target were both duplicated.
[0]: f025ff81fc
On the Windows platform allow pasting an image into the Image Editor
based on a filepath in the clipboard. For example, selecting "copy" on
the context menu in the file system. This checks for CF_HDROP format
and should work for all image formats we support.
Pull Request: https://projects.blender.org/blender/blender/pulls/127782
See blender/blender-assets!15 for the actual asset file change.
As part of the brush asset project, various weight paint brushes had
their falloff curve changed. This had the unintended effect of changing
the behavior of the gradient tool, as it shares the currently active
brush's settings.
This behavior is unintuitive and not well documented, as an interim fix,
the bundled assets were reverted.
Pull Request: https://projects.blender.org/blender/blender/pulls/131058
When OBJ file contains vertex normals, this can in some cases confuse
the custom loop normals code inside Blender. Since it does not simply
just use custom normals, but rather projects them into "lnor space".
But that "lnor space" calculation can go haywire sometimes, when
degenerate faces are present in the input.
Mark zero-area faces as "sharp" before doing custom normals. This will
make them not try to share the "smooth fan" lnor space with other faces,
and things will look correct.
Previously, OBJ importer was (wrongly) always setting all faces
as "sharp", which avoided this problem, but caused other issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/131041
This port is not so straightforward.
This shader is used in different configurations and is
available to python bindings. So we need to keep
compatibility with different attributes configurations.
This is why attributes are loaded per component and a
uniform sets the length of the component.
Since this shader can be used from both the imm and batch
API, we need to inject some workarounds to bind the buffers
correctly.
The end result is still less versatile than the previous
metal workaround (i.e.: more attribute fetch mode supported),
but it is also way less code.
### Limitations:
The new shader has some limitation:
- Both `color` and `pos` attributes need to be `F32`.
- Each attribute needs to be 4byte aligned.
- Fetch type needs to be `GPU_FETCH_FLOAT`.
- Primitive type needs to be `GPU_PRIM_LINES`, `GPU_PRIM_LINE_STRIP` or `GPU_PRIM_LINE_LOOP`.
- If drawing using an index buffer, it must contain no primitive restart.
Rel #127493
Co-authored-by: Jeroen Bakker <jeroen@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/129315
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
