Previously, the base math headers included GMP headers in all cases.
This was problematic because we don't want all modules that use the
math headers to depend on GMP, and the unnecessary includes could
theoretically have detrimental effects to compile times.
Now `BLI_math_mpq.hh` depends on `BLI_math_base.hh`, so if a file
needs to use exact arithmatic, it can just include the former.
Differential Revision: https://developer.blender.org/D15079
Issues stems from the mesh not being watertight. This was caused by
floating point precision issues when evaluating patch coordinates at
patch boundaries (loops/corners in different patches pointing to the same
vertex). To fix this we ensure that all loops pointing to the same vertex
share the same patch coordinate. This keeps code simple, and does not
require to track precision issues in floating point math all over the
place.
This commit hides "UI attributes" described in T97452 from the UI lists
in mesh, curve, and point cloud properties, and disallow accessing them
in geometry nodes.
Internal UI attributes like selection and hiding values should use the
attribute system for simplicity and performance, but we don't want to
expose those attributes in the attribute panel, which is meant for
regular user interaction. Procedural access may be misleading or cause
problems, as described in the design task above.
These attributes are added by two upcoming patches: D14934, D14685
Differential Revision: https://developer.blender.org/D15069
See previous commit for an explanation of what went wrong. Similar to
the fix there, we also have to update the dragged data (e.g. the
data-block) referenced by the button.
Committing separately since this could cause further issues.
In Blender buttons are recreated over redraws, except of the active
button which is kept alive, and replaces the new version of itself in
the new redraw. In order to do that, the button needs to be recognized.
This process of recognizing and matching buttons from different redraws
isn't always bullet-proof. That's okay-ish, but we have to make sure
that the relevant data of the old active button is updated with the
newest data.
Here the matching would go wrong, and the new active button was
recognized as the old active button, which was in fact removed when the
asset was cleared. This patch makes sure the image buffer attached to
the buttons is updated when buttons were recognized as matching.
Note that the dragging will still use the wrong data-block, this will be
fixed in the following commit.
When multiple objects are in edit mode, UVs for the objects, except for
the first one (in rendering order) appear corrupted. The corruption is
because the UVs are not evaluated as the compute shader is not bound,
thus we read unitialized memory.
We keep track of the currently bound shader in the GPU context in order
to avoid unnecessary shader switches in case the same shader is used in
consecutive calls. However, the shader used by the OpenSubdiv evaluator
is not part of Blender and therefore not tracked via the GPU context.
When extracting UVs for multiple objects, we only ever run a single
shader (FVar evaluation). However, between the compute calls, we also
call the OpenSubdiv stencil evaluation shader, which uses `glUseProgram`
modifying the current program, outside of our control, which then also
unbinds the Blender compute shader making the compute dispatch fail ("No
active compute shader").
The fact that extracting the UVs for the first rendered object works is
because another (Blender) shader was bound in the GPU context prior to
our binding of our evaluation shader.
To fix this, we remember, in the OpenSubdiv evaluator, the current
program so that it can be reset after the stencil program is done.
Differential Revision: https://developer.blender.org/D15064
When building blender as a python module, such as for inclusion in a
wheel, it is not permitted to link against python libraries.
This diff does so by simply unsetting the library when building blender
as a python module, instead of the more heavyweight solution of
switching to the cmake FindPython module.
Reviewed By: LazyDodo, campbellbarton
Ref D15012
The operator assumed it was called on a mesh object, which has
mostly been the case because of lack of support for other object
types, but the new curves object is supported, which is the situation
in the report.
Differential Revision: https://developer.blender.org/D15063
The new OBJ importer operator didn't register an undo event.
This commit enables the register and undo flags for the operator.
Reviewed By: Bastien Montagne, Aras Pranckevicius, Serhiy Striletksy
Differential Revision: https://developer.blender.org/D15051
Some of the tools in sculpt mode were still referring to the previously experimental sculpt vertex colors.
They should instead refer to color attributes.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D15073
Add the following macros for enums as support for these features wasn't
all that obvious and there were some inconsistencies in their use.
- RNA_ENUM_ITEM_HEADING(name, description)
- RNA_ENUM_ITEM_SEPR
- RNA_ENUM_ITEM_SEPR_COLUMN
Avoid in-lining large enums such as icons and event types, linking
to them instead.
This mitigates T76453, where long enums took a lot of space in the docs,
this was a problem with `UILayout` where each icon argument would list
all icons. [0] worked around the issue using CSS to scroll the list.
However this has the draw-back where some items are clipped in a way
that's not obvious, see: T87008.
The reason this isn't a complete solution is that Python defined enums
aren't written into their own pages which can be linked to, although
currently there are no large Python enums included in the API docs.
All in-lined enums are now under 20 items.
[0]: 1e8f266591
Create a page for every enum in RNA_enum_items.h, which includes
the enum values and the doc-string for each item.
Each page creates a references which the API reference can be linked to
via the same name as the enum, so :ref:`rna_enum_icon_items` links
to the list of icons for e.g.
This has two main advantages:
- No need to manually duplicate enum values in the doc-strings of
functions defined in Python's C/API (not RNA defined functions),
`bpy.props` for example.
- The generated Python API docs can reference these instead of including
the enums in-line - resulting in unreasonably long lists in the case
if icons and event types (for example).
These changes will be made separately.
This commits corrects the calculation of the Frame Node label size,
making it independent of the 'Line Width' user preference.
Since `U.dpi` is actually DPI divided by `U.pixelsize` and `U.pixelsize`
is calculated from line-width multiplying by `U.pixelsize` undoes
the connection between line-width and label size.
It now stays the same, regardless of the line-width setting.
Reviewed By: Julian Eisel, Harley Acheson
Differential Revision: https://developer.blender.org/D14338
This commits corrects the calculation of the Frame Node label size,
making it independent of the 'Line Width' user preference.
Since `U.dpi` is actually DPI divided by `U.pixelsize` and `U.pixelsize`
is calculated from line-width multiplying by `U.pixelsize` undoes
the connection between line-width and label size.
It now stays the same, regardless of the line-width setting.
Reviewed By: Julian Eisel, Harley Acheson
Differential Revision: https://developer.blender.org/D14338
Add support for adding (inserting) new background images into an
override of a linked Camera ID.
Request from the Blender studio.
This ended up being more involved than expected as it uncovered some
latent issues with existing background images code. Noticiably, a new
`BKE_camera_background_image_copy` had to be added to handle copying
of background images in a proper, generic ID-management way.
The number of attribute domains is not an attribute domain.
This way it doesn't have to be handled in switch statements.
Differential Revision: https://developer.blender.org/D15065
Assuming that an ID pointer is NULL because another 'source type'
property has some specific value is utterly wrong and a gateway to
usercounting bugs.
These lines were not used now because the handling of copy data has changed.
Assigning the `eval` data can produce unexpected result, especially since everywhere ID_RECALC_TRANSFORM is used, we also do a copy on write. That should take care of `ob->data` for the eval object.
