Author Archives: Eric

Yup, Zup?

In other words, is Y up, or is Z up? It’s a loaded question. My little lesson (YouTube) from the course is here, in case you don’t know the issue. What’s more entertaining, and the point of this post, are the answers I got back from the people I asked. I’ve asked this question before in this blog.

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).

 

Launched!

As of today, March 11th 2013, the free online interactive 3D graphics course I’ve been working on has begun, at last. I’ve been laboring in earnest and more than full time on this class since October (thank you, Autodesk), and I’m just the most visible person on the project. There’s a raft of others at Udacity making things work and look great: web programmers, video editors, and particularly Gundega Dekena, the assistant instructor on the course. Many other people inside and out of Autodesk have been contributing time for interviews, for video clips, and  for reviewing material (special shout-out to Patrick Cozzi and Mauricio Vives for reading over everything). It’s way more total work creating a video course than writing a book, maybe equivalent to the effort of making a movie vs. writing a novel.

Some of the slick things Udacity has done is integrate video lessons, WebGL/three.js demos, and exercises and questions all in a continuous series. I’d point at an URL, but you do have to sign up for the course to see its structure. Also, wait a day or so: by tomorrow a bunch more links to resources should be in place, at least for Unit 1. Soon the course code will be githubbed, the videos all downloadable, etc. (update: this is now done.)

By the way, this is only the first half of the course. I’m in the throes of writing the second half, which will come out May 1st. I’m learning the video creation process as I go, so I think the quality is increasing as the units progress. Gesturing at the screen and reading what I wrote at the same time gives me a new-found respect for weathermen.

Even if you already know about 3D graphics, you might want to check out the history of the teapot video, which Martin Newell kindly fact-checked. And if you don’t know who Martin Newell is, or only know that he created the teapot model, then you definitely should watch the video. Oh, and then try the WebGL/three.js demo here.

What’s nice is that all the course videos are hosted on YouTube, so it’s easy for anyone to link to any of the lessons (well, except where YouTube is blocked; Udacity has  alternate delivery methods). I hope that these videos and demos will be handy for other people explaining 3D graphics.

Introduction to Parallel Programming course available

I’ve been more than a bit busy working on the (newly renamed) Interactive 3D Graphics course for Udacity, so have been tardy pointing out that this cool course is out now: Introduction to Parallel Programming. Taught by John Owens, David Luebke, and others, it uses CUDA as its basis for teaching. I look forward to taking it myself! It’s a free online course with some serious content, graded exercises, and much else to recommend it – a lot of time & effort (& money) was put into making it, so I expect it will be worth my while.

Oh, and I should also mention another new course, HTML5 Game Development, from experts at Google. It’s more 2D graphics related, but again looks like quite a serious course with a lot of chew.

Wow, that worked?

The demo I made for the Interactive Rendering course actually runs on my phone (Samsung Galaxy S3). My course assistant found it runs on her HTC phone, too. Good luck hitting the up-arrow on my phone, like the documentation on the screen wants me to do… (I should fix that.) It runs only on Firefox, from what I can tell.

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.

Interview with three.js Creator

Three.js is one of a number of free WebGL libraries. First released in April 2010, it has become pretty popular, and includes a huge number of demos. I wanted to know more about its origins, so interviewed its creator, Ricardo Cabello, aka mr.doob, who lives in Spain.

* What is your background: your education, your current job?

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.

Currently I’m a freelancer doing web development, mainly working for Google Data Arts Team.

* Why did you create three.js?

There were many reasons. I was always curious to know what I could do with my own 3d engine. I also thought it was a good challenge for me. I had been tinkering with one since my ActionScript days, learning the basics and slowly figuring out the right architecture.

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.

* How did it get to be so popular?

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.

* Do you have a sense of how many users there are?

Not really…

* How many people contribute code?

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

* Is three.js’s support and extension a part of your job, a hobby, or both?

I guess both 🙂

* Where’s three.js going? Do you have a plan, or does it depend on user contributions?

There is no clear plan. If anything, I just want the web to be more demoscene-ish. More realtime/interactive stuff and less videos.

* One problem with having users is that the API gets locked into place. Do you have any plans to change any APIs and deprecate older classes? For example, “CubeGeometry” is misnamed, since the method actually creates boxes, not just cubes.

That’s probably the biggest problem. The API is still not locked and we break backwards-compatibility from time to time. There is a wiki page that documents all the changes.

However, we try to add deprecated messages here and there for some releases and try to avoid breakage. In the case of CubeGeometry, we would rename it to BoxGeometry while still keeping a CubeGeometry class that would return a BoxGeometry when instantiated plus throwing a warning on the console.

I think the API is getting there, though. It’s starting to feel right. The only parts I’m not done with are loaders and materials.

* What sort of technical challenges have you encountered? Does all three.js code work on pretty much all browsers and platforms (ignoring Internet Explorer)?

There have been many challenges, starting with finding the best coding patterns to use in JavaScript to avoid garbage collection. We still struggle with that. Next is finding the most useful data structures for geometry and materials. Then how to pass all that to WebGL in a performant way. We still have a lot to do there. But luckily this is all under-the-hood stuff that most users won’t even notice.

As for compatibility, yes, we try to support as many platforms as possible.

* In the area of interactive rendering, what’s the biggest surprise to you over the past ten years? Is there any new capability or platform or social phenomenon that has stood out in your mind?

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.

* What do you think is the biggest problem facing the field of interactive rendering at this point?

Lack of WebGL support on Safari for iOS and Chrome for Android. As soon as those browsers add support for it I can see this properly taking off.

* Which way is up, the +Y or +Z axis?

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.

New Year’s Teapot

I’ve been beavering away on my part of the Interactive Rendering course for Udacity and Autodesk. It’s a free MOOC – massive open online course – and I’ll talk more about what I learned from doing it when the course nears completion. For now, the main takeaway I have is “WebGL plus three.js is a pretty good combination for teaching graphics on the web.” The fact that WebGL is built into most browsers (sad slow head-shake to Microsoft Internet Explorer at this point) means you can point a student to an URL and they can immediately see and play with an interactive demo. Three.js is a scene graph library which simplifies for the student the mass of initialization and whatnot that WebGL requires, while also not hiding a lot of functionality from the programmer (like some scene graphs do). Bonus bit is that the Chrome browser has a JavaScript debugger built in (just hit F12 or ctrl-shift-I to toggle it on), so students can always look at the underlying code.

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).
Comments appreciated!

Graphics Codex version 1.7 Released

[This is a guest post from Morgan McGuire. His Graphics Codex is a pretty great thing for anyone who wants just about all graphics formulae and algorithms at their fingertips. It’s not a perfect venue yet, but I think this is an extremely interesting alternative to books, since the app can be constantly updated and improved. With links to working code for many of the algorithms, my first question, “how do I copy and paste?”, is covered. – Eric]

The Graphics Codex 1.7 costs $9.99 on the App Store. You can install it on multiple iOS devices (I use both an iPad and an iPhone). You also receive free (approximately-) monthly updates of new content and features. It supports all iPads, iPhones, and iPod touches with iOS 5 or later [my experience is that you need iOS 6 – there’s a refresh problem with anything older; evidently Apple has changed its scrolling support], although I recommend at least an iPad 2, iPhone 3, or iPod 4.

The Graphics Codex contains about 200 entries on essential computer graphics equations, algorithms, data, and figures. These span quite a range. For example, they include: the formal definition of the BSDF, source code for a shadow map pixel shader, LaTeX commands for image formatting, and figures commonly used in teaching. For me, the historical figures are particularly fun. The staff at the Chapin rare books library helped me to track down first editions of books including Newton’s Opticks, Durer’s perspective manuscripts, and even Lambert’s work. I then scanned these so that you can get Lambert’s law from his original derivation–a kind of vicarious graphics tourism. When lecturing, I connect my iPad to the classroom projector to display these; the students use their iPhones and iPads to pull up equations and details of what I’m writing on the board.

Every month I add new entries based on what I use in my own graphics work and requests that I receive by e-mail. I read all reviews posted on iTunes as well and respond to them with changes. I currently have a queue of 44 new entries to be added. For each one, I cite a primary source and actually implement the algorithm to ensure correctness. The citations include links to canonical (e.g., ACM Digital Library) and free (e.g., author version) PDFs in most cases, so you can quickly jump directly to the source to learn more. Since many functions are also supported under various APIs, I link to DirectX, OpenGL, Mitsuba, etc., documentation as well.

In addition to the reference material, version 1.7 includes “Lecture Notes on Rendering”: twelve long-form chapters suitable for use in an introductory (ray tracing) computer graphics course. This semester I taught graphics at Williams College using this as the primary reading material. I supplemented it with a few chapters from Fundamentals of Computer Graphics 3rd edition, Computer Graphics: Principles & Practice 3rd edition [to be released May 6, 2013 – Morgan is a coauthor], and two research papers: Kajiya’86 and Jensen ’96. The next three chapters I will add in future updates are deep explanations of Photon Mapping, Importance Sampling, and Color Theory. All of these can be used with any API, but are explicitly supported by the open source G3D Innovation Engine graphics library. G3D now includes a complete photon mapping ray tracer that matches the notation and structure of the renderers described in the lecture notes.

On the technical side, I completely rewrote the layout and scrolling engine for this release. The new GPU-accelerated version allows scrolling before layout completes, making even the longest chapters respond nearly instantly. The underlying code uses LaTeX for math typesetting and that runs on a second thread, so if you scroll really fast you’ll see the equations inserted as they are completed. I use dynamic layout instead of static (e.g., PDF) so that content can respond to changing device orientation and re-layout on font change rather than forcing the reader to scroll horizontally. This version also includes support for iPhone 5, iPod 5, and iPad mini resolutions and processors. I recommend using the latest iOS version 6.0.1 because that has the best GPU drivers, but the app supports everything back to iOS 5.1.

I can’t stress enough how liberating and rewarding it has been as an author to release material as an app instead of a book. There are no delays because I release content incrementally instead of in discrete editions, and the quality remains uncompromised by artificial publishing and marketing deadlines–I only release material when it is polished. Direct feedback from readers allows me to support them with appropriate content, and there are zero known errors; as soon as errata is collected, I simply patch the content and push it out to everyone. Selling for 10-20% of the cost of a textbook allows me to reach the hobbyists, indie developers, and students who will be tomorrow’s great developers and researchers. The down side, of course, is that I rely on “word of mouth” (e.g., blogs and Twitter) to promote the app, whereas traditional publications have marketing budgets and campaigns. Now that the app has a critical mass of content, I’m starting to promote it more actively. I look forward to readers letting me know what new features and entries to add in future months.

[p.s. here are links for the Graphics Codex homepage, and Morgan’s twitter feed (actually, he has two) and blog.]

Setting up a Windows Server for WebGL

While it’s fresh in my mind, I’m going to write down the steps for setting up a simple server on your local machine to help run WebGL. 99% of readers won’t care, so begone! Or actually, see the power of WebGL by trying out a zillion demos on the three.js page (you’ll need to use Chrome or Firefox or properly-prepared Safari – try this page if you have problems getting going, it points to the information you’ll need). Whoever’s left might be on Mac or Linux – you could use LAMP on Mac, Apache on Linux, or whatever else you like. Update: I found some further instructions here for other platforms and other server setup methods.

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).

Edit: I’ve been told the wamp server is also nice.

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.)

Seven Things for October 28, 2012