You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tracking Issue: Design a new vector table-based data representation for paths, meshes, nondestructive styling, and appearance #2603
This is a WIP brain dump for a new stab at the generalized mesh vector format. More thought is needed, but I wanted to put this down here before I forget.
Tables
To illustrate the data dependencies amongst the proposed tables, each bullet point stores data referenced by its sub-bullet points.
Points
Paths
Bends
Stroke Styles
Fill Styles
Points
Points describe positions in the local coordinate space. On their own, they represent a point cloud.
Paths
Paths describe the graph connectivity by listing walks of points. Each path is a list (or sub-table?) of point ranges, each representing a polyline. At least two points must be part of a path. A closed path is one that returns to its start point, representing a face (in the context of a 3D mesh like an OBJ file describes). Collectively, all the paths represent a vector mesh of straight edges. Paths have one-to-one correspondence with an imported SVG's subpaths in terms of topology (at least, for closed or non-filled shapes). With branching topology, multiple open paths make up portions of the overall shape.
Bends
Bends describe the curvature associated with every edge in a referenced path. They can be various types, such as splines (no handles specified), linear (essentially a no-op), quadratic (one handle), cubic (two handles), or other more exotic curve types. Handle points are references into the points table. If two paths independently specify the same edge or edges, their associated bends may curve them differently from one another.
Stroke styles describe all the paths corresponding to a particular stroke's paint. Each one contains a list (or sub-table?) of every path given the same style. If the style needs to change along a path, that needs to be broken up into separate adjoined paths. This is also the level at which tapered/variable stroke widths (#2207) are described, as well as dashes, caps, joins, and markers.
Fill styles describe all the boundaries corresponding to a particular fill's paint (or no paint for unfilled space). Each one contains a list (or sub-table?) of every boundary. Boundaries can be entire paths, or specific ranges of segments within a path, or the first/last half of a single segment.
TBD: how does fill rule fit in, if that's applicable at the level of the whole shape? Maybe traditional SVG-style styling information and fill rule applies to a single Table<Vector> row while the full Table<Vector> uses the mesh fill strategy. So that might also mean some of the above descriptions need to be adjusted to work where mesh vector operates at the Table<Vector> level while possibly Vector only deals with non-branching paths?
changed the title [-]Vector mesh data structure design ideas[/-][+]New vector table-based representation design ideas for meshes, nondestructive styling, and appearance[/+]on Aug 6, 2025
changed the title [-]New vector table-based representation design ideas for meshes, nondestructive styling, and appearance[/-][+]New vector table-based data representation for meshes, nondestructive styling, and appearance[/+]on Aug 6, 2025
changed the title [-]New vector table-based data representation for meshes, nondestructive styling, and appearance[/-][+]Tracking Issue: Design a new vector table-based data representation for paths, meshes, nondestructive styling, and appearance[/+]on Aug 7, 2025
Activity
[-]Mesh vector data structure design ideas[/-][+]Vector mesh data structure design ideas[/+][-]Vector mesh data structure design ideas[/-][+]New vector table-based representation design ideas for meshes, nondestructive styling, and appearance[/+][-]New vector table-based representation design ideas for meshes, nondestructive styling, and appearance[/-][+]New vector table-based data representation for meshes, nondestructive styling, and appearance[/+]Keavon commentedon Aug 6, 2025
Additional considerations (moved from #2520):
[-]New vector table-based data representation for meshes, nondestructive styling, and appearance[/-][+]Tracking Issue: Design a new vector table-based data representation for paths, meshes, nondestructive styling, and appearance[/+]