Attribute-based vector format refactor

[0HyperCube]

Closes #811

[Keavon]

This looks like a great start to making this all spreadsheet-based in the near future! Can't wait to have a spreadsheet view and the ability to tack on extra columns and read from those in nodes throughout the graph.

• I notice that we don't store handles as PointIds in the point domain, instead we use the DVec2s in Bezier-rs. I assume that's a temporary simplification. I'm just making a note of it here as a reminder that we'll want to address that in the future.
• We'll want to reenable the Morph node soon. It doesn't have to block this merging either, but I'm also just making a note here.
• It's unclear to me how/why the demo artwork, which hasn't been upgraded to the new format, still works. I notice we're still storing on VectorData both the original subpaths field (that hasn't been removed) and the three new point_domain/segment_domain/region_domain fields. Is the data being stored redundantly in both formats for now, I presume? Would you say that the plan is to remove the subpaths field in the future?

Those are my only three comments! None are merge blockers. I just need to do my QA testing now that I finished reading the code changes. Impressive work here.

[TrueDoctor]

I'm wondering if it makes sense to use the squared distance here instead to reduce the number of square root computations, the algorithm should still converge, but the convergence could be faster, thoughts?

[0HyperCube]

I'm not sure what you mean? (a+b)(a+b) ≠ a*a+b*b.

[TrueDoctor]

I'm basically suggesting to replace distance with distance_squared and then only computing the square root at the end. Let c = ((dist₀₂)² + (dist₀₁)² + (dist₁₂)²) / 2. Then dist₀₂ <= √c <= (dist₀₁ + dist₁₂).

[TrueDoctor]

But to be clear, this is in no way a release blocker, more of a "I'm wondering if this could be a future performance improvement"

[Keavon]

I tested for regressions from the nodes listed as changed within vector_nodes.rs. There is one recurring issue I found which becomes obvious when we use the primitive shape tools (Rectangle, Ellipse, and the Polygon tool's Ngons/Stars) which produce the unit-shapes with a non-1x1 Transform node that scales them up. These nodes seem to be using the non-scaled tiny shape rather than the transformed version for their calculations.

Here's a video showing this with the Repeat node:

capture_2_.mp4

Here's a list of all the nodes this happens with:

• Repeat
• Sample Points
• Poisson-Disk Points

I also noticed the LengthsOfSegmentsOfSubpaths node in vector_nodes.rs. I haven't checked this one specifically, since we only use its proto node for internal purposes, but I see potential for this to have the same problem as the others, maybe? Just mentioning it so you can investigate it together with the three above.

And there's also one node which seems to actually have been fixed from previously broken behavior:

• Circular Repeat: this is also different from master for the same reason as above, but the exact opposite. The new behavior is the desired one. Previously, the Radius parameter had to be really small if working with a unit-sized shape like this unit star.

I don't notice any other issues, so if you're able to fix the three nodes here, we should be good to merge! Thank you for all your hard work on this.

[Keavon]

My comments are minor enough that they don't need to be merge blockers. Feel free to merge this anytime.