| Age | Commit message (Collapse) | Author |
|---|
|
This adds a new `blender::BitVector` data structure that was requested
a couple of times. It also replaces usages of `BLI_bitmap` in C++ code.
See the comment in `BLI_bit_vector.hh` for more details about the
advantages and disadvantages of using a bit-vector and how the new
data structure compares to `std::vector<bool>` and `BLI_bitmap`.
Differential Revision: https://developer.blender.org/D14006
|
|
|
|
A `blender::Pool` can construct and destruct elements without reordering. Freed items memory
will be reused by next allocations.
Elements are allocated in chunks to reduce memory fragmentation and avoid reallocation.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D15894
|
|
|
|
This patch moves material indices from the mesh `MPoly` struct to a
generic integer attribute. The builtin material index was already
exposed in geometry nodes, but this makes it a "proper" attribute
accessible with Python and visible in the "Attributes" panel.
The goals of the refactor are code simplification and memory and
performance improvements, mainly because the attribute doesn't have
to be stored and processed if there are no materials. However, until
4.0, material indices will still be read and written in the old
format, meaning there may be a temporary increase in memory usage.
Further notes:
* Completely removing the `MPoly.mat_nr` after 4.0 may require
changes to DNA or introducing a new `MPoly` type.
* Geometry nodes regression tests didn't look at material indices,
so the change reveals a bug in the realize instances node that I fixed.
* Access to material indices from the RNA `MeshPolygon` type is slower
with this patch. The `material_index` attribute can be used instead.
* Cycles is changed to read from the attribute instead.
* BMesh isn't changed in this patch. Theoretically it could be though,
to save 2 bytes per face when less than two materials are used.
* Eventually we could use a 16 bit integer attribute type instead.
Ref T95967
Differential Revision: https://developer.blender.org/D15675
|
|
The purpose of `NodeTreeRef` was to speed up various queries on a read-only
`bNodeTree`. Not that we have runtime data in nodes and sockets, we can also
store the result of some queries there. This has some benefits:
* No need for a read-only separate node tree data structure which increased
complexity.
* Makes it easier to reuse cached queries in more parts of Blender that can
benefit from it.
A downside is that we loose some type safety that we got by having different
types for input and output sockets, as well as internal and non-internal links.
This patch also refactors `DerivedNodeTree` so that it does not use
`NodeTreeRef` anymore, but uses `bNodeTree` directly instead.
To provide a convenient API (that is also close to what `NodeTreeRef` has), a
new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink`
now have C++ methods declared in `DNA_node_types.h` which are implemented in
`BKE_node_runtime.hh`. To make this work, `makesdna` now skips c++ sections when
parsing dna header files.
No user visible changes are expected.
Differential Revision: https://developer.blender.org/D15491
|
|
When building without thumbnails some variables weren't used,
reduce their scope as well as the BlPath sub-string.
|
|
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
|
|
|
|
Previously the base virtual array implementation optimized for
common cases where data is stored as spans or single values.
However, that didn't make sense when there are already
sub-classes that handle those cases specifically. Instead,
implement the faster materialize methods for each class.
Now, if the base class is reached, it means no optimizations
for avoiding virtual function call overhead are used.
Differential Revision: https://developer.blender.org/D15549
|
|
When the curve type attribute doesn't exist, there is no reason to
create an array for it only to fill the default value, which will add
overhead to subsequent "add" operations. I added a "get_if_single"
method to virtual array to simplify this check. Also use the existing
functions for filling curve types.
Differential Revision: https://developer.blender.org/D15560
|
|
|
|
|
|
|
|
The calculation was revised to address two issues:
* Discontinuities occurring when detail was a non-integer greater than 2.
* Levels of detail in the interval [0,1) repeating the levels of detail in
the interval [1,2).
This fixes Cycles, Eevee and geometry nodes.
Differential Revision: https://developer.blender.org/D15785
|
|
|
|
Update comment, noting why this is kept.
|
|
Making the callers responsible for this isn't practical as matrices are
often passed indirectly to a functions such as mat3_to_axis_angle,
BKE_object_mat3_to_rot & BKE_pchan_mat3_to_rot.
Or the matrix is combined from other matrices which could be negative.
Given quaternions calculated from negative matrices are completely
invalid and checking only needs to negate matrices with a negative
determinant, move the check into mat3_to_quat and related functions.
Add mat3_normalized_to_quat_fast for cases no error checking on the
input matrix is needed such as blending rotations.
|
|
|
|
Add an assert to ensure callers don't pass in negative matrices as the
resulting quaternion is invalid.
|
|
Use a more direct method of checking if a matrix is negative instead of
using cross & dot product.
Also replace some determinant_m3() < 0 checks with is_negative_m3.
|
|
- Assign return arguments last instead of manipulating them.
- Remove redundant NULL assignment of return arguments.
|
|
Mostly update the declarations, in some cases rename in the function
especially when the names used were inconstant with related functions.
|
|
|
|
Use `inline constexpr` instead of `static constexpr` to prevent these
variables from being duplicated in each translation unit that includes
the BLI_any.hh header.
Differential Revision: https://developer.blender.org/D15698
|
|
Instead of using macros like GLIBC we can use the CMake build
systems internal functions to check if some header or functions are
present on the running system's libc.
Add ./build_files/cmake/have_features.cmake to add checks for
platform features which can be used to set defines for source
files that require them.
Reviewed By: campbellbarton
Ref D15696
|
|
|
|
Multiply numerator and denominator by 8 to split circle into octants.
Use symmetry and negation to increase precision.
|
|
|
|
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D15588
|
|
|
|
Commit 310be2e37cfb did not update UI_MENU_ARROW_SEP used in tests.
|
|
Use a smaller arrow text character as menu item separator.
See D15578 for examples and details.
Differential Revision: https://developer.blender.org/D15578
Reviewed by Julian Eisel
|
|
Builds on all four platforms on the buildbot. Includes clang tidy fixes.
|
|
This is a quite interesting case, where two arguments to a function are
evaluated in different order on Apple Clang than on GCC and I guess
MSVC. Left a comment on that.
|
|
|
|
When plotting equally distant points around a circle support an extra
axis of symmetry so twice as many exact values are repeated than
originally added in [0], see code-comments for a detailed explanation.
Tests to ensure accuracy and exact symmetry have been added too.
Follow up on fix for T87779.
[0]: 087f27a52f7857887e90754d87a7a73715ebc3fb
|
|
When plotting equally distant points around a circle support an extra
axis of symmetry so twice as many exact values are repeated than
originally added in [0], see code-comments for a detailed explanation.
Tests to ensure accuracy and exact symmetry have been added too.
Follow up on fix for T87779.
[0]: 087f27a52f7857887e90754d87a7a73715ebc3fb
|
|
It was correct but less efficient without this early return.
|
|
`parallel_invoke` allows executing functions on separate threads.
However, creating tasks in tbb has a measurable amount of overhead.
Therefore, it can be benefitial to disable parallelization when
the amount of work done per function is small.
See D15539 for some benchmark results.
Differential Revision: https://developer.blender.org/D15539
|
|
|
|
The face merging code in exact boolean made an assumption that
the tesselated original face was manifold except at the boundaries.
This should be true but sometimes (e.g., if the input faces have
self-intersection, as happens in the example), it is not.
This commit makes face merging tolerant of such a situation.
It might leave some stray edges from triangulation, but it should
only happen if the input is malformed.
Note: the input may be malformed if there were previous booleans
in the stack, since snapping the exact result to float coordinates
is not guaranteed to leave the mesh without defects.
This is the second try at this commit. The previous one had a typo
in it -- luckily, the tests caught the problem.
|
|
Use the newer more generic sampling and interpolation functions
developed recently (ab444a80a280) instead of the `CurveEval` type.
Functions are split up a bit more internally, to allow a separate mode
for supplying the curve index directly in the future (T92474).
In one basic test, the performance seems mostly unchanged from 3.1.
Differential Revision: https://developer.blender.org/D14621
|
|
Previously, curves sculpt tools only worked on original data. This was
very limiting, because one could effectively only sculpt the curves when
all procedural effects were turned off. This patch adds support for curves
sculpting while looking the result of procedural effects (like deformation
based on the surface mesh). This functionality is also known as "crazy space"
support in Blender.
For more details see D15407.
Differential Revision: https://developer.blender.org/D15407
|
|
Add sin_cos_from_fraction which ensures each quadrant has matching
values when their sign is flipped.
|
|
Also remove an unused include and add a comment,
const, use the math namespace.
|
|
The name makes more sense as an action, other interpolation
methods besides linear probably don't make sense here anyway.
|
|
|
|
Calling `finish` after writing to generic attributes is currently necessary for
correctness. Previously, this was easy to forget. Now there is a check for this
in debug builds.
|
