tornavis/source/blender/blenkernel/BKE_spline.hh

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

689 lines
26 KiB
C++
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
/** \file
* \ingroup bke
*/
#include <mutex>
#include "DNA_curves_types.h"
#include "BLI_float4x4.hh"
#include "BLI_generic_virtual_array.hh"
BLI: Refactor vector types & functions to use templates This patch implements the vector types (i.e:`float2`) by making heavy usage of templating. All vector functions are now outside of the vector classes (inside the `blender::math` namespace) and are not vector size dependent for the most part. In the ongoing effort to make shaders less GL centric, we are aiming to share more code between GLSL and C++ to avoid code duplication. ####Motivations: - We are aiming to share UBO and SSBO structures between GLSL and C++. This means we will use many of the existing vector types and others we currently don't have (uintX, intX). All these variations were asking for many more code duplication. - Deduplicate existing code which is duplicated for each vector size. - We also want to share small functions. Which means that vector functions should be static and not in the class namespace. - Reduce friction to use these types in new projects due to their incompleteness. - The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a bit of a let down. Most clases are incomplete, out of sync with each others with different codestyles, and some functions that should be static are not (i.e: `float3::reflect()`). ####Upsides: - Still support `.x, .y, .z, .w` for readability. - Compact, readable and easilly extendable. - All of the vector functions are available for all the vectors types and can be restricted to certain types. Also template specialization let us define exception for special class (like mpq). - With optimization ON, the compiler unroll the loops and performance is the same. ####Downsides: - Might impact debugability. Though I would arge that the bugs are rarelly caused by the vector class itself (since the operations are quite trivial) but by the type conversions. - Might impact compile time. I did not saw a significant impact since the usage is not really widespread. - Functions needs to be rewritten to support arbitrary vector length. For instance, one can't call `len_squared_v3v3` in `math::length_squared()` and call it a day. - Type cast does not work with the template version of the `math::` vector functions. Meaning you need to manually cast `float *` and `(float *)[3]` to `float3` for the function calls. i.e: `math::distance_squared(float3(nearest.co), positions[i]);` - Some parts might loose in readability: `float3::dot(v1.normalized(), v2.normalized())` becoming `math::dot(math::normalize(v1), math::normalize(v2))` But I propose, when appropriate, to use `using namespace blender::math;` on function local or file scope to increase readability. `dot(normalize(v1), normalize(v2))` ####Consideration: - Include back `.length()` method. It is quite handy and is more C++ oriented. - I considered the GLM library as a candidate for replacement. It felt like too much for what we need and would be difficult to extend / modify to our needs. - I used Macros to reduce code in operators declaration and potential copy paste bugs. This could reduce debugability and could be reverted. - This touches `delaunay_2d.cc` and the intersection code. I would like to know @howardt opinion on the matter. - The `noexcept` on the copy constructor of `mpq(2|3)` is being removed. But according to @JacquesLucke it is not a real problem for now. I would like to give a huge thanks to @JacquesLucke who helped during this and pushed me to reduce the duplication further. Reviewed By: brecht, sergey, JacquesLucke Differential Revision: https://developer.blender.org/D13791
2022-01-12 12:57:07 +01:00
#include "BLI_math_vec_types.hh"
#include "BLI_vector.hh"
Geometry Nodes: new geometry attribute API Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is accessible from RNA and C code. The second is implemented with `GeometryComponent` and is only accessible in C++ code. The second is widely used, but only being accessible through the `GeometrySet` API makes it awkward to use, and even impossible for types that don't correspond directly to a geometry component like `CurvesGeometry`. This patch adds a new attribute API, designed to replace the `GeometryComponent` attribute API now, and to eventually replace or be the basis of the other one. The basic idea is that there is an `AttributeAccessor` class that allows code to interact with a set of attributes owned by some geometry. The accessor itself has no ownership. `AttributeAccessor` is a simple type that can be passed around by value. That makes it easy to return it from functions and to store it in containers. For const-correctness, there is also a `MutableAttributeAccessor` that allows changing individual and can add or remove attributes. Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer to the owner of the attribute data. The second is a pointer to a struct with function pointers, that is similar to a virtual function table. The functions know how to access attributes on the owner. The actual attribute access for geometries is still implemented with the `AttributeProvider` pattern, which makes it easy to support different sources of attributes on a geometry and simplifies dealing with built-in attributes. There are different ways to get an attribute accessor for a geometry: * `GeometryComponent.attributes()` * `CurvesGeometry.attributes()` * `bke::mesh_attributes(const Mesh &)` * `bke::pointcloud_attributes(const PointCloud &)` All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`. Differential Revision: https://developer.blender.org/D15280
2022-07-08 16:16:56 +02:00
#include "BKE_attribute.hh"
#include "BKE_attribute_math.hh"
struct Curve;
struct Curves;
struct ListBase;
class Spline;
using SplinePtr = std::unique_ptr<Spline>;
/**
* A spline is an abstraction of a single branch-less curve section, its evaluation methods,
* and data. The spline data itself is just control points and a set of attributes by the set
* of "evaluated" data is often used instead. Conceptually, the derived vs. original data is
* an essential distinction. Derived data is usually calculated lazily and cached on the spline.
*
* Any derived class of Spline has to manage two things:
* 1. Interpolating arbitrary attribute data from the control points to evaluated points.
* 2. Evaluating the positions based on the stored control point data.
*
* Beyond that, everything is the base class's responsibility, with minor exceptions. Further
* evaluation happens in a layer on top of the evaluated points generated by the derived types.
*
* There are a few methods to evaluate a spline:
* 1. #evaluated_positions and #interpolate_to_evaluated give data for the initial
* evaluated points, depending on the resolution.
* 2. #lookup_evaluated_factor and #lookup_evaluated_factor are meant for one-off lookups
* along the length of a curve.
2021-05-14 23:37:05 +02:00
* 3. #sample_uniform_index_factors returns an array that stores uniform-length samples
* along the spline which can be used to interpolate data from method 1.
*
* Commonly used evaluated data is stored in caches on the spline itself so that operations on
* splines don't need to worry about taking ownership of evaluated data when they don't need to.
*/
class Spline {
public:
NormalMode normal_mode = NORMAL_MODE_MINIMUM_TWIST;
blender::bke::CustomDataAttributes attributes;
protected:
CurveType type_;
bool is_cyclic_ = false;
/** Direction of the spline at each evaluated point. */
mutable blender::Vector<blender::float3> evaluated_tangents_cache_;
mutable std::mutex tangent_cache_mutex_;
mutable bool tangent_cache_dirty_ = true;
/** Normal direction vectors for each evaluated point. */
mutable blender::Vector<blender::float3> evaluated_normals_cache_;
mutable std::mutex normal_cache_mutex_;
mutable bool normal_cache_dirty_ = true;
/** Accumulated lengths along the evaluated points. */
mutable blender::Vector<float> evaluated_lengths_cache_;
mutable std::mutex length_cache_mutex_;
mutable bool length_cache_dirty_ = true;
public:
virtual ~Spline() = default;
Spline(const CurveType type) : type_(type)
{
}
Spline(Spline &other) : attributes(other.attributes), type_(other.type_)
{
copy_base_settings(other, *this);
}
/**
* Return a new spline with the same data, settings, and attributes.
*/
SplinePtr copy() const;
/**
* Return a new spline with the same type and settings like "cyclic", but without any data.
*/
SplinePtr copy_only_settings() const;
/**
* The same as #copy, but skips copying dynamic attributes to the new spline.
*/
SplinePtr copy_without_attributes() const;
static void copy_base_settings(const Spline &src, Spline &dst);
CurveType type() const;
/** Return the number of control points. */
virtual int size() const = 0;
int segments_num() const;
bool is_cyclic() const;
void set_cyclic(bool value);
virtual void resize(int size) = 0;
virtual blender::MutableSpan<blender::float3> positions() = 0;
virtual blender::Span<blender::float3> positions() const = 0;
virtual blender::MutableSpan<float> radii() = 0;
virtual blender::Span<float> radii() const = 0;
virtual blender::MutableSpan<float> tilts() = 0;
virtual blender::Span<float> tilts() const = 0;
virtual void translate(const blender::float3 &translation);
virtual void transform(const blender::float4x4 &matrix);
/**
* Change the direction of the spline (switch the start and end) without changing its shape.
*/
void reverse();
/**
* Mark all caches for re-computation. This must be called after any operation that would
* change the generated positions, tangents, normals, mapping, etc. of the evaluated points.
*/
virtual void mark_cache_invalid() = 0;
virtual int evaluated_points_num() const = 0;
int evaluated_edges_num() const;
float length() const;
virtual blender::Span<blender::float3> evaluated_positions() const = 0;
/**
* Return non-owning access to the cache of accumulated lengths along the spline. Each item is
* the length of the subsequent segment, i.e. the first value is the length of the first segment
* rather than 0. This calculation is rather trivial, and only depends on the evaluated
* positions. However, the results are used often, and it is necessarily single threaded, so it
* is cached.
*/
blender::Span<float> evaluated_lengths() const;
/**
* Return non-owning access to the direction of the curve at each evaluated point.
*/
blender::Span<blender::float3> evaluated_tangents() const;
/**
* Return non-owning access to the direction vectors perpendicular to the tangents at every
* evaluated point. The method used to generate the normal vectors depends on Spline.normal_mode.
*/
blender::Span<blender::float3> evaluated_normals() const;
void bounds_min_max(blender::float3 &min, blender::float3 &max, bool use_evaluated) const;
struct LookupResult {
/**
* The index of the evaluated point before the result location. In other words, the index of
* the edge that the result lies on. If the sampled factor/length is the very end of the
* spline, this will be the second to last index, if it's the very beginning, this will be 0.
*/
int evaluated_index;
/**
* The index of the evaluated point after the result location, accounting for wrapping when
* the spline is cyclic. If the sampled factor/length is the very end of the spline, this will
* be the last index (#evaluated_points_num - 1).
*/
int next_evaluated_index;
/**
* The portion of the way from the evaluated point at #evaluated_index to the next point.
* If the sampled factor/length is the very end of the spline, this will be the 1.0f
*/
float factor;
};
/**
* Find the position on the evaluated spline at the given portion of the total length.
* The return value is the indices of the two neighboring points at that location and the
* factor between them, which can be used to look up any attribute on the evaluated points.
* \note This does not support extrapolation.
*/
LookupResult lookup_evaluated_factor(float factor) const;
/**
* The same as #lookup_evaluated_factor, but looks up a length directly instead of
* a portion of the total.
*/
LookupResult lookup_evaluated_length(float length) const;
/**
* Return an array of evenly spaced samples along the length of the spline. The samples are
* indices and factors to the next index encoded in floats. The logic for converting from the
* float values to interpolation data is in #lookup_data_from_index_factor.
*/
blender::Array<float> sample_uniform_index_factors(int samples_num) const;
LookupResult lookup_data_from_index_factor(float index_factor) const;
/**
* Sample any input data with a value for each evaluated point (already interpolated to evaluated
* points) to arbitrary parameters in between the evaluated points. The interpolation is quite
* simple, but this handles the cyclic and end point special cases.
*/
void sample_with_index_factors(const blender::GVArray &src,
blender::Span<float> index_factors,
blender::GMutableSpan dst) const;
template<typename T>
void sample_with_index_factors(const blender::VArray<T> &src,
blender::Span<float> index_factors,
blender::MutableSpan<T> dst) const
{
this->sample_with_index_factors(
blender::GVArray(src), index_factors, blender::GMutableSpan(dst));
}
template<typename T>
void sample_with_index_factors(blender::Span<T> src,
blender::Span<float> index_factors,
blender::MutableSpan<T> dst) const
{
Geometry Nodes: refactor virtual array system Goals of this refactor: * Simplify creating virtual arrays. * Simplify passing virtual arrays around. * Simplify converting between typed and generic virtual arrays. * Reduce memory allocations. As a quick reminder, a virtual arrays is a data structure that behaves like an array (i.e. it can be accessed using an index). However, it may not actually be stored as array internally. The two most important implementations of virtual arrays are those that correspond to an actual plain array and those that have the same value for every index. However, many more implementations exist for various reasons (interfacing with legacy attributes, unified iterator over all points in multiple splines, ...). With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and `GVMutableArray`) can be used like "normal values". They typically live on the stack. Before, they were usually inside a `std::unique_ptr`. This makes passing them around much easier. Creation of new virtual arrays is also much simpler now due to some constructors. Memory allocations are reduced by making use of small object optimization inside the core types. Previously, `VArray` was a class with virtual methods that had to be overridden to change the behavior of a the virtual array. Now,`VArray` has a fixed size and has no virtual methods. Instead it contains a `VArrayImpl` that is similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly, unless a new virtual array implementation is added. To support the small object optimization for many `VArrayImpl` classes, a new `blender::Any` type is added. It is similar to `std::any` with two additional features. It has an adjustable inline buffer size and alignment. The inline buffer size of `std::any` can't be relied on and is usually too small for our use case here. Furthermore, `blender::Any` can store additional user-defined type information without increasing the stack size. Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
this->sample_with_index_factors(blender::VArray<T>::ForSpan(src), index_factors, dst);
}
/**
* Interpolate a virtual array of data with the size of the number of control points to the
* evaluated points. For poly splines, the lifetime of the returned virtual array must not
* exceed the lifetime of the input data.
*/
virtual blender::GVArray interpolate_to_evaluated(const blender::GVArray &src) const = 0;
blender::GVArray interpolate_to_evaluated(blender::GSpan data) const;
Geometry Nodes: refactor virtual array system Goals of this refactor: * Simplify creating virtual arrays. * Simplify passing virtual arrays around. * Simplify converting between typed and generic virtual arrays. * Reduce memory allocations. As a quick reminder, a virtual arrays is a data structure that behaves like an array (i.e. it can be accessed using an index). However, it may not actually be stored as array internally. The two most important implementations of virtual arrays are those that correspond to an actual plain array and those that have the same value for every index. However, many more implementations exist for various reasons (interfacing with legacy attributes, unified iterator over all points in multiple splines, ...). With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and `GVMutableArray`) can be used like "normal values". They typically live on the stack. Before, they were usually inside a `std::unique_ptr`. This makes passing them around much easier. Creation of new virtual arrays is also much simpler now due to some constructors. Memory allocations are reduced by making use of small object optimization inside the core types. Previously, `VArray` was a class with virtual methods that had to be overridden to change the behavior of a the virtual array. Now,`VArray` has a fixed size and has no virtual methods. Instead it contains a `VArrayImpl` that is similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly, unless a new virtual array implementation is added. To support the small object optimization for many `VArrayImpl` classes, a new `blender::Any` type is added. It is similar to `std::any` with two additional features. It has an adjustable inline buffer size and alignment. The inline buffer size of `std::any` can't be relied on and is usually too small for our use case here. Furthermore, `blender::Any` can store additional user-defined type information without increasing the stack size. Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
template<typename T> blender::VArray<T> interpolate_to_evaluated(blender::Span<T> data) const
{
return this->interpolate_to_evaluated(blender::GSpan(data)).typed<T>();
}
protected:
virtual void correct_end_tangents() const = 0;
virtual void copy_settings(Spline &dst) const = 0;
virtual void copy_data(Spline &dst) const = 0;
virtual void reverse_impl() = 0;
};
/**
2022-03-14 04:25:32 +01:00
* A Bezier spline is made up of a many curve segments, possibly achieving continuity of curvature
* by constraining the alignment of curve handles. Evaluation stores the positions and a map of
* factors and indices in a list of floats, which is then used to interpolate any other data.
*/
class BezierSpline final : public Spline {
blender::Vector<blender::float3> positions_;
blender::Vector<float> radii_;
blender::Vector<float> tilts_;
int resolution_;
blender::Vector<int8_t> handle_types_left_;
blender::Vector<int8_t> handle_types_right_;
/* These are mutable to allow lazy recalculation of #Auto and #Vector handle positions. */
mutable blender::Vector<blender::float3> handle_positions_left_;
mutable blender::Vector<blender::float3> handle_positions_right_;
mutable std::mutex auto_handle_mutex_;
mutable bool auto_handles_dirty_ = true;
/** Start index in evaluated points array for every control point. */
mutable blender::Vector<int> offset_cache_;
mutable std::mutex offset_cache_mutex_;
mutable bool offset_cache_dirty_ = true;
/** Cache of evaluated positions. */
mutable blender::Vector<blender::float3> evaluated_position_cache_;
mutable std::mutex position_cache_mutex_;
mutable bool position_cache_dirty_ = true;
/** Cache of "index factors" based calculated from the evaluated positions. */
mutable blender::Vector<float> evaluated_mapping_cache_;
mutable std::mutex mapping_cache_mutex_;
mutable bool mapping_cache_dirty_ = true;
public:
BezierSpline() : Spline(CURVE_TYPE_BEZIER)
{
}
BezierSpline(const BezierSpline &other)
: Spline((Spline &)other),
positions_(other.positions_),
radii_(other.radii_),
tilts_(other.tilts_),
resolution_(other.resolution_),
handle_types_left_(other.handle_types_left_),
handle_types_right_(other.handle_types_right_),
handle_positions_left_(other.handle_positions_left_),
handle_positions_right_(other.handle_positions_right_)
{
}
int size() const final;
int resolution() const;
void set_resolution(int value);
void resize(int size) final;
blender::MutableSpan<blender::float3> positions() final;
blender::Span<blender::float3> positions() const final;
blender::MutableSpan<float> radii() final;
blender::Span<float> radii() const final;
blender::MutableSpan<float> tilts() final;
blender::Span<float> tilts() const final;
blender::Span<int8_t> handle_types_left() const;
blender::MutableSpan<int8_t> handle_types_left();
blender::Span<blender::float3> handle_positions_left() const;
/**
* Get writable access to the handle position.
*
* \param write_only: pass true for an uninitialized spline, this prevents accessing
* uninitialized memory while auto-generating handles.
*/
blender::MutableSpan<blender::float3> handle_positions_left(bool write_only = false);
blender::Span<int8_t> handle_types_right() const;
blender::MutableSpan<int8_t> handle_types_right();
blender::Span<blender::float3> handle_positions_right() const;
/**
* Get writable access to the handle position.
*
* \param write_only: pass true for an uninitialized spline, this prevents accessing
* uninitialized memory while auto-generating handles.
*/
blender::MutableSpan<blender::float3> handle_positions_right(bool write_only = false);
/**
* Recalculate all #Auto and #Vector handles with positions automatically
* derived from the neighboring control points.
*/
void ensure_auto_handles() const;
void translate(const blender::float3 &translation) override;
void transform(const blender::float4x4 &matrix) override;
/**
* Set positions for the right handle of the control point, ensuring that
* aligned handles stay aligned. Has no effect for auto and vector type handles.
*/
void set_handle_position_right(int index, const blender::float3 &value);
/**
* Set positions for the left handle of the control point, ensuring that
* aligned handles stay aligned. Has no effect for auto and vector type handles.
*/
void set_handle_position_left(int index, const blender::float3 &value);
bool point_is_sharp(int index) const;
void mark_cache_invalid() final;
int evaluated_points_num() const final;
/**
* Returns access to a cache of offsets into the evaluated point array for each control point.
* While most control point edges generate the number of edges specified by the resolution,
* vector segments only generate one edge.
*
* \note The length of the result is one greater than the number of points, so that the last item
* is the total number of evaluated points. This is useful to avoid recalculating the size of the
* last segment everywhere.
*/
blender::Span<int> control_point_offsets() const;
/**
* Returns non-owning access to an array of values containing the information necessary to
* interpolate values from the original control points to evaluated points. The control point
* index is the integer part of each value, and the factor used for interpolating to the next
* control point is the remaining factional part.
*/
blender::Span<float> evaluated_mappings() const;
blender::Span<blender::float3> evaluated_positions() const final;
struct InterpolationData {
int control_point_index;
int next_control_point_index;
/**
* Linear interpolation weight between the two indices, from 0 to 1.
2021-05-14 23:37:05 +02:00
* Higher means closer to next control point.
*/
float factor;
};
/**
* Convert the data encoded in #evaulated_mappings into its parts-- the information necessary
* to interpolate data from control points to evaluated points between them. The next control
* point index result will not overflow the size of the control point vectors.
*/
InterpolationData interpolation_data_from_index_factor(float index_factor) const;
virtual blender::GVArray interpolate_to_evaluated(const blender::GVArray &src) const override;
void evaluate_segment(int index,
int next_index,
blender::MutableSpan<blender::float3> positions) const;
/**
* \warning This functional assumes that the spline has more than one point.
*/
bool segment_is_vector(int start_index) const;
/** See comment and diagram for #calculate_segment_insertion. */
struct InsertResult {
blender::float3 handle_prev;
blender::float3 left_handle;
blender::float3 position;
blender::float3 right_handle;
blender::float3 handle_next;
};
/**
* De Casteljau Bezier subdivision.
* \param index: The index of the segment's start control point.
* \param next_index: The index of the control point at the end of the segment. Could be 0,
* if the spline is cyclic.
* \param parameter: The factor along the segment, between 0 and 1. Note that this is used
* directly by the calculation, it doesn't correspond to a portion of the evaluated length.
*
* <pre>
* handle_prev handle_next
* x----------------x
* / \
* / x---O---x \
* / result \
* / \
* O O
* point_prev point_next
* </pre>
*/
InsertResult calculate_segment_insertion(int index, int next_index, float parameter);
private:
/**
* If the spline is not cyclic, the direction for the first and last points is just the
* direction formed by the corresponding handles and control points. In the unlikely situation
* that the handles define a zero direction, fallback to using the direction defined by the
* first and last evaluated segments already calculated in #Spline::evaluated_tangents().
*/
void correct_end_tangents() const final;
void copy_settings(Spline &dst) const final;
void copy_data(Spline &dst) const final;
protected:
void reverse_impl() override;
};
/**
* Data for Non-Uniform Rational B-Splines. The mapping from control points to evaluated points is
* influenced by a vector of knots, weights for each point, and the order of the spline. Every
* mapping of data to evaluated points is handled the same way, but the positions are cached in
* the spline.
*/
class NURBSpline final : public Spline {
public:
2021-05-14 23:37:05 +02:00
/** Method used to recalculate the knots vector when points are added or removed. */
KnotsMode knots_mode;
struct BasisCache {
/**
2022-03-14 04:25:32 +01:00
* For each evaluated point, the weight for all control points that influences it.
* The vector's size is the evaluated point count multiplied by the spline's order.
*/
blender::Vector<float> weights;
/**
* An offset for the start of #weights: the first control point index with a non-zero weight.
*/
blender::Vector<int> start_indices;
};
private:
blender::Vector<blender::float3> positions_;
blender::Vector<float> radii_;
blender::Vector<float> tilts_;
blender::Vector<float> weights_;
int resolution_;
/**
* Defines the number of nearby control points that influence a given evaluated point. Higher
* orders give smoother results. The number of control points must be greater than or equal to
* this value.
*/
uint8_t order_;
/**
* Determines where and how the control points affect the evaluated points. The length should
* always be the value returned by #knots_num(), and each value should be greater than or equal
* to the previous. Only invalidated when a point is added or removed.
*/
mutable blender::Vector<float> knots_;
mutable std::mutex knots_mutex_;
mutable bool knots_dirty_ = true;
/** Cache of control point influences on each evaluated point. */
mutable BasisCache basis_cache_;
mutable std::mutex basis_cache_mutex_;
mutable bool basis_cache_dirty_ = true;
/**
* Cache of position data calculated from the basis cache. Though it is interpolated
* in the same way as any other attribute, it is stored to save unnecessary recalculation.
*/
mutable blender::Vector<blender::float3> evaluated_position_cache_;
mutable std::mutex position_cache_mutex_;
mutable bool position_cache_dirty_ = true;
public:
NURBSpline() : Spline(CURVE_TYPE_NURBS)
{
}
NURBSpline(const NURBSpline &other)
: Spline((Spline &)other),
knots_mode(other.knots_mode),
positions_(other.positions_),
radii_(other.radii_),
tilts_(other.tilts_),
weights_(other.weights_),
resolution_(other.resolution_),
order_(other.order_)
{
}
int size() const final;
int resolution() const;
void set_resolution(int value);
uint8_t order() const;
void set_order(uint8_t value);
bool check_valid_num_and_order() const;
int knots_num() const;
void resize(int size) final;
blender::MutableSpan<blender::float3> positions() final;
blender::Span<blender::float3> positions() const final;
blender::MutableSpan<float> radii() final;
blender::Span<float> radii() const final;
blender::MutableSpan<float> tilts() final;
blender::Span<float> tilts() const final;
blender::Span<float> knots() const;
blender::MutableSpan<float> weights();
blender::Span<float> weights() const;
void mark_cache_invalid() final;
int evaluated_points_num() const final;
blender::Span<blender::float3> evaluated_positions() const final;
blender::GVArray interpolate_to_evaluated(const blender::GVArray &src) const final;
protected:
void correct_end_tangents() const final;
void copy_settings(Spline &dst) const final;
void copy_data(Spline &dst) const final;
void reverse_impl() override;
void calculate_knots() const;
const BasisCache &calculate_basis_cache() const;
};
/**
2022-03-14 04:25:32 +01:00
* A Poly spline is like a Bezier spline with a resolution of one. The main reason to distinguish
* the two is for reduced complexity and increased performance, since interpolating data to control
* points does not change it.
*
* Poly spline code is very simple, since it doesn't do anything that the base #Spline doesn't
* handle. Mostly it just worries about storing the data used by the base class.
*/
class PolySpline final : public Spline {
blender::Vector<blender::float3> positions_;
blender::Vector<float> radii_;
blender::Vector<float> tilts_;
public:
PolySpline() : Spline(CURVE_TYPE_POLY)
{
}
PolySpline(const PolySpline &other)
: Spline((Spline &)other),
positions_(other.positions_),
radii_(other.radii_),
tilts_(other.tilts_)
{
}
int size() const final;
void resize(int size) final;
blender::MutableSpan<blender::float3> positions() final;
blender::Span<blender::float3> positions() const final;
blender::MutableSpan<float> radii() final;
blender::Span<float> radii() const final;
blender::MutableSpan<float> tilts() final;
blender::Span<float> tilts() const final;
void mark_cache_invalid() final;
int evaluated_points_num() const final;
blender::Span<blender::float3> evaluated_positions() const final;
/**
* Poly spline interpolation from control points to evaluated points is a special case, since
* the result data is the same as the input data. This function returns a #GVArray that points to
* the original data. Therefore the lifetime of the returned virtual array must not be longer
* than the source data.
*/
blender::GVArray interpolate_to_evaluated(const blender::GVArray &src) const final;
protected:
void correct_end_tangents() const final;
void copy_settings(Spline &dst) const final;
void copy_data(Spline &dst) const final;
void reverse_impl() override;
};
/**
* A collection of #Spline objects with the same attribute types and names. Most data and
* functionality is in splines, but this contains some helpers for working with them as a group.
*
* \note A #CurveEval corresponds to the #Curve object data. The name is different for clarity,
* since more of the data is stored in the splines, but also just to be different than the name in
* DNA.
*/
struct CurveEval {
private:
blender::Vector<SplinePtr> splines_;
public:
blender::bke::CustomDataAttributes attributes;
CurveEval() = default;
CurveEval(const CurveEval &other) : attributes(other.attributes)
{
for (const SplinePtr &spline : other.splines()) {
this->add_spline(spline->copy());
}
}
blender::Span<SplinePtr> splines() const;
blender::MutableSpan<SplinePtr> splines();
/**
* \return True if the curve contains a spline with the given type.
*
* \note If you are looping over all of the splines in the same scope anyway,
* it's better to avoid calling this function, in case there are many splines.
*/
bool has_spline_with_type(const CurveType type) const;
void resize(int size);
/**
* \warning Call #reallocate on the spline's attributes after adding all splines.
*/
void add_spline(SplinePtr spline);
Geometry Nodes: support instance attributes when realizing instances This patch refactors the instance-realization code and adds new functionality. * Named and anonymous attributes are propagated from instances to the realized geometry. If the same attribute exists on the geometry and on an instance, the attribute on the geometry has precedence. * The id attribute has special handling to avoid creating the same id on many output points. This is necessary to make e.g. the Random Value node work as expected afterwards. Realizing instance attributes has an effect on existing files, especially due to the id attribute. To avoid breaking existing files, the Realize Instances node now has a legacy option that is enabled for all already existing Realize Instances nodes. Removing this legacy behavior does affect some existing files (although not many). We can decide whether it's worth to remove the old behavior as a separate step. This refactor also improves performance when realizing instances. That is mainly due to multi-threading. See D13446 to get the file used for benchmarking. The curve code is not as optimized as it could be yet. That's mainly because the storage for these attributes might change soonish and it wasn't worth optimizing for the current storage format right now. ``` 1,000,000 x mesh vertex: 530 ms -> 130 ms 1,000,000 x simple cube: 1290 ms -> 190 ms 1,000,000 x point: 1000 ms -> 150 ms 1,000,000 x curve spiral: 1740 ms -> 330 ms 1,000,000 x curve line: 1110 ms -> 210 ms 10,000 x subdivided cylinder: 170 ms -> 40 ms 10 x subdivided spiral: 180 ms -> 180 ms ``` Differential Revision: https://developer.blender.org/D13446
2021-12-14 15:57:58 +01:00
void add_splines(blender::MutableSpan<SplinePtr> splines);
void remove_splines(blender::IndexMask mask);
void translate(const blender::float3 &translation);
void transform(const blender::float4x4 &matrix);
bool bounds_min_max(blender::float3 &min, blender::float3 &max, bool use_evaluated) const;
Geometry Nodes: new geometry attribute API Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is accessible from RNA and C code. The second is implemented with `GeometryComponent` and is only accessible in C++ code. The second is widely used, but only being accessible through the `GeometrySet` API makes it awkward to use, and even impossible for types that don't correspond directly to a geometry component like `CurvesGeometry`. This patch adds a new attribute API, designed to replace the `GeometryComponent` attribute API now, and to eventually replace or be the basis of the other one. The basic idea is that there is an `AttributeAccessor` class that allows code to interact with a set of attributes owned by some geometry. The accessor itself has no ownership. `AttributeAccessor` is a simple type that can be passed around by value. That makes it easy to return it from functions and to store it in containers. For const-correctness, there is also a `MutableAttributeAccessor` that allows changing individual and can add or remove attributes. Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer to the owner of the attribute data. The second is a pointer to a struct with function pointers, that is similar to a virtual function table. The functions know how to access attributes on the owner. The actual attribute access for geometries is still implemented with the `AttributeProvider` pattern, which makes it easy to support different sources of attributes on a geometry and simplifies dealing with built-in attributes. There are different ways to get an attribute accessor for a geometry: * `GeometryComponent.attributes()` * `CurvesGeometry.attributes()` * `bke::mesh_attributes(const Mesh &)` * `bke::pointcloud_attributes(const PointCloud &)` All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`. Differential Revision: https://developer.blender.org/D15280
2022-07-08 16:16:56 +02:00
blender::bke::MutableAttributeAccessor attributes_for_write();
/**
* Return the start indices for each of the curve spline's control points, if they were part
* of a flattened array. This can be used to facilitate parallelism by avoiding the need to
* accumulate an offset while doing more complex calculations.
*
* \note The result is one longer than the spline count; the last element is the total size.
*/
blender::Array<int> control_point_offsets() const;
/**
* Exactly like #control_point_offsets, but uses the number of evaluated points instead.
*/
blender::Array<int> evaluated_point_offsets() const;
/**
* Return the accumulated length at the start of every spline in the curve.
* \note The result is one longer than the spline count; the last element is the total length.
*/
blender::Array<float> accumulated_spline_lengths() const;
float total_length() const;
int total_control_point_num() const;
void mark_cache_invalid();
/**
* Check the invariants that curve control point attributes should always uphold, necessary
* because attributes are stored on splines rather than in a flat array on the curve:
* - The same set of attributes exists on every spline.
* - Attributes with the same name have the same type on every spline.
* - Attributes are in the same order on every spline.
*/
void assert_valid_point_attributes() const;
};
std::unique_ptr<CurveEval> curve_eval_from_dna_curve(const Curve &curve,
const ListBase &nurbs_list);
std::unique_ptr<CurveEval> curve_eval_from_dna_curve(const Curve &dna_curve);
std::unique_ptr<CurveEval> curves_to_curve_eval(const Curves &curves);
Curves *curve_eval_to_curves(const CurveEval &curve_eval);