`CubicBezier` should not allow constructing discontinuous curves
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## What's wrong?
[`CubicBezier`](https://docs.rs/bevy/latest/bevy/math/cubic_splines/struct.CubicBezier.html) says that it produces continuous output, but it actually just constructs a bunch of cubic Bézier segments which *a priori* have nothing to do with each other. The problem is that its input is essentially a `Vec<[P; 4]>` — an array of quadruples of control points which it takes ownership of:
```rust
/// Create a new cubic Bezier curve from sets of control points.
pub fn new(control_points: impl Into>) -> Self {
Self {
control_points: control_points.into(),
}
}
```
Each quadruple of control points is then used to construct a single `CubicSegment`. The problem here is that the guarantees from the Bézier construction do not relate these sets of control points to each other at all. For instance, the first segment of the curve will end at the last control point of the first quadruple and start at the first control point of the next.
Generally, the expectation for this kind of construction is that the last control point of one quadruple is the same as the first control point of the next. Thus, the correct input data to such a construction is actually `4 + 3k` control points, and the output is actually guaranteed to be continuous from the inputs alone.
In case users *actually* want to construct arbitrary unions of Bézier segments for some reason, that should be done through `CubicCurve` or `CubicSegment`. (I am not sure this is very ergonomic right now, but it probably does not need to be.)
Contributor guide
Research direction
Start with the CubicBezier API described in the issue and compare it with CubicCurve and CubicSegment to understand the intended construction paths. Done means CubicBezier accepts the stated 4 + 3k control-point relationship and guarantees continuous joins, with coverage for discontinuous input.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- computer-graphics
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100