Contribution Discussion: Kochanek-Bartels Spline

My topic is a compound question with multiple parts.
I have read the contribution document and its 3 golden rules:

  1. You cannot add code that will break backward compatibility
  2. You cannot add code that will slow down the rendering process
  3. 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. :smiley_cat:

1 Like

I like the attention to detail and thought that you’ve put into this! Being able to parametrically combine curves and corners is, well, it’s sharp :laughing::sunglasses:

You make a solid argument for its inclusion in points 1 and 2, but I think (and this is just my opinion, it doesn’t count for much!) that the third point is where the decision would hinge on. If you can prove out the two general use cases you outlined (I might suggest using the Playground) I think it will essentially answer by example the usability and complexity question as well as allow iterative design and feedback.

It’s possible that you do this and the decision is still ‘no’, but even so you’ll still have a good handle on why - and a component you can still use in your own project in the least!

HTH

1 Like

@jelster Thanks for your response,

I will have to do some thorough testing in the playground as you suggest before I embark on this. Mainly because I’ll need to walk through the concepts involved in a more practical capacity to fully grasp them. It’s one thing to write about them and quite another to turn the nuts and bolts.

I do hope that I can reach an actionable solution to this because of the creative and expressive possibilities that it would provide the average user. Plus, a chance to add my little piece to an open source project I love is exciting all on its own. :smiley:

Thanks again, I have my work cut out for me. :rocket:

1 Like

As do we all :slightly_smiling_face: but the great thing I’ve found about the BJS community is that people are happy to lend a hand!

Keep us updated on your progress, please!

1 Like

@jelster Of course! :smiley_cat:

This sounds like a perfectly thought through reflection and yes it would be great to have this new addition to the framework :slight_smile:

Feel free to make a PR, thanks a lot for the contrib !!!

I can’t agree more!