I was curious how he did those visualizations so I looked at the source code. Turns out he codes everything by hand in WebGL [1]. Absolutely impressive stuff. Source code is non-minified so you can have a look and understand everything as well.
A couple years ago I did some consulting for a company that needed a point cloud rendering engine. Luckily I had one ready to go. I showed them and they liked it and their young devs asked which library I was using. When I told them I used OpenGL they couldn't believe it. To them OpenGL was the "black magic box" and using it akin to having secret conversations with the GPU in some arcane cryptic language.
After finishing that I found out that they were already several major versions ahead and had fancy things like shaders... it really is an amazing tool.
Recently I started messing with some Three.js stuff and it does have some nice abstractions... main benefit of it for me is the ecosystem around it. Being able to just plug in some physics and interactivity and not have to deal with digging up old screen-to-world conversion code is nice.
History tidbit: Jim Clark, the founder of SGI, invented the GPU which was what made SGI machines so fast at 3D.. Later he went on to found Netscape.
Even more trivial: When I moved to Silicon Valley I bought a used Porsche on a whim (my recruiter implied it was a proper consultant accessory in SV) and fixed it up a bit until it became my daily driver. When I researched the title I discovered Jim Clark was the original owner. So I’d like to credit Jim Clark for starting me on the road to speed up my commute.
But if you want to be friendly to the tinkerers, you could always host both the *.js and *.min.js versions, and have the webpage just pull the latter - anyone who wants the unminified source can remove the “min” part from the URI, while the majority of end users will still benefit from pulling the minified js.
In practice this seems to be a lost cause, and links to alternatively hosted source code is more common. Sadly this makes is simple to introduce subtle, harmful differences between the source and what is hosted.
Seems better just to have premassaged source available in a repo somewhere, or called out on the page itself for a downloaded archive.
Minification strips comments too though, which may be undesirable in many cases.
$ ls -la
-rw-r--r-- 1 jack 197609 330905 May 4 22:56 watch.js
-rw-r--r-- 1 jack 197609 152172 May 4 22:55 watch.min.js
$ gzip watch.js
$ gzip watch.min.js
$ ls -la
-rw-r--r-- 1 jack 197609 43690 May 4 22:56 watch.js.gz
-rw-r--r-- 1 jack 197609 32507 May 4 22:55 watch.min.js.gz $ ls -l *.js
-rw-r--r-- 1 mrd staff 330904 5 May 01:04 watch.js
-rw-r--r-- 1 mrd staff 152172 5 May 01:10 watch.min.js
$ brotli watch.js
$ brotli watch.min.js
$ ls -l *.br
-rw-r--r-- 1 mrd staff 34461 5 May 01:04 watch.js.br
-rw-r--r-- 1 mrd staff 27122 5 May 01:10 watch.min.js.br
Whoops, typo: I meant to say that I'd be somewhat more content to ship an un-minified + Brotli-compressed file than a minified + gzip'd one. That is, I'd be more happy to serve the 34.4KB watch.js.br than the 32.5KB watch.min.js.gz.
I don't think the difference is significant enough in this case.
That said, I do think there should be an alternative to minification+gzipping, like e.g. a compiled version of JS that is more optimized than a browser's own JIT compiler can do. Mind you, that might up being a larger package than the JS source code.
* hopefully will be
Yeah minification is only really for obfuscation. The small and unpredictable difference is absolutely not worth the ridiculous complex "solution" of source maps. Just the fact that your debugger really doesn't work right, is a deal breaker in and itself, not to mention all the time spent configuring and fighting with webpack.
I don't think any form of "compilation" i.e. bundling, transpiling, minification etc is needed at all. Javascript can already dynamically load (additional) code files when needed, I don't understand why you need to bundle it in the first place.
I don't buy that the http request overheads are so big that it motivates all this complexity, and in the average case a user don't use every single page of the application anyway, so by bundling everything you are always serving "too much", compared to just dynamically loading additional code.
Hard disagree. "Use What's Right For You™".
Of course there is value in understanding the platform beneath your framework or generic library, but that's just an extension of "understand what you're using and why".
Doing it like this has the potential to be the most performant, but it does so in the same way as writing your programs directly in assembly is potentially performant.
I also don't think that the source code is particularly readable for me, and contains lots of magic numbers and very imperative code. I would personally find it a lot more readable if it was written in some sort of declarative way using a library, even if I have to look at a GitHub repo instead of view source.
Without abstractions you wouldn’t be able to read a text stored on a remote computer with accompanying style information displayed the same on both of our devices and with embedded 3D graphics doing the same thing on vastly differing devices be it a top of the line GPU or a simple low-end phone. Is it not abstraction?
The equivalent would be a mathematical services company, who created "free" abstraction packages that required you to rewrite all your math, away from the scientific community standards, to fit their abstractions, and who also made money on consulting and selling books. And the big benefit of it all, is really that they only abstracted away writing summaries of your papers, which is actually the easiest part that is quite irrelevant to your research.
Who is to tell whether the OSI model is ideal? It is more than likely not it, but we can’t measure these things up front, there is an insane cost associated with changing it, etc. Yet again, what is the alternative? We can’t manage complexity any other way, and essential complexity can’t be reduced.
The current idea of the OSI model was also retrofitted from what it originally was.
> contains lots of magic numbers and very imperative code
Well, we really don't know if the code was written in this form by hand, don't we.
It could have been compiled into this, to use your words, "assembly with magic numbers and imperative" from much more elegant form. We may see this form only because this is what browsers understand.
I am not saying it was compiled, just speculating that seeing pure WebGL does not mean it was pure WebGL to begin with.
Personally I'm not a fan of the magic numbers either but as I study more and more of it, it's everywhere
It also has the potential to evolve in the most efficient way.
Also, nature and graphics works as an imperative parallel machine. So the code mirrors that.
This is not written deliberately this way. Code comes out like that when you strip all the libraries, fluff, and other less-related stuff.
I also write a scientific application, and yes, This is the way.
Yeah in this case it doesn't need to; there's no extraneous or unused code or documentation blocks, and gzip (and comparable) compression is good enough, minification doesn't actually reduce the downloaded code size by that much.
With that said, the raw webGL approach here is arguably more educational, so goal achieved I think!
[1] https://docs.pmnd.rs/react-three-fiber/getting-started/examp...
Edit: there's actually a 50 LOC watch example with r3f: https://codesandbox.io/s/bouncy-watch-qyz5r
The reason you'd use gltfjsx (which that example doesn't) is to have fine grained controls for every node in the scene graph. In the case of the watch, this would map to having a component for each mesh or gear, which can be controlled with mechanics/physics.
I haven't done anything quite this amazing, but I have created other things with minimal upfront knowledge and "the way" is simple: just jump in and give it your best shot with what you already know, identify the most glaring deficiency in what you made, take your best shot at solving that, and repeat that process until you have something cool. You can also use this process to focus what you spend time studying/learning, as you backfill the information you were missing to figure out how to overcome whatever obstacles you encounter.
It does take time, but you know what they say about long journeys and single steps. Sometimes there are no shortcuts and you just have to take a lot of steps.
https://twitter.com/BCiechanowski/status/1522067904522428417
Yes. Almost no one uses it directly.
https://www.tutorialspoint.com/webgl/webgl_drawing_a_triangl...
Comparing this to Canvas is almost like comparing assembly to C. I'm honestly very surprised.
If you put more vertices and indices in Step 2 you can draw an arbitrarily complex 3-D object with this same code.
And there's a lot of stuff in GLSL where you can program directly with high-level concepts like vectors, normals, and partial derivatives, instead of expressing them by hand the way you would in C.
There's at least one (great) game written like that though, Need for Madness with a custom 3D engine and just using java's 2D gfx api for rendering.
Except that WebGL didn't exist so I just had to use the 2-D <canvas>. There's probably some trick for getting antialiased polygon edges in <canvas> to not show cracks...
https://github.com/patriciogonzalezvivo/glslCanvas/blob/mast... has most of that same boilerplate in a less repulsive form. https://github.com/patriciogonzalezvivo/glslCanvas/blob/mast... has other bits.
It’s a very bad, non-object oriented API in an object oriented language. It was designed for and by people who know GL in other C like languages, not for people who know JavaScript. It is unlike any other part of the language.
The fact that I have to write a shader myself, as a fricken string like I’m writing SQL over here, just to draw a triangle is absurd. There should at the very least be some sort of provided builder for simple shaders.
Object-oriented languages are not a good way to do 3-D rendering. If you want to write pixel shaders in JS you can totally do that but you will have to run them on the CPU; as it happens I wrote a program last week that works that way: http://canonical.org/~kragen/sw/dev3/trama. If you want to run them on the GPU you need a language that exposes the GPU's capabilities.
In essence your primary complaint is that the GPU instruction set is not object-oriented (and neither is your database). Well, you can design your own GPU, but I've got some bad news for you about Verilog, Chisel, and BlueSpec! And you may find out that the real problem is that solid-state physics isn't object-oriented, so your OO GPU will end up underperforming, like the Burroughs B5000 and the Symbolics 3600 (hopefully not as badly as the Intel iAPX432). You'll probably have more success writing an object-oriented database.
However, I do agree that WebGL is a bad API, because boilerplate is never acceptable.
I am saving this quote for future use. Thank you :)
Objects are a convenient day-to-day model in real life and software, but there are more "functional" models that comprise the object model.
Once you get through the process of drawing a triangle on the screen then you're learnt 70% of the core of OpenGL. I think you're making the incorrect assumption of "wow if it takes this long to just get a triangle on the screen it must take 1000x as long to get an entire model of a watch" when really you're almost able to draw a model already, you just need to put multiple triangles on the screen now instead of just one.
Adjust the flags as necessary to crawl more of the site if needed (omitting `--include-directories` without an `-l {limit}` flag will eventually crawl the whole site, please be kinder to their bandwidth than that).
Would antifragile be an applicable word to use here?
You really have to admire people who do stuff like that (I can't imagine that I would ever have the patience to do that).
What I'm mildly curious about is why would anyone want to do it? Is there a demand for such stuff? I can understand it if the exercise was for training people but wouldn't most people who were interested in the internal workings of watches already be familiar with them?
I'd reckon most would be like me in that they'd pulled enough watches apart in their younger years to already know their ins and outs (I've long lost track of the number watches and clocks I've either fixed or disassembled by the time I was a teenager).
Most young people don’t even have access to a mechanical watch these days.
First, I should say that I was perhaps a little harsh in my above comment and I didn't convey what I actually wanted to say. Unfortunately, I was distracted by the somewhat irritating fact that I couldn't view any of those drawings on two different smartphones (I could read the article but only saw white spaces where the drawings were supposed to be). It was only later when logged onto my PC that I could view them, and even then the whole page was sluggish and a pain to view. Perhaps those with faster equipment and or faster internet connection had better luck.
Thus, the thinly-veiled message behind my comment was a question about fitness for purpose—both about the subject matter and its method of delivery. My cynical inference was that if people today didn't already understand the basics of gearing, mechanical advantage and escapement mechanisms etc. then something has gone wrong with the education system in that the basics of how clocks worked were well covered in physics (in mechanics) during my first year in high school—and that should not have changed as we still live and move around in a mechanical world—and thousands of industrial mechanical devices use these principles and rely on people having a good working knowledge of them.
By third year physics, everything relevant about the essential workings of a clock would also have been covered at a basic mathematical level: Hooke's Law, gears and gear ratios, friction and simple harmonic motion. Even temperature expansion and contraction and the need to compensate for them was discussed (and in this context the physics teacher even discussed Harrison's famous chronometer and how his design included temperature compensation to ensure that changes in these parameters did not impact heavily on time drift).
In essence, by third year, everything of important in that article had been covered in the school curriculum. If articles such as that under discussion are now being used to compensate for the lack of training in high school science then we have a serious problem with the education system.
Incidentally, even if one's not interested in clock mechanisms, it's worth having a look at this 19th Century publication on mechanical movements that's on the Internet Archive (there are more types around than most people have ever likely considered: https://archive.org/details/Mechanical_Movements_507
First, I learned a concept in school, and probably forgot it. Later, I heard about it again, and hung the concept on the skeleton of what I remembered from school. Only much later, when I'm actually applying the concept (in my career, during home repair, when doing my son's homework), do I connect the dots and really understand the concept front to back.
When talking to people I'll say I learned the concept {of gearing, of escapements, of the behavior of springs} in school. But it's probably just as accurate to say that exposure to experiences like this site were what truly cemented them in my mind.
I don't think so, I'd reckon you'd be pretty typical. It's basically how I learn things and I'd think it's how most others acquire skills.
From my experience, the key issue is having an interest in the subject, subjects that I was interested in I did well in and it was the opposite for those that bored me. I suppose that makes sense but in both cases multiple passes were required before I became proficient - it's just that it took considerably longer when my interest was less.
However, what I've noted on many occasions is that there are students who I'd classify as a class that are just good at learning things even if the subjects have little interest for them per se, they're the ones who would often top the class and later in life you'd find them doing jobs unrelated to the subjects they did well in. I often think I'd like more of that trait.
For reasons I can only speculate about, my interest in certain specific subjects seems to have inate origins, it's as if some a priori interest was there before I knew about them. This doesn't necessarily bode well for other subjects that are deemed essential for one to become skilled in as one's learning can become lopsided.
There's little doubt that hands-on training works for most - and that brings me back to clocks. In physics practical classes on tension, springs, mechanical advantage, etc. we actually had clocks to experiment with. These were usually old bedroom alarm clocks and such that could be pulled apart and reassembled and if damaged it didn't matter much. We all learned from these experiences, even kids with little mechanical aptitude as clocks contains just about every instance of the physics we were learning about and it was obvious how they all came together to make clocks work.
It's the same here. Without people who deeply understand a tool's input and output, we won't ever write a better tool.
[1] don't @ me, cryptographers and kernel programmers.
Agreed, but programming in ASM makes one think differently. In my opinion every programmer should do some elementary Assembler as part of their training, say some basic projects based on 8086 stuff or even the simpler 8085/Z80 etc. It's a long while since I've done any serious ASM work but the techniques one learns and the ideas one develops frame important attitudes that can't be easily gathered from high level stuff (one gains a better understanding of the underlying hardware and such).
You're right, we still need people for this work, it'd be pretty hard to optimize a compiler without them methinks.
FYI, there's stuff I omitted to mention in the above comment, I mentioned it below in my reply to bitcurious. It's interesting 'fitness for purpose' arises given your ASM comment.
Great great great work!!!