- Add path.intersectsBeam() method
- Add utils.beamIntersectsLine() method
- Simplify calculation and improve precision on beam intersections
- Document return types properly
- beamIntersectsCurve now uses the proper function from Bezier library instead of emulating it by constructing a huge line
- docs: path.intersect... methods never return false, they simply return an empty array in case of no intersection
In some edge cases, like when splitting a path on or very close to its
start or end point, `Path.split()` will return an array in which one of
the elements is not a Path object, but rather an empty array.
That is rather combersome to check for, so this changes that behaviour
and will return null for such cases.
I've also updated the documentation to clarify this behaviour.
Fixes#6816
This also fixes a bug when a path was being split on its end point.
The discussion in #5976 is whether `Path.join()` should use a line
segment to close any gaps in the path caused by move operations, or by
differences in the end and start points of paths being joined.
The answer is yes, that is the intended behaviour, but people who read
_join_ might expect differently.
So I have made a few changes to clarify this:
- The new `Path.combine()` method combines multiple path instances into
a single instance without making any changes to the drawing operations
- Since `Path.combine()` is variadic, I have also updated `Path.join()`
to be variadic too, since that is more consistent.
- The old way of calling `Path.join(path, bool)` is deprecated and will
log a warning. Calling `Path.join()` this way will be removed in v4.
- Related to this change is how `Path.length()` should behave when there
are gaps in the path. Currently, it skips those. So I've added a
parameter that when set to `true` will include them.
- Added documentation for `Path.combine()`
- Updated documentation for `Path.join()`
- Updated documentation for `Path.length()`
Note that the tests for Lumina are failing, but that's not related to
the chai upgrade, rather it seems these tests fail because of issues in
the design that we'll tackle later (it's a brand new design yet to be
released).
This moves resolving of the config from the pattern constructor to the
init() method. The idea is that adding a part to a pattern is exactly
the same as adding a part to a design. In other words, late-stage adding
of parts would be no different as the config gets resolved after that.
This is currently broken in many different ways, but the unit tests
particular to this new way of resolving the config do pass.
