Today, three-dimensional computer graphics form an integral part of information technology. Although present in many different applications, only recently they’ve become easily available in web development. But, how?
Prior to 2010, anything related to 3D graphics required specialized hardware and software to run on. Displaying them in a browser was possible, but difficult. Then, WebGL appeared.
WebGL?
In the beginning, there was the Canvas API. And WebGL said, ‘Let there be 3D’.
WebGL is a JavaScript API for rendering points, lines and triangles using your GPU. It’s cross-platform, high-performance and available in all modern browsers. These qualities make it a great option for developing 3D graphics in websites. Unfortunately, as most graphics APIs, it’s also significantly low-level. Any element must be built using exclusively those same points, lines and triangles.
To help with that, multiple frameworks came to life to make it easier to integrate into websites: Babylon.js, PixiJS, Unity 5, PlayCanvas and many others. These frameworks abstract the low-level interface of WebGL and bring their own features. Each one has its pros and cons, but, to us, one stands out from the rest: Three.js.
Three.js?
Similarly, Three.js is a JavaScript library built using WebGL. Even though it was conceived prior to WebGL, Three.js grew rapidly with its advent and now stands as one of the most popular frameworks for general-purpose graphics in web development. It’s open source, robust and continues growing to this day.
The highlight, however, is how much it streamlines development. Implementing most features takes drastically less time and effort thanks to its interface. To showcase its simplicity, let’s compare using the 3D equivalent of a “Hello, World”; that is, rendering a rotating cube.
Hello, Cube!
Without going into detail, here’s a code snippet for our cube using Three.js:
And the same cube using WebGL:
Notice the difference in code length and complexity between both snippets. Three.js achieves the same result without exposing most of the bottom math concepts. Instead of dealing with programs or buffer attributes, the developer has access to simpler concepts such as cameras, meshes and materials. Moreover, the number of lines of code decreases by roughly 80%.
Of course, this is merely the tip of the iceberg. The computer graphics ocean is vast and understanding the underlying concepts is important on the long run. Still, that doesn’t mean the journey shouldn’t be made easier. Graphics libraries are tools, not crutches.
Happy rendering!