Drawing lines in WebGL is pretty hard. Here's my Schrödinger wavefunction visualizer (http://ridiculousfish.com/wavefiz/) where I learned too much about it.
Note these lines are in actual 3d space: you can rotate the scene using the circle control towards the bottom.
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.
Like in particular real time data. This idea of “uploading data” is classified as slow. I’m not interested in preloading. I want a mouse to churn 1k pixels. This “upload to gpu” seems a major bottleneck. Where’s 1000000 particles cannot be interactively controlled
I find this post intriguing not just for the actual effect, but as yet another little signal of the slow and steady mixing of serious-ish mathematics (though mostly applied maths) into engineering culture; which there was almost no trace of only a few years ago.
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.
I disagree- maths has always been an essential tool of all engineering disciplines. Software engineering is not an exception (algorithms, control systems, graphics, simulations).
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.
The difference is that one can do software engineering without much "explicit" math and without resorting to gut feeling (though admittedly much is written on gut feeling too).
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.
You could build a bridge with gut feeling, but if you wanted a stable bridge with the least possible material then you have to use math. In most software engineering cases, I guess having an abundance of resources lets us get away without math
Works really well even on my old-ish smartphone (2014). WebGL is really interesting, too bad I still have yet to find the time to get a grasp of it. But blog posts like this are very inspiring!
I don't understand why'd you do it this way. I would draw a full screen quad and evaluate if a pixel should be lit or not in screen space in a frag/pixel shader.
The cost of doing this would be enormous - program shader for each pixel would have to calculate this function for every line segment. Instead, only triangles that cover the segment are evaluated.
no... it really depends on the function being evaluated and frag shaders operate in warps. Furthermore, on certain CPUs, vertex shading is emulated on the CPU which is worse than a fragment shader.
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.
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...