Make the functions more flexible and more generic by changing the curves
arguments to the curve offsets. This way, theoretically they could become
normal utility functions in the future. Also do a consistency pass over
the algorithms that generate new curves geometry for naming and
code ordering, and use of utility functions. The functions are really
quite similar, and it's much easier to tell this way.
The default when there is no cyclic attribute is that none of the curves
are cyclic. In the mesh to curve node, avoid creating the attribute with
just false to save time and memory usage. Also avoid looking up the
attribute twice in the trim node.
Standardizing the process of creating a new CurvesGeometry with
different curve sizes based on an existing curves is helpful, since
there are a few methods to simplify the process that aren't obvious
at first, like filling the offsets with sizes directly and accumulating
them to become sizes.
Also, in the trim curves node, avoid creating the curve types attribute
all the time. Use the special API functions for the types which do
some optimizations automatically. Also use a more consistent
method to copy the curve domain data, and correct some comments.
The same logic from D17025 is used in other places in the curve code.
This patch uses the class for the evaluated point offsets and the Bezier
control point offsets. This helps to standardize the behavior and make
it easier to read.
Previously the Bezier control point offsets used a slightly different standard
where the first point was the first offset, just so they could have the same
size as the number of points. However two nodes used a helper function
to use the same `OffsetIndices` system, so switch to that there too.
That requires removing the subtraction by one to find the actual offset.
Also add const when accessing data arrays from curves, for consistency.
Differential Revision: https://developer.blender.org/D17038
This changes how we access the points that correspond to each curve in a `CurvesGeometry`.
Previously, `CurvesGeometry::points_for_curve(int curve_index) -> IndexRange`
was called for every curve in many loops. Now one has to call
`CurvesGeometry::points_by_curve() -> OffsetIndices` before the
loop and use the returned value inside the loop.
While this is a little bit more verbose in general, it has some benefits:
* Better standardization of how "offset indices" are used. The new data
structure can be used independent of curves.
* Allows for better data oriented design. Generally, we want to retrieve
all the arrays we need for a loop first and then do the processing.
Accessing the old `CurvesGeometry::points_for_curve(...)` did not follow
that design because it hid the underlying offset array.
* Makes it easier to pass the offsets to a function without having to
pass the entire `CurvesGeometry`.
* Can improve performance in theory due to one less memory access
because `this` does not have to be dereferenced every time.
This likely doesn't have a noticable impact in practice.
Differential Revision: https://developer.blender.org/D17025
Trim erronously samples the next to last control point when it should
sample the last control point on the curve. This only happens when
reducing the curve to a single point. These changes should correct
the behavior.
Differential Revision: https://developer.blender.org/D17003
Previously, the lifetimes of anonymous attributes were determined by
reference counts which were non-deterministic when multiple threads
are used. Now the lifetimes of anonymous attributes are handled
more explicitly and deterministically. This is a prerequisite for any kind
of caching, because caching the output of nodes that do things
non-deterministically and have "invisible inputs" (reference counts)
doesn't really work.
For more details for how deterministic lifetimes are achieved, see D16858.
No functional changes are expected. Small performance changes are expected
as well (within few percent, anything larger regressions should be reported as
bugs).
Differential Revision: https://developer.blender.org/D16858
Adjusts behavior for trimming Bezier curves, specifically the outer
Bezier handles for the endpoints which do not influence the actual
curve. Handles are only adjusted if they lie within the same segment
with at most one endpoint being a control point (unless they are the
same in which handles are set to the point itself). The result yields
a curve in which the trim result can be inverted by re-setting the
cyclic property for the curve using 'Set Spline Cyclic' node
(iff both trim endpoints lie within a segment).
Differential Revision: https://developer.blender.org/D16488
Correct trim for cyclical curves mentioned in T101379, splitting the
curves if the start/endpoint is at the 'loop point'.
Correct implementation based on comments in D14481, request was made to
use 'foreach_curve_by_type' to computing the point lookups.
Included corrections from D16066 as it may not be a adopted solution.
Exposed selection input by adding it as input to the node.
Note: This is disabled for 3.4 to avoid making UI changes in Bcon3.
Differential Revision: https://developer.blender.org/D16161
The trim functionality is implemented in the geometry module, and
generalized a bit to be potentially useful for bisecting in the future.
The implementation is based on a helper type called `IndexRangeCyclic`
which allows iteration over all control points between two points on a
curve.
Catmull Rom curves are now supported-- trimmed without resampling first.
However, maintaining the exact shape is not possible. NURBS splines are
still converted to polylines using the evaluated curve concept.
Performance is equivalent or faster then a 3.1 build with regards to
node timings. Compared to 3.3 and 3.2, it's easy to observe test cases
where the node is at least 3 or 4 times faster.
Differential Revision: https://developer.blender.org/D14481
