Instanced Line Rendering Using WebGL
wwwtyro.net
wwwtyro.net
One thing you should do is try to limit very short and small segments, as GPUs don’t like rendering 1px triangles.
Still, I’ve been lead to understand that the instanced rendering done in this article is suboptimal on most GPUs. A better way to do it is apparently to put the points into a (non-vertex) buffer and do (batched) drawcalls for large numbers of vertices with a kind of manual instancing. Basically looking up what amounts to instance data using gl_VertexInput/6 and vertex data using gl_VertexIndex%6 (or 4 instead of 6 for indexes rendering).
Unfortunately I haven’t had the time to implement and test this yet.
If like me you’re also rendering lines with perspective, you want to also look at Freya Holmer's work. Particularly line thinness fading is important to reduce shimmer/aliasing. This means basically keep the width at a minimum of 1px and adjusting opacity below that instead.
Edit: For those interested, mine is implemented as a plugin to the Bevy game engine, written in Rust. Bevy can be found here https://github.com/bevyengine/bevy. The plugin is https://github.com/ForesightMiningSoftwareCorporation/bevy_p....
Note that you can't do this in WebGL, at least WebGL 1.0. (Also, be careful about assuming things apply to “most” GPUs!)
Web graphics moves a lot slower than native graphics.
In other words, I suppose that three.js doesn't have nice lines because nobody contributed it, which is usually a sign of low-ish demand. (I know nothing about three.js governance and goals so I might be mistaken)
I do think ThreeJS should include basic thick screen space line support, though, as it covers most use cases and doesn’t add a lot of bloat/complexity to the core framework.
And also if the 10px limit is a hard limit or just of this demo?
When we wrote the instanced WebGL line renderer for https://count.co one of the tricky parts was switching between mitre and bevel joins based on the join angle - for very acute angles the mitre join shoots off to infinity.
Another nice extension (that we are yet to implement) is anti-aliasing, but I think that requires extra geometry to vary the opacity over.
I’m also interested in adding anti-aliasing to my implementation. Maybe widening the line by a bit and fading opacity over that? But yeah, extra geometry, it seems.
There’s a way to do it where you pass one extra vec2 from the vertex shader and use that to determine how much of the pixel is covered by the lines. (This has the effect of thinning the line, so you may want to thicken it to compensate)
Here’s an example of a pair of shaders that do this: https://github.com/paulgb/experiments/tree/master/2021-05-20...
Here’s a demo: https://twitter.com/paulgb/status/1394824275635408907
And:
https://blog.mapbox.com/drawing-antialiased-lines-with-openg...
I am also rendering round caps in the fragment shader. You can then render multiple lines with 1 draw call. The only problem is drawing transparent lines, because of the overlap between segments.
I'll bet chrome://gpu either shows "WebGL: disabled" or "WebGL: enabled; WebGL2: disabled". I think `ignore-gpu-blocklist` in chrome://flags should affect WebGL.
FWIW I'm running Chrome on Linux with hardware rendering force/explicitly enabled for both video and rasterization (`enable-gpu-rasterization` in chrome://flags - don't think this affects WebGL), and it all works great (notwithstanding terrible thermal design) on this fairly old HP laptop w/ i5 + HD Graphics 4000. (The GPU process does admittedly occasionally hang and need killing so it restarts, but that's about it.)
Getting video decode requires --enable-features=VaapiVideoDecoder on the commandline as well, or at least it did in the last version of Chrome, I haven't checked if this is no longer required.
If poking `ignore-gpu-blocklist` doesn't work, what does chrome://gpu show in Chrome, what does about:support (and possibly about:gpu? not sure) show in Firefox, and what GPU and OS are you using?