GSoC 2021: Curve Improvements: Weekly Reports

Week 4 (June 28th to July 4th)

  • Some discussing took place regarding the shortcut for closing curves. There are several options for this but none of them seem optimal. It would be helpful to hear any thoughts regarding the following options or any other suggestions for a shortcut. Please post them in the feedback forum):
    • Ctrl + click and drag from one end point to the other: The issue with this is that both deleting a point and making a cut on the curve are assigned to Ctrl+Click.
    • Click end point consecutively to close the loop: The issue with this is that selecting a point is also set to left click. So if someone wishes to select an end point after another they would either have to select something else or deselect before selecting which isn’t too bad but it’s not too intuitive.
  • There was also a bit of discussing on what could be done for the problem of functionality being re
  • In a previous discussion it was decided to implement the “bevel-like rounding of curve corners” tool as a geometry node. Furthermore, it would be named as Curve Fillet. Accordingly, I would be following this design task for the implementation.
  • Started working on the Curve Fillet node. Took some time to familiarize myself with the geometry nodes code and the C++ curve data structures. Currently working on the implementation.

Couldn’t get a lot done during the last week due to exams. Hoping to catch up this week.

Plan for next week

  • Continue to work on the Curve Fillet node.
10 Likes

Hi Dilith, my name is Peter Pienkowski; I’m the technical director from Elliott Animation in Toronto, Canada. We are also working on curve tool improvements, similar to yours. I’d like to offer you to take a look at what we are doing and approaching our development. You might be interested in the curve cutting tools we have.

8 Likes

Hi, Peter. Thanks a lot for the offer! I think it would be very helpful to have a look at what you’re working on. Could you direct me to where I need to look? Thanks!

Hi Dilith, could you please email me at [email protected] I would like to send you some footage of what we have, and if anything catches your interest, we can take it from there.

1 Like

Week 5 (July 5th to July 11th)

For the entirety of this week I worked on the Curve Fillet node. So far, the following is the design for the node (Pay no attention to the names of the fields; they’ll probably change :slight_smile: ).

  • Mode can be one of 2 values:
    • Adaptive: This enables the Angle field. In this mode, the number of points per segment is automatically adjusted based on the angle formed by the corner.
    • User Defined: This enables the Count field. In this mode, the user can specify the number of points per corner and all fillets would have the same count.
  • Radius Mode can be one of 2 values:
    • Float: This enables the Radius field. This can be used to define the radius of the fillet formed. The float shall be used by all corners.
    • Attribute: This enables the Radii field. This can be used to specify the distribution of radii for the entire curve.
  • Currently, I am using the curve’s built-in radius attribute to create a custom attribute (because I had an issue where built-in attributes weren’t detected) which defines the fillet radius for each vertex (see gif below). Ideally, an independent attribute should be definable using which the fillet radius can be defined for each vertex.
  • At the moment, the implementation only supports addition of a single vertex but it should be able to support the addition of multiple vertices before long.

demo1

There is a minor issue (mathematically) where the ends of the created arc aren’t parallel to the adjacent sides (See bottom right vertex in the gif above). However, this should be a fairly straight forward fix.

Plan for next week

  • Fix the incorrect arc issue and issue with inability to accept built-in attributes directly.
  • Work on creating fillets with higher resolution arcs.
22 Likes

Week 6 (July 12th to July 18th)

  • Fixed previous week’s issues.
  • Added support to fillet Poly splines (See gif).
  • Added support for circular arcs with multiple points: both adaptive and user defined (demonstrated in the gif using Poly splines because it’s easier to notice the difference).

2021-07-19-08-28-12

As seen on the gif and in the image below, there can be situations where the specified radius cannot be fitted on to the given corner (note in the image that the radius is 1.380 while the height is only 1). The solution for this should be decided on. An option is to clamp the radius before it exceeds the maximum radius. Other suggestions are appreciated.

Plans for next week

  • Look into handling Bezier curves of auto and align types (currently, the result makes sense only for vector and free types) and NURBS curves.
  • Decide on what to do regarding radii that are too large.
  • Test Curve Pen tool and ensure functionalities work consistently.
25 Likes

Week 7 (July 19th to July 25th)

  • Added functionality for handling Auto and Align type handles (it may undergo further changes so I won’t post a video yet)
  • Searched on how NURBS curves can be filleted. The implementation isn’t trivial so currently it’s handled similar to Poly splines (which doesn’t give an exact circular arc). Eventually, it should support exact circular arcs, but with the time constraints, it may be looked into after the summer.
  • Tested Curve Pen and increased threshold for curve cut and vertex delete.

Plan for next week

  • Look into what changes need to be made to handle auto and align handles in the curve fillet tool.
  • Look into implementing additional features for the curve pen tool suggested by users. One such functionality I’ll be looking into would be to alter the curve by dragging the curve itself rather than using its control points.
26 Likes

Week 8 (July 26th to August 1st)

  • Added functionality to close a spline by selecting two end points consecutively. Note that this would mean that, in order to select an end point while the other endpoint is selected, the user has to select a different point prior to selecting the endpoint. (See first gif)
  • Added functionality to alter a segment by clicking and dragging on the spline. (See first gif)
  • Added a checkbox to limit the radius in the curve fillet node in case overlapping is undesirable. (See second gif. In it, I increase the float radius. Notice that the radius is skewed towards the larger angle when the radius increases a lot. This is because the smaller angle would reach its limit faster than the larger angle. I’ll be looking into this the coming week.)

pen_cycle_move

fillet_overlap

Plan for next week

  • Look into the limit radius behavior.
  • Begin submitting patches for code review.
23 Likes

Week 9 (August 2nd to August 8th)

  • Added support for Poly and NURBS curves in Curve Pen. All functionality works similar to Bezier splines without the handle interactions. For making a cut on a NURBS spline, the poly-like lines need to be Ctrl clicked instead of the spline itself.
    curve-pen-NURBS

  • Fixed the issue with limit radius behavior. The shape of a segment after hitting its limit would be dependent on the ratio between the radii of the adjacent control points. The control point with the larger radius would get a larger portion of the segment.

  • Submitted patches for the Curve Pen (⚙ D12155 Curves: Curve Pen) and Curve Fillet Node (⚙ D12115 Geometry Nodes: Add curve fillet node).

  • Created an Experimental Build for the Curve Pen (found in Blender Builds - blender.org under branch name: soc-2021-curves). Note that it currently doesn’t build on Mac due to a bug in the master branch. I’ll update this post once its ready. For now, it should work fine for Windows and Linux.

Plan for the next week

  • Make changes according to code reviews on the patches.
  • Further testing.
26 Likes

3 posts were merged into an existing topic: GSoC 2021: Curve Improvements: Feedback

Week 10 (August 9th to August 15th)

  • Most of this week was spent on improving the curve fillet node code based on feedback on the revision. However, most of these changes shouldn’t affect the overall behavior of the tool.
  • Made vertex dissolve as the default behavior of delete vertex in curve pen.
  • Fixed bug where cuts cannot be made near control points due to cut distance not scaling with zoom level.
  • Other refactoring of the curve pen code.

It’s officially the end of the coding period but there are still some improvements left to be made, mainly to improve the code quality based on feedback on the revisions. So that’s the main plan for the next week and likely a few weeks following the next. I’ll post updates here or the feedback forum if anything new happens. Hopefully, I’ll be able get these . Additionally, I hope that people would get a chance to test out the builds (both available at Blender Builds - blender.org under the names: soc-2021-curves for the curve pen and soc-2021-curve-fillet for the curve fillet node) and provide feedback on what needs to be improved and whether there are any bugs/issues. I likely won’t be making any large changes in the upcoming weeks but I’ll definitely try to fix any bugs that may be encountered. Thanks for all the support so far!

19 Likes

Nice job! Do you have any estimate when this functionality will land in the Blender Master?

Thank you! I think the curve fillet node might be merged fairly soon. I’m hoping within one or two weeks. The curve pen tool still has a fair bit to go. Not sure how long that’ll take since the focus was mostly on the curve fillet node so far (although there were a few improvements for the curve pen tool which I’ll summarize the next time I post). Hopefully, that too wouldn’t take too long :slight_smile:.

9 Likes

Thanks for the great work! :slight_smile:

3 Likes

@dilithjay
Dilith, thanks for your amazing job! I’m really thankful to you and I’m sure I’ll use your tools a lot in the future…
But now I only see chat about your GN fillet node (and I love that too) but your curve editing improvements are a god sent for practical use. Artists use chisels first and nodes (maybe) second :smiley:

20 days later, do you have a better prediction on the curve editing merge?

Also have you (all of you) thought about filleting just being simply accessible by a rounding parameter of a curve endpoint? (I mean a NEW parameter)
I see some contradiction to use a radius parameter for it (which is thickness) instead of a separate roundness parameter. And if the new parameter is present, it should really be accessible from edit mode. Because why set up a node network just for specific end point rounding?
Again, chisels VS whole new systems. :slight_smile:

I’m just thinking out loud here but I’m curious about your (and Hans’) opinion on this.

3 Likes

Thanks a lot for the kind words and the feedback!

Yes, that’s right. We’ve been focusing on getting the fillet node ready (which it almost is. The revision was accepted so it should be merged any day now) but I’ll definitely work on the curve pen next. Won’t abandon it :slight_smile:

However, since the code reviews haven’t exactly begun on the curve pen, I’m not certain as to how long it might take. Tools and geometry nodes are developed somewhat differently. I learned a fair bit of do’s and don’ts during the code review of the fillet node and there’s likely some of that for the tool as well so it may take some time but it should eventually get there :slight_smile:

I myself have not thought about it. Not sure how that might work since filleting creates new vertices and the parameter wouldn’t make sense on the new vertices. Either way, this seems like a fairly major design choice so I’ll leave it to someone more experienced.

The built-in radius parameter was just used for testing TBH. Also, there were several significant changes to the fillet node inputs (the task summary in ⚙ D12115 Geometry Nodes: Add curve fillet node should summarize the node). The radius and count, both accept fields now. I’m not too familiar with fields so I’m probably not the best to talk about it but I believe in the long run, it would make the inputs more flexible.

I agree with you on the point that being able to fillet from the edit mode would be very useful. I believe the node was given priority because a design task was already in place for it when I had started the project. There’s been a bit of discussion for porting it to the edit mode as a tool (along with some other nodes I believe). Hopefully, that happens before long. I think @HooglyBoogly would be able to give a better idea if he’s available.

2 Likes

Thank you for your in-depth reply!
I learned a lot about the internal discussions which is great.

"filleting creates new vertices and the parameter wouldn’t make sense on the new vertices"

I see now. This does makes sense in GN though as that’s parametric until applied.
Yeah in my mind (coming from 2D vector software) edit mode could also be parametric. Some software (like Affinity Designer) treat the new points conceptual and not selectable until applied (similar to GN) and some (like Illustrator) keeps it procedural just until you grab any point of the newly created ones (I believe this the dumb way of doing it and would make zero sense to Blender)

What do you think about this:
I think a possible way to port this to Edit mode would be a separate parameter but the moment you use it, Blender creates a GN modifier and updates it with everything you do in edit mode. It should be that simple. (similarly to for example how a new particle sim creates the corresponding modifier) Then you can apply it and get to the new points if you want.
Ah this would be a dream scenario!

I hope for the best for every topic you mentioned :slight_smile:

No problem!

Right, I could see this working. But adding a new parameter just to add a GN modifier feels a bit unnecessary to me (unless I misunderstood what you meant), especially since the same can be achieved with a few extra steps by adding a GN modifier manually. What do you think?
I think once ported, the tool would work a bit like the bevel tool (for meshes) where there’s a handle to adjust the radius. At least that’s how I imagine it would be.

Thank you! :slight_smile:

Well if you keep using the - currently available - radius parameter for it then what happens if a curve has thickness to it AND then I’d like to fillet some points in it?
Both very different options will be controlled by the same value?

I think it’s perfectly fine to have a new parameter for a new feature. The fact that GN works in the background shouldn’t mean it can’t be treated like a real feature.
Filleting curves was simply not a thing before in Blender. You made it. It deserves a parameter :smiley:

If GN is as fast and reliable as the devs currently think then imho this is true to other features (which could be exposed in the UI) as well.

The real problem is that curves don’t support generic attributes in edit mode. They have radius, tilt, and “Soft-body Goal Weight” that are sometimes interpolated correctly when making changes to the curve. But that’s it. If you want to store another value you have to add it everywhere in the code, it’s just not feasible. We can’t keep adding a new value to every curve control point every time we add some useful procedural feature.

That’s basically the reasoning behind the rewrite of curves for geometry nodes. Storing generic data per point is essential for a procedural data type.

So the way forward is to continue that transition until we can edit generic attributes in curve edit mode. This was also the reason why I suggested making curve fillet as a node instead-- it’s more future proof, and the same code can be used for edit mode when that’s possible.

14 Likes