Even though the `no_unique_address` attribute has only been standardized
in C++20, compilers seem to support it with C++17 already. This attribute
allows reducing the memory footprint of structs which have empty types as
data members (usually that is an allocator or inline buffer in Blender).
Previously, one had to use the empty base optimization to achieve the same
effect, which requires a lot of boilerplate code.
The types that benefit from this the most are `Vector` and `Array`, which
usually become 8 bytes smaller. All types which use these core data structures
get smaller as well of course.
Differential Revision: https://developer.blender.org/D14993
This commit changes the Curve to Mesh node to work with `Curves`
instead of `CurveEval`. The change ends up basically completely
rewriting the node, since the different attribute storage means that
the decisions made previously don't make much sense anymore.
The main loops are now "for each attribute: for each curve combination"
rather than the other way around, with the goal of taking advantage
of the locality of curve attributes. This improvement is quite
noticeable with many small curves; I measured a 4-5x improvement
(around 4-5s to <1s) when converting millions of curves to tens of
millions of faces. I didn't obverse any change in performance compared
to 3.1 with fewer curves though.
The changes also solve an algorithmic flaw where any interpolated
attributes would be evaluated for every curve combination instead
of just once per curve. This can be a large improvement when there
are many profile curves.
The code relies heavily on a function `foreach_curve_combination`
which calculates some basic information about each combination and
calls a templated function. I made assumptions about unnecessary reads
being removed by compiler optimizations. For further performance
improvements in the future that might be an area to investigate.
Another might be using a "for a group of curves: for each attribute:
for each curve" pattern to increase the locality of memory access.
Differential Revision: https://developer.blender.org/D14642
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Sometimes the current spline list isn't part of the original curve, like
when using the deformed control points, etc. This will be helpful in
the curve modifier stack.
This is convenient because having a uniform interface is nice, and
because of the similarity to "last".
Differential Revision: https://developer.blender.org/D11076
This method is similar to `std::vector::emblace_back` in that it constructs
the new object inplace in the vector, removing the need for a move.
The `_as` suffix is consistent with similar behavior in Map and Set data structures.
Some generic algorithms from the standard library like `std::any_of`
did not work with all container and iterator types. To improve the
situation, this patch adds various type members to containers
and iterators.
Custom iterators for Set, Map and IndexRange now have an iterator
category, which soe algorithms require. IndexRange could become
a random access iterator, but adding all the missing methods can
be done when it is necessary.
Casting pointers from one type to another does change the
value of the pointer in some cases. Therefore, casting a span
that contains pointers of one type to a span that contains
pointers of another type, is not generally safe. In practice, this
issue mainly comes up when dealing with classes that have a
vtable.
There are some special cases that are still allowed. For example,
adding const to the pointer does not change the address.
Also, casting to a void pointer is fine.
In cases where implicit conversion is disabled, but one is sure
that the cast is valid, an explicit call of `span.cast<NewType>()`
can be used.
Using C++ exceptions in Blender is difficult, due to the large
number of C functions in the call stack. However, C++ data
structures in blenlib should at least try to be exception safe,
so that they can be used if someone wants to use exceptions
in some isolated area.
This patch improves the exception safety of the Vector, Array
and Stack data structure. This is mainly achieved by reordering
some lines and doing some explicit exception handling.
I don't expect performance of common operations to be affected
by this change.
The three containers are supposed to provide at least the
basic exception guarantee for most methods (except for e.g.
`*_unchecked` methods). So, resources should not leak when
the contained type throws an exception.
I also added new unit tests that test the exception handling
in various cases.
The new reverse iterators behave as the reverse iterators for contains from
the standard library. Have a look at the tests to see how to use them.
Using them will hopefully become easier with ranges in C++20.
A Vector can now be constructed from two iterators, which is very common
in the standard library.
New Vector.insert methods allow adding elements in the middle of a vector.
These methods should not be used often in practice, because they has a linear running time.
New Vector.prepend methods allow adding elements to the beginning of a vector.
These methods are O(n) as well.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
Those are useful when you have to create containers with static
storage duration. If those would use Blender's guarded allocator,
it would report memory leaks, that are not actually leaks.
This updates the usage of integer types in code I wrote according to our new style guides.
Major changes:
* Use signed instead of unsigned integers in many places.
* C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`).
* Hash values for C++ containers are 64 bit wide now (instead of 32 bit).
I do hope that I broke no builds, but it is quite likely that some compiler reports
slightly different errors. Please let me know when there are any errors. If the fix
is small, feel free to commit it yourself.
I compiled successfully on linux with gcc and on windows.
This allows us to avoid many calls to `as_span()` methods. I will
remove those in the next commit. Furthermore, constructors
of Vector and Array can convert from one type to another now.
I tested these changes on Linux with gcc and on Windows.
This also renames `MutableArrayRef` to `MutableSpan`.
The name "Span" works better, because `std::span` will provide
similar functionality in C++20. Furthermore, a shorter, more
concise name for a common data structure is nice.
The main focus here was to improve the docs significantly. Furthermore,
I reimplemented `Set`, `Map` and `VectorSet`. They are now (usually)
faster, simpler and more customizable. I also rewrote `Stack` to make
it more efficient by avoiding unnecessary copies.
Thanks to everyone who helped with constructive feedback.
Approved by brecht and sybren.
Differential Revision: https://developer.blender.org/D7931
* Rename template parameter N to InlineBufferCapacity
* Expose InlineBufferCapacity parameter for Set and Map
* Add some comments
* Fixed an error that I introduced recently
Instead of building on top of `BLI::Vector`, just use a raw array
and handle the growing in `BLI::VectorSet`.
After this change, the existing `EdgeSet` can be reimplemented using
`BLI::VectorSet` without performance regressions.
