How to draw oscilloscope lines with WebGL
m1el.github.io
m1el.github.io
Note these lines are in actual 3d space: you can rotate the scene using the circle control towards the bottom.
WebGL supports lines natively, but Windows Chrome ignores the thickness (https://bugs.chromium.org/p/chromium/issues/detail?id=60124) so I had to find a different approach on Chrome.
The approach I used is per Matt Deslauriers (https://mattdesl.svbtle.com/drawing-lines-is-hard) . The essential idea is to construct a zero-width line, then use a vertex shader to push each vertex along the line's normal in screen space (not model space). Now represent each vertex twice, and push each one in opposite directions, and you get a nice width.
A fragment shader is used to soften the edges.
Here's my vertex shader, which is the meat of the drawing: https://github.com/ridiculousfish/wavefiz/blob/master/ts/pol...
Couldn't you use a geometry shader to convert points into triangles (or quads)?
[0] https://stackoverflow.com/questions/8641119/webgl-geometry-s...
Webgl and “shadertoy” is why I am in computing, I am not here for Angular but this is how I make money.
My fascination is pointless processing of pixels and without it I feel bored.
I need to learn webgl but there seems no definite guide.
I'm not sure if this a typical case, but the reason I use serious-ish math is my major in physics. When I see a simulation problem calculus comes to mind first.
In my experience there was not a single time calculus was applied in everyday engineering on my projects.
Of course, a lot of people can and do write useful software knowing little to no maths, but then again, I suppose one can build a working bridge based on gut feeling as well.
By "explicit" I mean that e.g. a lot of things I work on for example certainly will use principles that you could write out formally using various mathematical disciplines, but I may or may not have been aware of the underlying maths when writing it, but that does not mean I'm not approaching it in a systematic way.
In a lot of CS papers, even, the use of maths often turns out to be less formal than code, in that I often see maths used to handwave away details you can't get away with not presenting if writing it out as code.
Notice that the default settings in the shader are 300 audio samples (lines) per frame, which is skipping 80% of the audio samples.
You are right that it does depend on the function being evaluated. The function in this article is a set of ~22k arbitrary lines (~44k audio samples) per second, so the fragment shader has to calculate the distance to every line at every pixel.
At 30fps, that's around 750 point-to-line distance calculations per pixel. So turn up the ShaderToy example to 750 iterations, and see how fast it goes. (#define NBITERATIONS 750 in Buf A) I tried that, and my GPU goes down to 10fps in the small window (~600x400) and about 1fps at full screen. And this shader is using a much cheaper intensity function than @m1el used.
So, while it is possible to do this in a fragment shader at interactive speeds (especially if you skip samples), it is more expensive than drawing lines. Keep in mind that a full screen quad also has a greater fill rate than drawing thin lines.
If there were a way to reduce the number of lines you have to check, then you might be right that a fragment shader would be faster. But in this particular case, there's no obvious way to quickly skip checking some of the lines, so drawing lines directly with quads is a lot faster than using a shader, even if vertex shading is CPU bound.