Tag Archives: three.js

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

 

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!