Skip to content

Vector mesh data structure design ideas #2603

Open
0 of 2 issues completed
Open
Task
0 of 2 issues completed
@Keavon

Description

@Keavon

This is a WIP brain dump for a new stab at the generalized mesh vector data 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 VectorData while the full VectorDataTable 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 VectorDataTable level while possibly VectorData only deals with non-branching paths?

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    ArchitectureInvolves architecture or engineering work or discussionGraphicsGPU and graphics programming related

    Type

    Projects

    Status

    Short-Term

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions