Skip to content

Tracking Issue: Design a new vector table-based data representation for paths, meshes, nondestructive styling, and appearance #2603

Open
1 of 5 issues completed

Description

@Keavon

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

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

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?

Activity

  1. added
    ArchitectureInvolves architecture or engineering work or discussion
    GraphicsGPU and graphics programming related
    on Apr 21, 2025
  2. added theissue type on Apr 21, 2025
  3. changed the title [-]Mesh vector data structure design ideas[/-] [+]Vector mesh data structure design ideas[/+] on Apr 24, 2025
  4. 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
  5. 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
  6. Keavon commented on Aug 6, 2025

    @Keavon
    MemberAuthor

    Additional considerations (moved from #2520):

    I originally wrote this down January 2024, but I've transferred this here now for easier reference.

    Partially related to #2522, #2309, #1832, #1834, #950.

    • Data-oriented design (struct of arrays)
    • Harmony with Vello’s GPU-based pipeline
    • SIMD and compute shader friendliness
    • Sequential (like SVG) vs. index buffer (like OBJ) approach
    • Short-term: vector paths (SVG-style open or closed paths)
    • Long-term: vector meshes (points, segments, and regions)
    • Segments representing any curve spline type
    • Basing paths around segments or manipulator groups
    • Relationship between anchors and handles
    • Columns for attributes (and custom attributes for passing along any info like color palette or other variables)
    • Open or closed faces
    • Subpaths
    • Fill rule
    • Winding order
    • Styling with fill
    • Styling with stroke
    • Stroke taper
    • Stroke being affected by parent groups that impose a stretch/skew transformation
    • Stroke caps/joins varying per-point
    • Avoiding cloning per node
    • Integration of monadic attributes into the graph
    • Copy on write attributes
    • Lazy evaluation of whole attributes (columns) or ranges (rows)
    • Propagating parametric modeling constraint relationships
    • Be a superset of a 3D mesh (including a Z axis) to support 3D to 2D vector flattening
    • Vector mesh depth sorting in the event of overlapping faces
    • Support for a bisection style drawing approach shown in https://www.youtube.com/watch?v=EZLEkhxiw9o
    • Support for a Shape Builder tool and Trim tool where you draw cuts through segments
  7. 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
  8. moved this from Short-Term to Ongoing Projects in Task Boardon Aug 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ArchitectureInvolves architecture or engineering work or discussionGraphicsGPU and graphics programming related

    Type

    Projects

    • Status
      Ongoing Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions