Turning brush strokes into polygons is fun, but what does a regular dab-style brush engine look like in the browser? brush-engine.vercel.app
This is a *much* easier problem than creating pressure-sensitive stroke polygons. All we do is repeat a texture (in this case, a circle) at a regular distances along a line, with the pressure (real or simulated) determining the size of the texture.
This is how apps like Photoshop or Procreate work. There's some interpolation between points in order to fill in the blank spaces—and you can use a lot more data to determine the texture's size, skew, opacity, etc—but that's the general idea.
The process normally produces a raster, but we may have better luck here in 3D-as-2D-land (I'm using @PixiJS for this demo), where we have more options to play around with geometry after the fact.
Quick evening experiment, lots more to explore.
smash that the Super Follow button
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Would you a design tool's exported code in a project?
Ok, some context. I've spent the week researching these kinds of features, maybe it'll help to tweet through it. 🧵
These days, we expect that a modern design tool will include some kind of "inspection" mode where a developer can view dimensions, export values for colors, typography, etc. Pretty basic but a dev can use this information in any kind of project with zero commitment.
pressure sensitive lines (drawing with iPad pencil)
In order to make this work, we start by capturing points from a mark.
We also capture a delta (the change between this point and the previous point), from which we can get a direction for each point. Here I'm drawing lines at each point with that point's direction rotated 90deg.
Aspect ratio resizing was breaking my head. I just couldn't figure out when to respect the user's height (and scale the width) vs. when to respect the user's width (and scale the height).
Long story short, remember the selection's initial aspect ratio (width / height, shown in green) and compare it against the current aspect ratio (pink). If the current ratio is greater than the initial ratio, we're tall so scale the height; otherwise, scale the width.
Flips also took a minute to work though. Depending on which dimension is being scaled, we need to offset a opposite point by the scaled width or height. Really visual problem—my comments have drawings in them.
Small fix: zooming in on arrows in @excalidraw no longer leads to clipped arrows.
(This is how it used to look.)
Since I have the GIFs, here's a quick explanation. When it comes time to draw an element, it is first drawn onto an off-screen canvas. This canvas is then composed onto the main canvas.
Hit testing against our axis-aligned rectangles is easy. Is the point left of the left edge? Right of the right edge, above the top, or below the bottom? If you answered yes to any of these questions then it's a miss; otherwise, it's a hit.
Our lines are more difficult. We want to score hits within a certain distance of the line so we need to turn the line into a box. If the line is straight then we test against a polygon (a potentially rotated rectangle). Trickier but not bad. Curved lines? Those are hard.
Experiment with adjustable arrows. The whole point of my arrows library was to avoid this kind of thing—and let the algorithm "guess" the best arc for an arrow, based on its distance—but this is useful too. 🏹🧵
For comparison, here's the same arrangements (almost) with the guessing algorithm in action.
The library has always supported two options: "bow" defines the minimum arc and "stretch" adds more arc to short arrows. The first GIF is essentially a UI to set the bow of arrows with no stretch. The second GIF is a set of arrows that all have the same non-zero bow and stretch.