That’s the elevator talk, Twitterized (well, maybe 3 tweets worth). I won’t blab on and on about it, just a few things.

First, it’s so cool to be able to show a student a video, then give a quiz, then let them interact with a demo, then have them write some code for an exercise, all in the browser. Udacity rocketh, both the web programmers and video editors.

Second, I’m very happy about how a whole bunch of lessons turned out. The tough part in all this is trying to not lose your audience. I think I push a bit hard at times, but some of my explanations I like a lot. Mipmapping, antialiasing, gamma correction – a number of the later lectures in particular felt quite good to me, and I thought things hung together well. Shhh, don’t tell me otherwise. Really, it’s not pride so much; I’m just happy to have figured out good ways to explain some things simply.

Third, I wrote a book, basically: it’s about 850 full-sized pages and about 145,000 words. It’s free to download, along with the videos and code. I think of this course as the precursor to Real-Time Rendering, sort of like “Star Wars: Episode 1″, except it’s good. I should really say “we wrote a book”: Gundega Dekena, Patrick Cozzi, Mauricio Vives, and near the end Branislav Ulicny (AlteredQualia) offered a huge amount of help in reviewing, catching various mistakes and suggesting numerous improvements. Many others kindly helped with video clips, interviews, permission to show demos, on and on it goes. Thanks all of you!

Fourth, I love that the demos from the course are online for anyone to point at and click on. Some of these demos are not absolutely fascinating, but each (once you know what you’re looking at) is handy in its own way for explaining some graphics phenomenon. The code’s all downloadable, so others can use them as a basis to make better ones. I’ve wanted this sort of thing for 16 years – took awhile to arrive, but now it’s finally here.

Fifth, working with students from around the world is wonderful! I love helping people on the forums with just a bit of effort on my end. Also, I just noticed a study group starting up. I’ve also enjoyed seeing contest entries, e.g.,  here are the drinking bird entries, click a pic to see it in WebGL:

What’s making a MOOC itself like? See John Owens’ excellent article - my experience is pretty much the same.

A close-up in the recording studio, my little world for a few weeks:

Hey, let’s turn this into 7 great links (use Chrome or Firefox to view them, or enable WebGL in Safari):

• Why WebGL? - nice page (with a clever header) pointing out some of the best WebGL work out there. His math visualizations page is also cool.
• Mind-numbingly well-done and instructive terrain rendering demo in WebGL.
• Morph targets rigging for a face looks good in a browser.
• Using particles for model display gives an interesting look, with more data streaming in filling in gaps vs. the usual LOD popping.
• Some great slidesets on animation, collision detection, and other kinds of math from GDC 2012.
• To be honest, WebGL is a bit behind at this point, in DirectX terms being sort of Shader Model 2.0 to 3.0. But boy can that little dog dance: irradiance volumes, for example.
• Useful? Beats me, but it’s fun to watch Gource show the last year of development of three.js in two minutes. I like seeing myself flit in at the end and help shoot lasers at the source tree.

I know there are a bunch more links in the Instructor Notes that are worthwhile (things like the GLSL shader validator plug-in for Sublime Text 2), but these particular ones stuck with me.

I did get to visit the shrine one morning while in Mountain View recording:

Speaking of cameras, is there nothing that three.js cannot do? Check out this incredible piece of wonderfulness and have a webcam ready. Or go right to the demo, and then the other demo. It’s one of those “of course we should be able to do that” kinds of things, but to have it just one mouse click away (assuming you’re set up to run WebGL; if not, go here).

Update: works in Chrome Beta for Android.

Anyway, I’m impressed that my phone can do this at all. It does take a good long while to download and run, but still. 44 frames per second – not bad! Go three.js and WebGL. Oh, and here’s a little video.

click the picture below to go directly to the demo.

My education was a bit of a disaster. I went to primary school, in the later years there I was also going to an academy to learn to draw comics. Then I started studying electronics in secondary school and later moved to arts. It wasn’t really the right time for me to study so I quit before going to University.

During all these years I was fairly active on the Demoscene and that’s where it all comes from. However, back then I was not a programmer, I only created the graphics, and came up with ideas for demos and stuff.

However, the main motivation probably was the fact that, back in the Demoscene days, everyone were doing their own 3d engines that were only used for one or two demos. For the next demo they would create a new engine. I always found that a bit wasteful so I thought of doing one that others could reuse.

So now I’m trying to build the kind of engine and tools I wish I had back then.

I don’t know. Compared to the ones that were popping up at the time, while not the most performant, maybe it was the one with the friendliest API and the easiest to extend. Thanks to that, it now has tons of features and handy code sitting in the examples folder.

There tends to be around 3 active people. There are many others that do small random contributions/fixes: 171 in total so far.

I guess the fact that I’ve been following the demoscene for years has rendered me insensitive about these things… I remember loving Google Body (now Zygote Body) because it showed how 3D could be actually useful as a presentation medium. You couldn’t grasp the data in the same way if the interface was 2D.

Y is up. If you’re consistent with the 2D graphics world (X right, Y up (well… down)) then the missing axis is Z which becomes depth.

So, here’s my New Year’s thingy for you to try out:

The Teapot – nicer controller, not currently working on mobile

The Teapot - semi-mobile friendly, annoying trackball

[Mac/Safari users: follow these simple instructions to enable WebGL on your machine. Other users: if stuck, try this site.]

Nothing deep, as it’s meant for teaching about Gouraud vs. Phong shading: the mouse changes the view (left: trackball, right: pan, middle: zoom), there are a few keyboard controls to switch from vertex to pixel shading and change the tessellation, a GUI for messing with the model and scene, and a little FPS counter in the corner. If the mouse or GUI doesn’t work the first time, hit refresh (and if anyone knows a fix for this glitch, speak!). If you see the FPS counter consistently below 60 FPS for your machine, please let me know your hardware configuration. The heresies I commit in this program:

• You can add a bottom to the teapot (SJ Baker’s excellent page considers this a major sin).
• You can expand the lid 7.7% horizontally to give a solid seal between the teapot and the lid (this gap looks goofy to unbelievers).
• You can scale the model up by 30% so it actually looks more like the real teapot (read the end of this section for one explanation of why the model was changed – short version: Blinn hack to adjust for non-square pixels).

Now, for whoever’s really left…

Why would you want to set up a server for webpages? Well, you need this only if:

• You want to develop WebGL applications.
• You plan on loading textures or model files.
• You don’t want to set up some tricksy settings that open up security holes in your browser.
• You don’t have a server running on your machine and are as clueless as I am about setting such things up.

Background: if you want to load a texture image to use in a WebGL program, then you need the texture to be on the same machine (barring cleverness) and to have both your web page and the texture somewhere in the “documents” area of the same server. This is needed for security reasons.

On Firefox you can get around this security feature by typing “about:config” in the URL. You’ll get a security warning; say “OK”. Now search on “strict_” and you’ll find “security.fileuri.strict_origin_policy”. Double-click to set this to “false”.

On Chrome you can do it two ways: each time on the command line, or once with the program icon itself; I recommend the latter.

First method, command line: start a command window (“Start” button, type “cmd”), go to the directory where chrome.exe is located, (e.g., “cd C:\Users\hainese\AppData\Local\Google\Chrome\Application”) then type:

chrome.exe --allow-file-access-from-files

to start up Chrome. Key tip: make sure to close down all copies of Chrome before restarting it this way, otherwise it doesn’t work (thanks to Patrick Cozzi for this “obvious in retrospect” tip).

Second method: made a shortcut to Chrome, right-click on it and select Properties. Then, add

    --allow-file-access-from-files

to the end of Target, which will be something like “C:\Users\hainese\AppData\Local\Google\Chrome\Application\chrome.exe”.

Server Creation Instructions

These previous methods are nice, in that you can then just double-click on a WebGL html page and it’ll run. Downside is you’re opening up a security hole. If you’d rather just set up a local server and be safer (AFAIK), it’s pretty easy and less scary that I thought. Lighttpd (pronounced “lighty”, go figure) is a lightweight server. There are others, but this one worked for me and was trivial to set up for Windows (vs. Microsoft’s involved “install, open, create” steps for its IIS server for Windows, which I’m told is “easy” but looked more like a treasure hunt). Here’s the whole deal:

1.  Download from WLMP Project - the link to download the .exe is near the bottom (Google’s Developer Network hosts one, so it’s safe), here’s the link.
2.  Run the .exe and install. Use the defaults. You may get a “reinstall with recommended settings” warning at the end; I did.
3.  Edit the text file “C:\Program Files (x86)\LightTPD\conf\lighttpd.conf” (or wherever you put it) and comment out the line (by adding a “#” in front of it):

server.document-root        = server_root + "/htdocs"

and add this line after:

server.document-root        = "C:/Users/<yourname>/Documents/WebGLStuff"

substituting “<yourname>” and “WebGLStuff” with whatever user directory you want. Important: note that the directory path has “/”, not “\”. It might work both ways, but I know “/” works. Everything in this directory and below will be in view of the server. Save the file. Key tip: don’t make this directory in some semi-protected area of your computer like “C:/Program Files (x86)”, make it in your user directory area.

4.  Go to “C:\Program Files (x86)\LightTPD\service” and run Service-Install.exe, then answer “Y”:

You may get a “reinstall with recommended settings” here, too – just agree and do it again.

You have a server running on your machine! You can see it running by ctrl-alt-delete and in the Task Manager you’ll see it under “Services” as “lighttpd”.

Now you can put any and all WebGL code, images, etc. in any location or subdirectory below ”C:/Users/<yourname>/Documents/WebGLStuff” and be able to run it. You’ll run by actually typing “localhost” and then clicking on down into the directory you want. That’s important: you can’t just double-click on an HTML page in a directory but have to use the path “localhost/” as the prefix to the URL.

For example, if you put the code for three.js (which is entirely awesome, in the “awesome” sense of the word, not in the “pancakes? awesome!” sense of the word) in a directory, you’ll see something like this as you find it in your tree:

Click on an HTML file and you run it. For example, if I clicked on the last file shown, it would run and the URL shown would be “http://localhost/three.js/examples/canvas_interactive_voxelpainter.html”.

This all sounds like a PITA, but the cool thing about it all is that WebGL pages you make let you put interactive 3D demos and whatnot on the web without requiring much by the viewer (just any browser other than Internet Explorer, pretty much) – no program download, no plugin, no permissions requirements, nothing. I plan on using this functionality heavily in the web course I’m designing.

There’s lots more you can do with the lighttpd .conf configuration files, but the change detailed above is the minimal thing to do. If you ever later change your .conf configure file options, first run Service-Remove.exe in ”C:\Program Files (x86)\LightTPD\service”, make your changes, then run Service-Install.exe again.

(Thanks to Diego Hernando Cantor Rivera with his help in getting me past some roadblocks. You’d be amazed at how many ways you can mess up steps 3 & 4.)

WebGL: Up and Running, by Tony Parisi, O’Reilly Press, August 2012. More info about the book here, including a sample. I recall Tony from way back in the days of VRML, he had one of the first viewers for that file format, so he’s been working in this area of 3D graphics for the web for a long time. This looks to be a good book if your goal is indeed to get something on the screen fast. It’s readable, and I appreciate his use of URLs to WebGL demos and resources and (properly credited) Wikimedia images. The code samples for the book are here on github.

It uses the popular three.js library to insulate you from the OpenGL ES roots of WebGL and hide its raw API nature. The author of three.js, Mr.doob (I don’t make these names up), notes that his work is “a lightweight 3D library with a very low level of complexity — in other words, for dummies”. Which is a fine thing, and I think I’ll be using it myself to teach introductory computer graphics. However, if you want to gaze at the occult pulsing mutation spawned of JavaScript + OpenGL ES + DOM + JSON + HTML 5, I mean, unleash the full power of WebGL itself, you’ll want to read the next book instead.

WebGL Beginner’s Guide, by Diego Cantor and Brandon Jones, Packt Publishing, June 2012 (code here). This is a pretty impressive book overall. The authors deal with WebGL directly, adding only the glMatrix library on github to make matrix manipulation easier (this is about as minimal as you can get). This book walks through much of what WebGL does (essentially, the same as OpenGL, of course), giving lots of code examples and worthwhile illustrations. Some example programs are quite nice, with useful user interfaces allowing you to twiddle values and see the effect. The book deals with more advanced topics towards the end, such as how to render offscreen and sample the results (their example is for performing picking). There are a few minor problems with layout on my iPad (a few illustrations don’t fit and there’s an awkward scrolling interface that doesn’t quite work), and some occasional lapses in grammar, but overall the book is fine. Occasionally the authors will get distracted by side topics, like a full derivation of why you use the inverse transpose of the matrix for transforming normals, or explaining a shader that does simple ray tracing. In general, however, the book works through the key areas of the WebGL API and warns you of potential problems along the way. WebGL itself exposes you directly to vertex and fragment shaders, so if you are planning to do some serious work in this area, this book is perhaps a better choice that Parisi’s (that said, three.js itself gives you easy access to shaders).

Personally, these two WebGL books were cheap enough on Kindle that I bought them both. The Beginner’s Guide in particular is a much better deal on Kindle – a third the physical book’s price. They’re actually better on Kindle, in that they’re in color; the physical books are printed with grayscale images. There are other books on WebGL, but these were the two recommended to me and they are both reasonable choices, depending on your goals. I would not recommend either if your primary goal is learning the fundamentals of computer graphics (though there’s a bit of that type of material in each). For learning WebGL itself and the basics of what it offers, both books are fine, with the “WebGL Beginner’s Guide” being aimed at the more “to the metal” programmer.

JavaScript: The Good Parts, by Douglas Crockford, O’Reilly Press, May 2008. If you use WebGL, you’ll have to know at least a bit about JavaScript. Patrick Cozzi mentioned this as a reasonable guide, along with other writings by the author. I’ve only started it, but it’s pretty amusing. The book’s approach is to indeed teach only the good parts about the language and not let you know how to use the bad parts. The author recommends only one of the dozens of books on JavaScript, JavaScript: The Definitive Guide. He feels the rest are, to quote, “quite awful.”

Update: I finished this book and thought it got better as it went along. It starts out a bit language-wonkish, too much about grammar. Skip that chapter. The most useful parts were the appendices, where he explains the various parts of JavaScript clearly and succinctly, calls out the dangerous and evil parts of the language, and explains how to steer clear of them. The author came up with JSLint, which checks your code for badness, but to be honest it’s way too a strict schoolmarm for me, hitting me on the knuckles whenever I put a left brace “{” on the wrong line. I recommend JSHint instead.

Enough on WebGL and JavaScript, my current interests. I’ll mention just two more books that I’ve only just glanced at and so can jump to conclusions.

Real-Time Graphics Rendering Engine (Advanced Topics in Science and Technology in China), by Hujun Bao and Wei Hua, Springer Publishing. Shame on you, Springer, for shame. A 300 page book for $169 is bad enough, but this one has a slap-dash translation that could probably have been done better by Google Translate. I’m judging only from the “Look Inside” text I can access on the Amazon listing, but I see things like a section labelled “Rending Modle” on page 5. This might be a fine book in its native Chinese, the bits of material I tried to read seemed sound enough, but the translation is, well, judge for yourself. Here’s the end of chapter summary, a section I picked at random:

“Real-time rendering is always formed as a pipeline composed of consequential data processing and graphics calculations to generate final rasterized images. In order to achieve amazing rendering effects as well as real-time performance, GPU techniques, especially shader techniques, are introduced to utilize programmable pipelines and the parallel computing structure. Virtual geometric 3D models are transformed to be located in a virtual scene by geometrical transformation matrices. Material and/or other visual properties are then attached to those geometrical models to compute visually pleasant rendering results. As the performance of real-time rendering applications is highly emphasized, tailored shading techniques and BRDF models are employed to achieve real-time rendering results with balanced visual effects.”

I feel terrible for these authors whose work has been so shabbily thrown between two covers.

However, there is certainly a worse book out there, and I have to give the full-sized cover from its Amazon listing, since I expect it to disappear any day now and I want to keep it as a memento.

Suck it, bizzatches, I got me my own book on Amazon. Yes, the title is my name, it’s ostensibly a biography; I’m not the author. I ran across it yesterday morning, and it almost made me laugh. Almost, because I hate these “books”. It’s clearly by the same people who came up with all those other automated offerings, VDM Publishing.

I’ve posted about this so-called publisher before, here and here. VDM now has a new imprint, “Cel Publishing” (one of seventy-nine!), I expect because the Alphascript and Betascript Publisher books are fast disappearing from Amazon’s catalog as the complaints and returns roll in. The short version is that this firm has a program that grabs a random Wikipedia page and follow links from it. Once there’s enough material for a book-sized book, it spits out the contents. Some human – in this case allegedly one “Iustinus Tim Avery” (anagram server’s first hit is “Autism University”) – slaps a cover on it and it’s put in the catalog, to be published on demand.

The most creative part of the process used to be the cover choice. In the past they were sometimes pretty amusing, but it looks like Cel Publishing has removed that fun part of the job for the “editor” and instead just uses random abstract patterns. I personally think of myself as more of a splash of chartreuse paint, but so be it. Also, the book is clearly underpriced at $38 for 60 pages. What did make me laugh is that there’s now a review of the book (thanks, Matt!).

• http://webglplayground.net/ – on the left is the code, on the right is the result. See the gallery for more examples, which tend towards 2D and artistic examples.
• http://glsl.heroku.com/ – code actually overlays the display itself. Here is a more 3D example.
• http://spidergl.org/meshade/index.html – more elaborate, shows separate shaders, model loading, and JSON and HTML generated. To run, click “Load” to load the given model, which you can interact with.
• http://www.iquilezles.org/apps/shadertoy/ – allows playing with the pixel shader, essentially. Mostly about image deformations, often encountered in old Demo Scene programs.
• http://www.kickjs.org/example/shader_editor/shader_editor.html – for playing with a 3D object and trying out experiments with the vertex and pixel shaders in the GPU.
• http://cesium.agi.com/Cesium/Apps/Sandcastle/index.html – give it time to load (hey, it’s loading the whole world). It shows a quite elaborate development environment. They are using CodeMirror to do the in-browser editor. See their other demos here.
• http://jsfiddle.net/ – a more general tool for trying out JavaScript programs, not WebGL per se.

Enjoy! And let us know of any others you find.