Add an error check that the path being linked doesn't match the current
blend file.
Also resolve reference leak in the case of library override errors.
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
This removes the include `UI_interface_layout.hh` from
`UI_interface_c.hh`, and in many places this swaps the include
from `UI_interface.hh` to `UI_interface_layout.hh`.
Also, cleanups some `UI_interface.hh` includes with
`UI_interface_icons.hh` or `UI_interface_types.hh`
GPU_DATA_UINT_24_8 isn't used anymore. We cannot phase out the data type
as it can still be used by add-ons. This PR will deprecate
`GPU_DATA_UINT_24_8`. When used in an add-on a deprecation message will
be shown.
Pull Request: https://projects.blender.org/blender/blender/pulls/140715
Resolve reference counting error in the RNA API which mixed up ownership
between ExtensionRNA::data & StructRNA::py_data.
In practice this generally worked as RNA_struct_free_extension behaved
as if ExtensionRNA owned the reference instead of StructRNA, so as long
as only one reference was removed, there wasn't any difference.
When re-registering Python classes with RNA, ownership wasn't handled
properly which could result in negative reference counts,
crashing in some cases.
Python 3.14 has moved some functionality into the public API,
use the updated names even with older Python versions.
Also resolve an error caused by variable reuse with delayed annotation
evaluation for TextureProperties_MixIn on startup.
Resolve#140695.
Python 3.14 has moved some functionality into the public API,
use the updated names even with older Python versions.
Also resolve an error caused by variable reuse with delayed annotation
evaluation for TextureProperties_MixIn on startup.
Resolve#140695.
Metal and AMD/Intel/Vulkan don't support depth24 texture formats
natively. The backends implemented fallback to use depth32f in
stead.
Recently we removed all usages of depth24 to use depth32 and the
next step is to remove the depth24 format and the workarounds in
the backend.
Note: The removal of `GPU_DATA_UINT_24_8` isn't part of this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/140659
GPU_DEPTH24_STENCIL8 and GPU_DEPTH_COMPONENT24 are deprecated in Blender
5.0. Internally they will be removed. When used via python they are
automatically converted to their DEPTH32F variant and a deprecation
warning will be displayed.
Pull Request: https://projects.blender.org/blender/blender/pulls/140644
The reasoning is that this is not supported by Vulkan.
In order to make shaders cross API compatible, python scripts
needs to use `GPUShaderCreateInfo`.
This removes the constructor all-together. Another option
is to raise an error inside the constructor and always
return none.
Rel #107374
Pull Request: https://projects.blender.org/blender/blender/pulls/140368
This commit implements #125759.
It removes:
* Blender does not build on big endian systems anymore.
* Support for opening blendfiles written from a big endian system is
removed.
It keeps:
* Support to generate thumbnails from big endian blendfiles.
* BE support in `extern` or `intern` libraries, including Cycles.
* Support to open big endian versions of third party file formats:
- PLY files.
- Some image files (cineon, ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/140138
This prevents the use of unaligned data types in
vertex formats. These formats are not supported on many
platform.
This simplify the `GPUVertexFormat` class a lot as
we do not need packing shenanigans anymore and just
compute the vertex stride.
The old enums are kept for progressive porting of the
backends and user code.
This will break compatibility with python addons.
TODO:
- [x] Deprecation warning for PyGPU (4.5)
- [x] Deprecate matrix attributes
- [x] Error handling for PyGPU (5.0)
- [x] Backends
- [x] Metal
- [x] OpenGL
- [x] Vulkan
Pull Request: https://projects.blender.org/blender/blender/pulls/138846
Annotation `Callable[[Any, ...], str | None]` is not supported by Python
typing system and ... will be misinterpreted as unknown type instead of
option to provide variable number of arguments.
Ref !138804
e.g. stands for "exempli gratia" in Latin which means "for example".
The best way to make sure it makes sense when writing is to just expand
it to "for example". In these cases where the text was "for e.g.", that
leaves us with "for for example" which makes no sense. This commit fixes
all 110 cases, mostly just just replacing the words with "for example",
but also restructuring the text a bit more in a few cases, mostly by
moving "e.g." to the beginning of a list in parentheses.
Pull Request: https://projects.blender.org/blender/blender/pulls/139596
This PR adds builtin shaders for drawing points. Using `FLAT_COLOR`,
`SMOOTH_COLOR`, `UNIFORM_COLOR` can lead to undesired behavior
on Metal and Vulkan backends. To ensure future compatibility this PR
adds `POINT_FLAT_COLOR` and `POINT_UNIFORM_COLOR`.
The point size can be set using `gpu.state.point_size_set`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139583
This PR adds a clear on creation for draw region framebuffers, which
fixes issue https://projects.blender.org/blender/blender/issues/139443.
When using the "Lock Interface" option, redrawing is disabled until the
rendering process has finished. When the GPU driver does not initialize
framebuffer textures with zero, this means that visual corruption can
be perceived when resizing the main window while rendering.
This fix makes sure that framebuffer textures are initialized with zero
on all GPU platforms.
Pull Request: https://projects.blender.org/blender/blender/pulls/139445
This is adding a hard error for backends do that do not supports it.
Even without this, the backend would return a nullptr. But the error
message in this case was just "see console for more details" without
any additional detail. Which was confusing.
Add back the deprecated format to avoid asserts.
GPU backends should still have the code to support them.
Also add deprecation warnings as these types will be
removed for 5.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/139213
This promotes any INT_TO_FLOAT attribute to F32 and
to the float promotion inside python `attr_fill`.
We issue a deprecation warning when hitting this path.
Raise an error is the component type is not integer.
Pull Request: https://projects.blender.org/blender/blender/pulls/139206
For IDProperties, this flag is mostly used only to controll whether
IDProperty code should also handle ID refcounting or not (through
`LIB_ID_CREATE_NO_USER_REFCOUNT`).
Without this fix, IDProp Group Merge could end up trying to modify ID
refcount of its data-block properties (via `IDP_FreeProperty`), which
can lead to data corruption or even crashes (e.g. when used in readfile
code, before lib-linking process).
Issue discovered while working on the system IDProperties split project
(!135807).
Pull Request: https://projects.blender.org/blender/blender/pulls/139230
This commit finishes removing the uses of the integer to float
vertex buffer fetch mode. Previous commits noted below already started
that process. The last usage was geometry attributes. Now integers are
converted to floats as part of the existing upload process.
The change makes the Vulkan vertex buffer type conversion unused, so
it's removed. That's nice because Vulkan vertex buffers go from 1040 to
568 bytes in size and have significantly less overhead on creation.
Related:
- 153abc372e
- 1e1ac2bb9b
- 617858e453
Pull Request: https://projects.blender.org/blender/blender/pulls/138873
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
Symptoms were drivers still being active while others seemingly
disabled. Indices in the RNA path up to the `ANIM_remove_driver` call
are correct, so it is not entirely clear to me why this goes wrong, but
forcing an update by tagging animation resolves the issue.
NOTE from @dr.sybren : Without this fix, the old copy-for-evaluation
is still there, which still has the driver (because it's a copy)
NOTE: seems we are not handling ND_FCURVES_ORDER anywhere?
Pull Request: https://projects.blender.org/blender/blender/pulls/138490
