Goal of this patch is to stop the invocation of OpenGL calls via the bgl module
on a none OpenGL GPU backend, report this as a python deprecation warning
and report this to the user.
## Deprecation warning to developers
```
>>> import bgl
>>> bgl.glUseProgram(0)
<blender_console>:1: DeprecationWarning: 'bgl.glUseProgram' is deprecated and will be removed in Blender 3.7. Report or update your script to use 'gpu' module.
```
## Deprecation message to users
The message to the user is shown as part of the Info Space and as a message box.
{F14159203 width=100%}
{F14158674 width=100%}
During implementation we tried several ideas:
# Use python warning as errors: This isn't fine grained enough and can show incorrect information to the user.
# Throw deprecation as error and use sys.excepthook to report the user message.
This required a custom exception class to identify the bgl deprecation and a CPython handler function to
be set during python initialization. Although this is the most flexible there was a disconnect between the
exception class, exception function and the excepthook registration.
# A variant how we handle autoexec failures. A flag is stored in Global and when set the user message is reported.
Not that flexible, but code is more connected to the boolean stored in the Global struct.
Although using Global struct isn't nice I chose this solution due to its traceability. It is clear to developers
reading the code how the mechanism works by using search all functionality of your IDE.
Reviewed By: MichaelPW, campbellbarton
Maniphest Tasks: T103863
Differential Revision: https://developer.blender.org/D16996
Use a consistent style for declaring the names of struct members
in their declarations. Note that this convention was already used in
many places but not everywhere.
Remove spaces around the text (matching commented arguments) with
the advantage that the the spell checking utility skips these terms.
Making it possible to extract & validate these comments automatically.
Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo`
which were using brief descriptions.
A proper boolean custom property type is commonly requested. This
commit simply adds a new `IDP_BOOLEAN` type that can be used for
boolean and boolean array custom properties. This can also be used
for exposing boolean node sockets in the geometry nodes modifier.
I've just extended the places existing IDProperty types are used, and
tested with the custom property edit operator and the python console.
Adding another IDProperty type is a straightforward extension of the
existing design.
Differential Revision: https://developer.blender.org/D12815
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
Translation from python enum values were incorrect and textures created
in python using those types would result in faulty textures. In
renderdoc those textures would not bind.
`BPYGPU_IS_INIT_OR_ERROR_OBJ` is not implemented in all pygpu functions.
Instead of copying and pasting that call across the API when it has no
gpu context, override the methods with one that always reports error.
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
Function casts hid casting between potentially incompatible type
signatures (using int instead of Py_ssize_t). As it happens this seems
not to have caused any bugs on supported platforms so this change is
mainly for correctness and to avoid problems in the future.
Missed these changes in [0].
Also replace designated initializers in some C code, as it's not used
often and would need to be removed when converting to C++.
[0] e555ede626
Use struct identifiers in comments before the value.
This has some advantages:
- The struct identifiers didn't mix well with other code-comments,
where other comments were wrapped onto the next line.
- Minor changes could re-align all other comments in the struct.
- PyVarObject_HEAD_INIT & tp_name are no longer placed on the same line.
Remove overly verbose comments copied from PyTypeObject (Python v2.x),
these aren't especially helpful and get outdated.
Also corrected some outdated names:
- PyTypeObject.tp_print -> tp_vectorcall_offset
- PyTypeObject.tp_reserved -> tp_as_async
This patch adds a placeholder for the vulkan backend.
When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`)
it might open a blender screen, but nothing should be visible as
none of the functions are implemented or otherwise crash on a nullptr.
This is expected as this is just a placeholder. The goal is to add shader compilation
+validation to this backend as one of the next steps so we can validate
changes to existing shaders on OpenGL, Metal and Vulkan at the same time.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D16338
Show the windowing environment on non MS-Windows/Apple systems,
since X11/WAYLAND are selected startup there was no convenient way
for users to know which back-end was being used.
Include the windowing environment in the About splash & system-info.txt
since it will be useful for handling bug reports.
This commit adds a private API call not intended for general use
as I would like to be able to remove this later and it's only needed
in the specific case of testing if Blender is using WAYLAND or X11
(which maybe be used via XWayland).
Python scripts can already inspect the system to check which windowing
environment used, the API call is mainly useful for troubleshooting.
Rename BKE_appdir_folder_id_version to
BKE_appdir_resource_path_id_with_version because BKE_appdir_folder_id
and BKE_appdir_folder_id_version didn't accept compatible arguments.
Also add notes to GHOST_getSystemDir & GHOST_getUserDir that
BKE_appdir_resource_path_id(..) should be used instead (in most cases).
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
Mathutils types were always GC tracked even when it wasn't intended.
Not having to track objects speeds up Python execution.
In an isolated benchmark created to stress test the GC
creating 4-million vectors (re-assigning them 100 times), this gives
an overall ~2.5x speedup, see: P3221.
Details:
Since [0] (which added support for sub-classed mathutils types)
tp_alloc was called which defaults to PyType_GenericAlloc which always
GC tracked the resulting object when Py_TPFLAGS_HAVE_GC was set.
Avoid using PyType_GenericAlloc unless the type is sub-classed,
in that case the object is un-tracked.
Add asserts that the tracked state is as expected before tracking &
un-tracking, to ensure changes to object creation don't cause objects
to be tracked unintentionally.
Also assign the PyTypeObject.tp_is_gc callback so types optionally GC
track objects only do so when an object is referenced.
[0]: fbd9364944
Depending on the actual platform, Blender will disable features that are
known to have a faulty implementation. Add-on developers or users don't
have the ability to check what is actually enabled.
This patch will add the ability to check for
* Compute shader support `gpu.capabilities.compute_shader_support_get()`.
* SSBO support `gpu.capabilities.shader_storage_buffer_objects_support_get()`.
* Image load/store `gpu.capabilities.shader_image_load_store_support_get()`.
Correction of U.dpi to hold actual monitor DPI. Simplify font sizing by
omitting DPI as API argument, always using 72 internally.
See D15961 for more details.
Differential Revision: https://developer.blender.org/D15961
Reviewed by Campbell Barton
This simplifies python code.
When we call a method like shader.uniform_float("color", (1,1,1,1)),
we expect the shader's uniform to be updated regardless of whether the
shader is bound or not.
And `batch.draw()` already calls `GPU_shader_bind` inside.
Differential Revision: https://developer.blender.org/D15929
