Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendering the fills of vector meshes and intersecting paths #2309

Open
Keavon opened this issue Feb 21, 2025 · 0 comments
Open

Rendering the fills of vector meshes and intersecting paths #2309

Keavon opened this issue Feb 21, 2025 · 0 comments
Labels
Architecture Involves architecture or engineering work or discussion Graphics GPU and graphics programming related

Comments

@Keavon
Copy link
Member

Keavon commented Feb 21, 2025

Vector meshes generalize paths to support arbitrary topology. Loops of segments need a way of being rendered with a fill. This needs to support certain requirements, such as reasonable robustness during editing and animation.

The plan according to the current design is to define a filled region as the area bounded within a list of segments, taking into account each segment's winding order (flow direction or half-edge of a segment) to bound the curved area, akin to CSG. If a flow direction is backwards, it represents a back-face which isn't considered filled.

For example, the dots in the inside of this edge flow would indicate that the left lobe of the infinity shape should be filled as the front-face, while the right lobe's outer-facing dots would be considered a back-face and not filled.

Image

Uniquely identifying cubic Beziers isn't possible because there can be up to 9 intersections with 8 enclosed regions between a pair of them, compared to quadratic Beziers with 4 intersections and 3 enclosed regions. To address the boundaries of quadratics, cubics need to be considered as quadratics. This can likely be done (without actually subdividing the geometry) by addressing the starting or ending halves of a half-edge, splitting a segment up into four pieces. The midpoint of a half-edge is where the number of intersections is equal to half the total. The starting half reaches from the start to that middle intersection and the ending reaches from the end to the middle intersection, overlapping by a shared segment in cases with even numbers of intersections. A full explainer is at https://discord.com/channels/731730685944922173/731738914812854303/1341703079770193951 (and for @Keavon and @otdavies, this private Discord chat).

This drawing shows some unique addressing cases of each individual region. Red circles indicate midpoint intersections (from one or both of either curve).

Image

CSG boundary edges don't have to address just one region; they can also address a larger region while ignoring any intersections that aren't listed as boundaries. If, for example, the self-intersecting 4-region shape at the center right in the drawing above just had its full list of path segments used as its boundary, it might work similar to a regular SVG path (including a choice of fill rule)? (Or would that only count as enclosing the dark blue center region since only points in there would be enclosed by all segments? Hopefully not, so it can act like regular SVG complete with a choice of fill rule.)

@Keavon Keavon added Architecture Involves architecture or engineering work or discussion Graphics GPU and graphics programming related labels Feb 21, 2025
@github-project-automation github-project-automation bot moved this to Short-Term in Task Board Feb 21, 2025
@Keavon Keavon moved this from Short-Term to Medium-Term in Task Board Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Architecture Involves architecture or engineering work or discussion Graphics GPU and graphics programming related
Projects
Status: Medium-Term
Development

No branches or pull requests

1 participant