[p5.js 2.0+ Question]: Stroke Scaling is Different in p5 WebGL and WebGPU

[quinton-ashley]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• WebGPU
• p5.strands
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

Any

Web browser and version

Any

Operating system

macOS 26.5

Steps to reproduce this

Is stroke scaling in p5 WebGL and WebGPU incorrect?

https://editor.p5js.org/quinton-ashley/sketches/ddhGfhknv

[davepagurek]

Apologies in advanced, this one's a little more involved than it just being a bug fix that's required!

For some context, the current state of strokes in WebGL/WebGPU is different than 2D mode as a sort of compromise between standard 2D usage and standard 3D usage. 2D mode works as you describe, with scale affecting everything. In 3D systems, there is often a different mental model: rather than the stroke being part of the geometry that scales uniformly, the stroke is kind of like a filter applied on top of the vertices that are rendered, and scale() and other transformations just affect the vertices. This is partially for more uniform rendering of outlines, and often partially for efficiency. It's also related to a difference in interpretation of what I'll call "strokes" which are like, lines as shapes, and "outlines", which is like, a way of visualizing edges of your meshes. There is no incorrect interpretation of those, they're both valid, and p5's WebGL mode sorta tries to walk the line of having one system work for both. It means you can get relatively high quality caps and joins in WebGL mode for two dimensional content, and have them also work in 3D. It's not super great at performance.

For what we can do about it: I don't think the answer is just to switch to the 2D mode interpretation of lines, but maybe try to figure out a better way of handling these different types of line usage. Here are two ideas:

• We could separate out strokes and outlines. We have the beginnings of this distinction with the simple lines mode that @perminder-17 made, for the times when you do just want to highlight edges and don't care about caps and joins. Possibly we could branch behaviour on that, and have scalable lines when intentionally drawing strokes, and have the outline system be more like how simple lines mode currently works.
• We could try to make a way to make it clearer how to pick between the different line styles. The standard 3D pipeline is you take your vertices, then run them through the model matrix (includes translations, scales, etc), then run them through the view matrix (applies the position/orientation of the camera), then run them through the projection matrix (flattens them onto the screen using perspective or orthographic projection.) You possibly could want lines to live between any of those phases: 2D mode is like having the lines happen before the model matrix, currently lines happen between the view and the projection matrix, and many systems apply it only in screen space after projection.

A thing to consider for 3D stuff specifically: currently stroke thickness (affected by scale) is not a per-vertex property, it is set once for the whole model. This means that if you are using buildGeometry to create a model out of some shapes, as it stands, it would flatten all stroke weight variations into one, including any scale variation we apply. We probably don't want to make this truly per-vertex as that adds a lot of extra data to send to the GPU. There's a GSoC project going on right now making it so that you can effectively work with multiple models with different properties with the ergonomics of one object, so that could be a way forward, although one should also be aware that making a model with many differently scaled shapes is no longer a performance optimization compared to drawing them individually with different scales. Not sure how best to resolve that just yet.

[quinton-ashley]

@davepagurek Ah that makes sense!

Those ideas sound great. Either way having a mode where stroke weight would change based on scale would be nice.

But until then, this would just be good info to have in the strokeWeight documentation:

Note: In P2D mode, stroke weight is affected by transformations, especially calls to scale(). It is not affected by transformations in WebGL and WebGPU modes.

[davepagurek]

Definitely! I'll keep this open for discussion on that larger issue, since figuring out strokes/outlines is something that we keep coming back to, but I'll also mark this as help wanted for updating the docs.