GSoC 2025: Ergonomic API for Vector Mesh Topology

[indierusty]

My name is Priyanshu Raj and I've been selected as GSoC 2025 student developer to work on Graphite. Throughout the summer I will be working on creating an API for editing vector mesh topology.

Synopsis

The project aims to design and implement an ergonomic and efficient API for accessing, manipulating, and performing operations on vector data such that implementing complex vector based algorithms or developing tools to perform vector manipulations is efficient and ergonomic. The second aspect of the project is to enhance performance and stability by transitioning from Bezier-rs to Kurbo algorithms and data structures to perform vector operations.

Benefits

• Significant improvements in performance and reliability.
• An ergonomic API will simplify the development of advance vector mesh topology editing tools.

Deliverables

• An ergonomic API to access, manipulate and do vector operations will make it intuitive for developer to implement complex algorithms and add functionality to tools.
• Implementation of efficient data structures and algorithms will lead to better performance hence it will improve the user experience.
• Use of Kurbo API in place of Bezier-rs will lead to more maintainable and robust code.

[indierusty]

Community Bonding Period

In this three week time period I worked on refactoring code to use Kurbo instead of Bezier-rs. This resulted in significant performance and accuracy improvements while also fixing a few bugs.

Nodes refactored to use Kurbo API:

• 'Offset Path' node (Replace Bezier-rs use in the 'Offset Path' node with a Kurbo algorithm #2596)
• 'Solidify Stroke' node (Refactor the Solidify Stroke node implementation to use the Kurbo API #2608)
• 'Position on Path' and 'Tangent on Path' nodes (Refactor the 'Position on Path' and 'Tangent on Path' nodes to use the Kurbo API #2611)
• 'Sample Points' node (Refactor the 'Sample Points' node to use Kurbo instead of Bezier-rs #2629)
• 'Scatter Points' node (Refactor the 'Scatter Points' node to use Kurbo instead of Bezier-rs #2634, Fix 'Scatter Points' node artifacts #2657)

[indierusty]

Week 1:

• Explored different approaches and techniques to find the line between two connected segments for bevel algorithms, though I haven't found a good solution yet.
• Fixed a bug in the morph node implementation.
• Planned out some of the API to start with for the vector mesh and how I'd implement it considering the refactor.
• Refactored the 'Morph' and 'Bounding Box' nodes to use Kurbo instead of Bezier-rs.

[indierusty]

Week 2 update:

• Started to work on prototyping a data structure to represent a vector mesh.
• Worked on refactoring the 'Centroid' node to use Kurbo.
• Started to work with the help of @4adex on refactoring methods for modifying vector data such that the function returns the index of the vector data in the row of VectorDataTable instances.

[indierusty]

Week 3

This week I started off by implementing new nodes 'Path Length', 'Count' and 'Split Path' and then worked on the prototype for testing ideas and design for a fresh vector mesh representation that is easy to understand and work with for both the user and developers.

Implemented a basic vector path edit tool and structure for representing vector mesh in the prototype and implemented a few basic APIs for query and manipulation of the data.

While working on the prototype, I spent most of my time thinking about the structure for the vector mesh such that the data is represented as a table and is also efficient to access and manipulate for implementing APIs. Initially @Keavon suggested storing it as list of commands which describes the path like Kurbo does. Though this approach gives a simple way to represent the data I wasn't sure if implementing APIs with this would be efficient and also make it easier for the users to work with. I proposed to represent the vector mesh data as a list of points, segments, and attributes very similar to how it is represented currently. Then, while discussing my proposed idea, @Keavon suggested an even better approach which is to represent the segments components as columns in a table, just like attributes which feels like the best approach which works for the users and developers.

@4adex and I also diccused a new approach for filling the regions which is dynamic and created by the intersections of path segments in a mesh. The idea he proposed is to store the fill of the regions as a list of fill which is left or right of the subsegments that are part of that region and then compute the fills of each region by calculating the fill which is present in most of the subsegments that construct that region.