Render vector mesh fills more correctly as separate subpaths

[iamthenoname]

Resolves #3378

Using the SVG renderer:

Using the Vello renderer:

The render_svg and render_to_vello functions have become a bit complex and hard to follow, but I plan on improving this after this change has been settled.

[Keavon]

Could you please estimate (as a percentage, or feel free to explain in more detail) how much of this is LLM-authored versus authored directly by you?

[iamthenoname]

I'd say around 60% was AI, and 40% was from me.

I didn't use any LLM assistance whatsoever for the rendering code.

For the algorithm itself I implemented it myself first, then had it go through an LLM to check for optimization issues (although I'll admit the LLM did most of the work here).

Admittedly I also got lazy with the follow-up changes and used the LLM to implement those as well. I've been experimenting with these tools recently and wanted to see how effective they would be.

If there's any concerns with the LLM use I'll be toning it down and redoing it myself. I apologize for not making this clear.

[Keavon]

Ok, thanks for clarifying and explaining your process. I noticed the prompt files you committed and got concerned that a greater share of the implementation was written without human control than I'd initially expected. The important part is that the actual thought process is yours and the code that's produced is a representation of your engineering competency, so it's not done without a human in the loop. I'm not as concerned about its help doing trivial things like writing the actual characters of code or applying code review style change requests or tab-completing the rest of your lines of code. But beyond trivial uses like tab-completing, we ask that you always disclose LLM authorship so it is clear how that may affect quality, which is crucial information to have when approaching a code review.

[Keavon]

!build

[github-actions[bot]]

📦 Build Complete for 169ddb12a41b4a2bdc747007c2a28223898ef6a4
https://1b86b5c3.graphite.pages.dev

[liunicholas6]

Update: I should have sketched out a few more examples and read the blog post before reviewing.

Derivative angle should actually be the only value used for the sort key for determining being "rightmost", not just the tiebreaker like I initially assumed.

I should have sketched out a few more examples and read the blog post before reviewing.

Additionally, the hack using the derivative at the end instead of the start breaks as many self-intersecting cases and can be ignored.

Apologies for the error

[iamthenoname]

Update: I should have sketched out a few more examples and read the blog post before reviewing.

Derivative angle should actually be the only value used for the sort key for determining being "rightmost", not just the tiebreaker like I initially assumed.

I should have sketched out a few more examples and read the blog post before reviewing.

Additionally, the hack using the derivative at the end instead of the start breaks as many self-intersecting cases and can be ignored.

Apologies for the error

I see, I'll fix this as well. I'll be working on making tests to make sure that the algorithm is working properly.

[Keavon]

@iamthenoname would you be willing to open up commit access to @liunicholas6 who was requested to collaborate with you on this PR's code? You can do that by inviting him to have write access to your fork's repo in its settings page. If you're willing, of course.

[iamthenoname]

Alright, I've added @liunicholas6 as a collaborator.