Open carewolf opened 6 years ago
I've given thoughts to this at times. I'd do it in addition rather than instead (if you don't need the computational overhead of a rational Bezier, no need to pay for it).
Given that I'd keep the basic Beziers and that, to me, NURBS would add even more value, do you think there's a significant enough benefit to having rational Beziers instead of NURBS?
The obvious answer is the same as I provided for keeping simple Beziers (only pay for what you want/need). But I also need to take into account keeping the API as compact as possible. Additionally, if adopted, this will be a TS initially such that if user feedback is that they want rational Beziers in addition to NURBS (and that they want to have standardized 2D graphics) it would almost certainly be added.
I lean strongly towards NURBS. After simple Beziers, NURBS are the next most used/required feature in the realm of "curves" in my experience.
As a follow up, if you agree that NURBS are better to have than rational Beziers, are you willing to create a fork, implement a NURBS figure_item using cairo, and the submit a pull request that I could integrate? (It'd need to be under the same license as this project, i.e. the BSL 1.0). The biggest reason that something like this isn't yet in the proposal is that I haven't been able to spare the cycles to implement a NURBS figure item using cairo's line and cubic Bezier interface. It'd actually be several figure items, of course. One to begin it, control points, knots, and an end marker.
If you can spare the cycle to work on an implementation, that would be awesome and I'd gladly make time to work with you on API design issues, etc.
Best regards,
-Mike
On Montag, 27. November 2017 02:41:11 CET Michael B. McLaughlin wrote:
I've given thoughts to this at times. I'd do it in addition rather than instead (if you don't need the computational overhead of a rational Bezier, no need to pay for it).
Given that I'd keep the basic Beziers and that, to me, NURBS would add even more value, do you think there's a significant enough benefit to having rational Beziers instead of NURBS?
The obvious answer is the same as I provided for keeping simple Beziers (only pay for what you want/need). But I also need to take into account keeping the API as compact as possible. Additionally, if adopted, this will be a TS initially such that if user feedback is that they want rational Beziers in addition to NURBS (and that they want to have standardized 2D graphics) it would almost certainly be added.
I lean strongly towards NURBS. After simple Beziers, NURBS are the next most used/required feature in the realm of "curves" in my experience.
As a follow up, if you agree that NURBS are better to have than rational Beziers, are you willing to create a fork, implement a NURBS figure_item using cairo, and the submit a pull request that I could integrate? (It'd need to be under the same license as this project, i.e. the BSL 1.0). The biggest reason that something like this isn't yet in the proposal is that I haven't been able to spare the cycles to implement a NURBS figure item using cairo's line and cubic Bezier interface. It'd actually be several figure items, of course. One to begin it, control points, knots, and an end marker.
If you can spare the cycle to work on an implementation, that would be awesome and I'd gladly make time to work with you on API design issues, etc.
I think NURBS might be too different. If you want to implement them, they are superior, but I suggested rational bezier because they are mimally different, and have a minimal overhead (just one extra weight for the cubic version), and solves the two biggest problems with bezier curves in the 2D rendering engines today, perspective transforms, and circle painting. The biggest problem with rational beziers is that they are easier to due for cubic bezier curves, and more complicated with quadratic. So if you want both quadratic and rational beziers, it takes bit more work. (At least if I remember correctly, or maybe how to do it with quadratic curves was just not readily available anywhere, and I had to do the math myself.)
I might have some time around Christmas, and I will see if I can dig up what I did last time I tried doing this for Qt. I was stopped back then because I couldn't do it due to API and ABI stability, which is why I wanted to suggest it to you early, so you don't get trapped the same way.
'Allan
Rational bezier curves are curves where the control point(s) has an extra weight. There are two stong benefit of rational bezier curves over basic bezier curves: a) They can represent all conic arcs accurately. This makes arc a special case of bezier curves, and possible to represent it internally as a single bezier curve. b) They are stable under projection transformation. You do not currently have 3D transforms in the library, but if you had, then bezier curves would be broken by them, and need to split or rasterized after a projection transform, but rational bezier curves can be transformed under any 3D transform and still be a rational bezier curve.