GSOC 2021 Proposal Draft : Curve Improvements

Hello all, I have created a draft proposal for curve improvements and would like feedback and additional ideas that I could look into implementing over the summer. This is my first experience with any kind of professional software development so I’m going to apologize in advance for any glaring errors.

Curve Improvements Proposal


Cameron Mitchell



Blender ID/Dev: cmitchell

Github: clm101


The goal of this project is to add features to curves and to refactor the code to ease future development.


This project would provide an improved experience for both users and developers. For the users, there would be the addition of familiar polygon-based features(beveling, for example). There would also be added information that can help to influence design decisions, such as curve length. For developers, the current code would be refactored to improve readability and encourage future development.


  • Curve length calculation
  • Adaptive resolution
  • Control point insert/splitting (similar to Alt+D behavior when modeling)
  • Curve beveling
  • Additional user documentation for new features

Project Details

  • Curve length calculation: The calculation at least will be done in an iterative manner. An analytic approach to arc length will be taken when possible. The method used may vary with each kind of curve. The information will be displayed in the properties panel with the location, rotation, scale, etc information. If an iterative method is used, then the option to increase or decrease the precision could be exposed.
  • Adaptive Resolution: When converting to a mesh, an adaptive resolution option will be added to the pop-up menu. The purpose of this option is to preserve detail in locations with high curvature. The meaning of “high curvature” will be user-adjustable. Currently, the planned implementation is to determine the difference between the tangent of the previous point and the current location on the curve. A vertex will be placed once the difference reaches a variable threshold. In cases of curves containing both high amounts and low amounts of curvature, the decision of whether or not to place a vertex on a curve at a location can also be dependent on the length of curve traversed since the last vertex.
  • Control point insert/splitting: When modeling using a mesh, Alt + D adds a vertex at the location of the currently selected vertex. This functionality will be extended to curve control points. The new control point will have the same tangent as the selected point. In the case of a control point being added from a control point with two adjacent control points, the new point will have the selected control point and one of the two adjacent ones as its adjacent points. Pressing the shift key prior to placing the new point will place it with the selected point and the other adjacent point as its adjacent points. This functionality is contrasted with extruding a control point with two adjacent points where two new control points are placed with one being locked to the cursor and the other, new point being added on top of the selected point.
  • Curve beveling: The functionality of curve beveling is similar to the behavior of adding a new control point using Alt + D except the selected point’s tangent will be changed so there is a constant angle step from one adjacent point to another across the two interior points. The behavior would be similar to the bevel modifier used on meshes. The control points would not be affected. This feature will not be implemented as a modifier to avoid confusion with mesh beveling behavior. Instead it will be as a right-click menu option with adjustable parameters provided in a collapsible panel in the lower left corner of the viewport.

As currently planned, beveling would change the shape of the curve. If this is determined as undesirable, it would be implemented to allow for the shape of the curve pre-bevel to be preserved.

  • Documentation and Extras: Throughout development, the accompanying documentation will be written alongside the code. I, likely naively, do not anticipate the features and changes to take the entirety of the allotted time so at the start of the summer I will put out a call for extra features/changes and upon completion of curve beveling I will begin to implement the requests, if possible. One possible idea I have seen online is enabling the shrinkwrap modifier for curves( Since this feature would require me to also become familiar with the modifier code, I am not sure if I would have time to implement it. This also seems to require mostly work with the modifier code so it is arguably outside of the scope of this project.
  • Refactoring: As I get more comfortable with the codebase and get more experience with implementing features, I will start to refactor the current code. As of right now, I don’t have any concrete plans as to the changes I will make.

Project Schedule

For June only, I will not be able to devote full time to this project, but in July/August I will be full time on this project. I will be able to work on the weekends and from late afternoon to evening during the week in June.

May 22-31: Become familiar with the current code

June 1- 14: Add curve length calculations

June 15-30: Implement adaptive resolution

July 1-22: Add curve beveling tool

July 23-August 16: Document changes and implement more user-requested features


I am an undergraduate Computer Science student at Louisiana Tech University. I also have minors in Math, Physics, and Electrical Engineering. I am experienced in C++, C, and Python. I have varying degrees of experience with Java, ML, Assembly, and Prolog.

Between school and work, I have not been able to commit much time to using or developing Blender. With that said, I have completed a few tutorials, including the infamous donut tutorial, and have watched many so I have observed different workflows. I have also periodically spent time reading Blender’s source code to learn how it starts, how it creates meshes, how the node system works, etc.

I enjoy learning about physics-based simulations and hardware acceleration. On my Github I have two projects that I work on when I have free time: a gravity simulator and a hardware-accelerated ray tracer implemented on an FPGA. Unfortunately, between school and work, I am not able to commit as much time as I would like to these projects. I am planning on reducing the amount of time spent working at the end of April to devote more time to learning the Blender codebase and working on my projects. I have been looking to get more experience in professional software development and believe completing this project is within my abilities.


I’ve been using poly type curves a lot recently and being able to bevel them without constant curve-mesh-curve conversions will be a huge time saver :heart:

1 Like

im here for that alt+d implementation lol, thanks
also if you need any basic things to add or practice on you can check right click select too

Segment highlight on Curves much as Edge highlighting on Faces when a Point is selected — Blender.Community

1 Like

Hi, thanks for sharing your proposal here. My first reaction is that you’re planning to take on too much here. This stuff will almost always take longer than you think. This matters even more when GSoC is only part time this year.

However, my larger concern is that some of these changes conflict with work I’m doing on curves currently. Currently there is some design / planning for adding curve support to geometry nodes. You can find the design here:

Then, everyone basically agrees that the current curve code is messy, and in need of a refactor. So I took this as an opportunity to improve the code with a new implementation. You can find a task to track the work here: T87245: Geometry Nodes: Curve Support Implementation. I’m using C++ here with some more modern / efficient architecture that should be much better in the end.

I don’t speak for everyone here, and I’m obviously biased since I’m the one working on this refactoring, but I would personally much rather see most of these changes like this be done in the context of the above task, rather as iterative changes on the existing code.

This idea was added to the list when the plans were less solid, so sorry for the confusion. However, I think there is still room for a project here. By the summer these changes might be a lot further along, so one option is to work with the new curve code. Though it’s not absolutely certain what the status of the branch will be. Another option is to find the space of least overlap with the plans above and work there. That is likely the curve edit mode changes you propose, though I still have some of the same reservations about that.


I’m happy to see you want to add all these indeed needed functionalities, but for me Curve editing lacks extremely important features like the ones described in this RCS proposal here:
The current way of editing a curve/adding new points is very frustrating to me, and the proposal describes important basic features that curve editing should have. The tool that is currently closer to these functionalities is the draw tool, but it’s still far from ideal. I hope this will be considered by either you or the devs (@HooglyBoogly do you think the suggestions of the proposal can be taken into account for the work you want do on curves?), thanks anyway for wanting to commit your time on this task!


Thank you for critiquing my proposal. I’ve looked at what you’ve linked and I’m going to spend some time looking into the items on your task. I would like to work with you to determine which tasks you feel are the least intrusive on what you’re working on or the most beneficial to you. Do you believe that I should focus more on working on the items listed in your task?

I see the length attribute in the task you’ve linked; does it refer to the number of control points on a curve or the arclength of the curve? I spent a bit of time looking at the geometry-nodes-curve-support branch and it looks like the former but I very likely could have been looking in the wrong place.


Take a look, maybe you can include/revive/refactor this one too:

1 Like

That specific proposal doesn’t overlap too much with what I’m working on for now, which is more of the procedural / evaluation side of things. Eventually I would hope to transition edit mode operations to the new data structures, but not quite yet. So something like that may be a better fit for a GSoC project in the near future.

Since I’m actively working on some of them it may evolve quite a bit, but I think there is probably room to work on more procedural features that would fit into a node context. The issue is that design is not as obvious here after you go beyond existing features.

Both are rather trivial to expose in the spreadsheet, and they will both be available. So far I’ve implemented an arc length read-only attribute.