My topic is a compound question with multiple parts.
I have read the contribution document and its 3 golden rules:
- You cannot add code that will break backward compatibility
- You cannot add code that will slow down the rendering process
- You cannot add code that will make things complex to use
Firstly, how would I benchmark against rule #2?
I would like to contribute support for the following curve type, as mentioned in the wiki entry for Cubic Hermite Spline: Kochanek–Bartels spline - Wikipedia
Secondly, is there a particular reason this curve type has been omitted?
The ability to return a Catmull-Rom by setting tension, continuity, and bias to zero does present a redundancy.
In the event this curve type has been redacted due to noncompliance with rules #2 or #3, I’d like to make a case for its inclusion.
With regard to golden rule #1:
- The curve itself is an extension of the Cubic Hermite Spline, which can also be simplified as a series of Cubic Bezier Curves using Bernstein polynomials. This means that the Kochanek-Bartels Spline, as a curve type, would build upon current curve types and reside in parallel to them, rather than break backward compatibility.
With regard to golden rule #2:
- Because this curve is effectively an extension of existing curve types, their rendering code can and would be used to draw this curve type. This means that already vetted rendering routines would not slow down the rendering process.
With regard to golden rule #3:
- Simplicity and usability is the only aspect that presents a challenge. Namely, this curve type is inherently complex when compared to the other curves already supported. This challenge could be resolved via naming conventions for its properties that would be more descriptive than mathematically opaque.
General use case:
The Kochanek-Bartel Spline curve type would allow for the instantiation of complex open- and closed-path shapes that contain both round- and sharp-edged details within a single Curve3 object; as defined by a series of Vector3 points and their complementary parameters, if any.
The key difference that separates this curve from the other currently supported types is that the entire path can be parametrically interpolated through manipulations of the extended parameters. This makes said interpolations simpler and more efficient to implement – in theory.
Thanks for reading.