Previously the bounding box was calculated for each rotation,
even though the loop would early exit if the area exceeded the best
known area, this meant the areas of the bounds was checked for
each point too. This scaled poorly, close to O(n^2).
Replace this with simple logic that keeps track of the indices
at the bounds, advancing them forward for each rotation.
This is around ~140x faster for a hull with 10k points on my system.
Note that there is potential for other improvements although
the cases where this new method doesn't perform well are quite specific
and faster than checking all points, see code-comments for details.
Add new descriptions to the `PROP_HIDDEN`, `PROP_SKIP_SAVE`, and
`PROP_LIB_EXCEPTION` flags. For the former two, these are more
explanatory than the previous descriptions. For the latter it's the
first ever description.
Personally I don't think "Do not use ghost values" was particularly
helpful, as the concept of "ghost values" isn't actually that well known
(compared to generally how many people use `bpy`). Granted, it's
described at [1], but IMO if the term "ghost values" is to be kept here,
it should include a link to that page.
[1]: https://docs.blender.org/api/current/bpy.types.bpy_struct.html
Pull Request: https://projects.blender.org/blender/blender/pulls/118036
These flags (like `'HIDDEN', 'SKIP_SAVE', etc.) mean the same thing when
used on enums and non-enum properties. Now they actually use the same
description definition in the source code, ensuring that any
improvements will apply to both.
No changes to the actual messages. Just using them for both enums and
non-enum property flags.
Pull Request: https://projects.blender.org/blender/blender/pulls/118036
Convex hull calculation would "cap" line segments with the first point.
Besides causing a buffer overflow when passing in two points,
it's not needed as matching first/last ends aren't expected
to be set by this function.
Use EXPECT_NEAR instead of EXPECT_EQ to account for a differences in
atan2 implementation on macOS, more generally relying on exact
float comparison for tests is error prone.
The BLI_endian_defines.h include was removed in [0] because
the resulting object files were unchanged on little endian systems.
Using -Werror=undef with GCC prevents this from happening in the future.
[0]: 9e4129feeb
Currently the multi-input sockets are not exposed to the custom nodes
Python API. This makes some features cumbersome to implement if one
wants a node to process an arbitrary number of inputs.
One workaround is to make inputs duplicate themselves when a link is
created, but a proper multi-input would be easier to use for both
add-on developers and users.
This commit exposes a new `use_multi_input` boolean parameter when
creating a new node socket. This makes it possible to declare a
multi-input, while still leaving the existing `is_multi_input`
property read-only so that existing nodes cannot be made unstable.
The parameter is optional so existing scripts stay compatible. It also
raises an error when used on output sockets, since it makes no sense
for those to be multi-input.
The Custom Node Tree Python template was updated to reflect this
change by making one of the inputs of the custom node multi-input.
Pull Request: https://projects.blender.org/blender/blender/pulls/114474
The benefits are removing unnecessary reallocations of the string data
and unnecessary recalculations of the size, better type safety, and more
automatic memory management.
Pull Request: https://projects.blender.org/blender/blender/pulls/118045
In this commit, a temporary mesh is created representing the edit mesh.
This mesh is then used in the Edit Mesh snapping system instead of the
BMesh.
By using a Mesh object for snapping, we remove a considerable amount of
code and use a more optimized version of snapping.
This simplifies the code and makes it easier to implement new features.
## Performance test: Face + Edge + Vert
| | Cache | Gen. Snap |
|--------|-----------|-----------|
| Before | 680.88 ms | 0.1250 ms |
| After | 489.06 ms | 0.1064 ms |
| Improv | 28.65% | 14.88% |
## Performance test: Face
| | Cache | Gen. Snap |
|--------|-----------|-----------|
| Before | 293.90 ms | 0.0230 ms |
| After | 411.92 ms | 0.0256 ms |
| Improv | -40.15% | -11.30% |
Pull Request: https://projects.blender.org/blender/blender/pulls/117047
Currently we have some old code from shader/compositor/texture nodes
that stores runtime data during and after evaluation on the node tree
itself. This is meant to be avoided, since the node tree is just meant
to be evaluation _instructions_.
Pull Request: https://projects.blender.org/blender/blender/pulls/118056
