Thursday, December 27, 2012

GitHub and Open Source in the Classroom

I started using source control in high school, and I believe every computer science student should be comfortable with at least one source control package. Last semester in my GPU Programming and Architecture course at the University of Pennsylvania, we had students use GitHub for their code. This semester, we took it a step further.

Last semester, we used a GitHub educational account so each student could access a free private repo. To release a project, we added a new directory to each student's repo (which was slighly less work than creating a new repo; forking was not an option since each student wasn't required to create an educational account). Students submitted their work by creating a tag. This all worked OK. Students learned basic git features. Rolling out fixes to our starter code was reasonable enough.

But we could do much better.

This semester we said goodbye to private repos, and went completely open source (well, students still had the option to use private repos, but no one did). To release a project, we simply added the new repo to our GitHub organization, and students forked it. Students submitted their work with pull requests. Besides better exposing students to git, this had some major benefits.

Code portfolios

Each student built a code portfolio, which will help them start their careers. This is inspired by an internship posting by Christophe Riccio:

"The profile for the candidates: C++, OpenGL, OpenCL. Applications with a source code and for the principle of it, a resume."

I whole-heartily agree with the spirit of this. Students with public code portfolios are more marketable than students without. Public code portfolios give students more exposure and give employers a lower barrier-to-entry. By diffing repos, employers can also see what exactly the student did vs. what was provided.

Combine a public code portfolio with cool projects (our students implement GPU ray tracers, path tracers, and rasterizers to name a few), and quite frankly, I don't know how students without a code portfolio will compete.

In addition to helping our students, keeping everything public has the potential to help anyone.

Help the larger community

Interested in writing a GPU path tracer? Fork ours. Don't stop there, read our slides and listen to the audio. They're public for everyone's benefit. Ultimately if the course gets attention, it also benefits those who took the course.

Academic integrity

The most common question I get is if everyone's work is public, can't students cheat?

Yes, but students don't need public repos to cheat. They can talk among themselves and there's already lots of code online.

There's also lots of things that discourage cheating:
  • No two projects are alike - we never provide rigid requirements. For example, the image processing project gives a selection of filters to implement, and requires students to come up with new ones. The rasterizer gives a set of required stages, and a selection of extra ones. In practice, projects turned out to be remarkably different.
  • Random presentations follow projects - three or four students present their projects in class without any notice. The main motivation is for students to get use to talking on their feet giving an elevator pitch. Discouraging cheating for fear of not presenting well is perhaps a side-effect.
  • Social pressure - the code trail is public and commits have time stamps.

Cheating is, of course, still possible, especially copying one-liners. However, the benefits of public code repos outweigh the risk. We strive for a course culture where students don't care to cheat. They want to implement the projects - actually, even students outside of our course want to implement them. If a student wants to chase after grades, they need to take another course. In our course, we stay up to 2am coding for fun, not grades.

Saturday, December 1, 2012

Hackathons in the Classroom

I teach a graduate-level GPU Programming and Architecture course at the University of Pennsylvania. I do lots of atypical things like open source projects using github (there is no "homework" - who wants to do homework?) and I've even let the students make their own final - of course, they didn't know they were doing it at the time. This year I got rid of the final altogether to allow us to focus more on building portfilios of projects like, for example, the work of Zakiuddin Shehzan Mohammed.

Inspired by Facebook and PennApps, and based on feedback from last semester, I decided to bring a hackathon into the classroom. The goal being to build a culture of excitement and intensity, and to code for the fun of it. No grades, just bragging rights and prizes: a copy of OpenGL Insights and a few Cesium t-shirts.

Tiju Thomas presents his hack

I canceled class and replaced it with a six-hour hackathon, 6pm-12am, in the graphics lab using the GLSL Sandbox, an online editor for writing GLSL fragment shaders. The theme was two triangles (or even one) ought to be enough for anybody. The GLSL Sandbox renders a full-screen quad providing one fragment per pixel for students to ray trace, ray march, or do anything else they liked. They were allowed to fork any existing example in the gallery as long as they demoed the original along with their work.

I even encouraged students to fork each other's work as a fun way to compete, e.g., a student might focus on soft shadows, procedural textures, and other shading techniques, and then fork another student's work doing CSG to create something really awesome. This arms race didn't pan out in practice, but with more preparation - perhaps a project on ray marching leading up to the hacakthon - it could be really interesting.

Ashima Gupta and Yue Hue present their hack

Once the hackathon got rolling, there was a sense of focus and intensity. By the end, all students got something working, and many surprised themselves. People outside of my course even joined in, like Nop Jiarathanakul's procedural smoke and Gabriel Leung's Conway's Game of Life

We stayed until about 2am doing demos and reflecting on the experience. It was very cool to see students motivated and working hard for the sake of the project; there were no grades involved. A student could have walked out or not even showed up with nothing to lose, but no one did.

Yuanhui Chen presents her hack

Moving forward, we may compete with a class at another university and do a longer event open to all our graphics students. I want to thank our TA, Karl Li, for helping with the event, Nop Jiarathanakul for demoing his work at the kick-off, and Aline Normoyle for letting us use the lab.

Check out the results:

WebGL, Virtual Globes, and Santa

I've been quiet on this blog recently; in addition to teaching GPU Programming and Architecture again, I have been working on a fun project using WebGL and Cesium, our virtual globe, to help NORAD track Santa this Christmas Eve.

NORAD has a long history of tracking Santa. The NORAD Tracks Santa site is very popular, last year it received 19 million unique visitors over the holiday season. NORAD has provided a 3D globe with Santa's real-time location on Christmas Eve before. However, thanks to WebGL, this is the first time the globe does not require a plugin, so I expect 3D will reach even more people.

I wrote a blog post on the Cesium website with many of the tech details: rendering global terrain, imagery, stars, etc. However, some of the biggest challenges weren't strictly technical, for example, how do you design a UI for 5-10 year-olds and their parents?

Of course I am excited about this opportunity for Cesium, but I also see this as a huge opportunity for WebGL. APIs need killer apps to drive adoption. Although there are lots of amazing WebGL demos, there are few WebGL apps that have reached the masses with a compelling better experience. This needs to change, and I hope NORAD Tracks Santa is one step in that direction.

Our globe will be live Christmas Eve at In the meantime, there is the tech preview I wrote and instructions for getting WebGL, but if you're reading this blog, I'm pretty sure you already know how to do that.

Tuesday, July 24, 2012

OpenGL Insights

Our new book, OpenGL Insights, will be available at SIGGRAPH, and shipping from Amazon and elsewhere early August.

Christophe Riccio and I served as editors, and worked with 52 authors and 17 technical reviewers from the OpenGL, OpenGL ES, and WebGL communities to create 44 chapters and 712 pages on rendering techniques, performance, debugging, profiling, software design, teaching, and other topics.

The OpenGL Insights website is now up.  It contains:
  • Five sample chapters
    • Octree-Based Sparse Voxelization Using the GPU Hardware Rasterizer by Cyril Crassin and Simon Green
    • Performance Tuning for Tile-Based Architectures by Bruce Merry
    • Asynchronous Buffer Transfers by Ladislav Hrabcak and Arnaud Masserann
    • ARB_debug_output: A Helping Hand for Desperate Developers by António Ramires Fernandes and Bruno Oliveira
    • The ANGLE Project: Implementing OpenGL ES 2.0 on Direct3D by Daniel Koch and Nicolas Capens
  • OpenGL 4.2 and OpenGL ES 2.0 Pipeline Map
    • This was Christophe's idea, and his amazing work created the most detailed pipeline diagram that I've ever seen.  I love it.  I have a copy on my cube wall and plan to hand it out the first day of class in my GPU course.  A two-sided 14x18 inch detachable color version is also included with the book.
  • Tips
    • The book includes short OpenGL tips, for example, Depth writes only occur if GL_DEPTH_TEST is enabled.  The website includes all the tips in the book, and we plan to continuously update it, so please send your tips to

Big thanks to Omar Rodriguez, coauthor of the Browser Graphics Analysis and Optimizations chapter, for his help with the website.

When I look back at the original call for authors, I am delighted that the final book lives up to the high expectations and broad scope that we initially set.  We received an overwhelming number of chapter proposals, especially considering OpenGL Insights was an unestablished, new series.  Authors put in significant effort, sometimes reworking parts several times in feedback loops with reviewers.  All chapters received feedback from multiple reviewers; some chapters had as many as six.  The reviewer's technical knowledge was humbling.

A huge part of this project's success is due to Christophe.  When I initially emailed Christophe in March, 2011 to ask him to join me in this effort, I said: this project needs your enthusiasm; it will not be the same quality without you.  Quite frankly, that was an understatement.  Christophe's passion, drive, vision, belief in community, and OpenGL knowledge are amazing.  Working so closely with him was a rewarding experience.

Monday, July 2, 2012

Reflections on Teaching GPU Programming and Architecture: Take II

I recently wrapped up teaching CIS 565: GPU Programming and Architecture at the University of Pennsylvania. The first time I taught it, I wrote a reflections post on my lessons learned. Here are my reflections on my second time through.

But first a brief course history... This course was first offered in 2005 by Suresh Venkatasubramanian, and focused on Cg for GPGPU. In 2007, Gary Katz and Joe Kider immediately migrated to CUDA when it became available in the middle of the semester. I was a student at the time, and remember our bitonic sort homework getting canceled because the solution just came out in the CUDA SDK. Joe taught the course several times, and suggested I teach it starting last spring, 2011. Over the years, we added quite a bit of rendering, making the course a combination of GPU computing and real-time rendering.

This past semester some things went well, and others did not.

1. Exploit parallelism in the final.

GPU Accelerated Path Tracing - Xing Du
My first semester, I had each student create a practice final that I crowdsourced to create a 100% student-made final. It was great fun and had great results.

To mix it up this semester, I crowdsourced questions on each homework to create a 100% student-made take-home final. I took it a step further by also having an in-class final that I made. I brought it into class and said "you probably realized that you made the take-home final, but I made the in-class final myself. However, there is only one copy. Design a parallel algorithm to take it."

Given that much of the course is on exploiting parallelism and parallel algorithms, i.e., reductions, scan, stream compaction, sorting, searching, etc., I thought the parallelism theme for the final was appropriate and fun.

Instead of using the student's parallel algorithm of ripping the final into pieces (I'm surprised they didn't want to photocopy it), I gave the exam verbally, and had each student work on the same question in parallel. Then, acting as the scheduling hardware, I picked a student to answer. If they got it wrong, the value of the question dropped to emulate a synchronization penalty, and the rest of the class was allowed to synchronize and come up with an answer. Although the class as a whole was a parallel system, they weren't quite a GPU. That's OK - the difference between the two was actually a question.

The in-class final was a ton of fun, created a lot of energy, and hopefully left a lasting impression with the students, which was my real goal. I also received positive feedback on the take-home final; students liked going back through the material - which is the exact point of a final!

2. Everyone should use GitHub in their courses.

Ray Marching Distance Fields in Real-Time in WebGL
Nop Jiarathanakul
I believe students should learn source control as early as possible. Given how much momentum git and github have (github hosts 2.6 million projects last time I checked), my students were required to use github for their homework and projects. Github kindly provides free educational accounts with private repos.

Although it required some initial ramp up, by the end of the semester the students really liked using github, and it became a habit for many even after the course. Besides exposing students to source control, github also made it easy to deploy fixes to our starter code, and host the course website backed by a git repo, which is much better than manual FTP.

In addition to the private repos used for homeworks, every student made their final project open source, and some continue to develop their projects. Given that github is becoming the new resume, i.e., show me code not paper, next semester all coding will be done in public repos so students can start building a code portfolio. Of course, this creates potential academic integrity issues, but we can combat them with follow-up presentations and structuring projects as implement x of n features.

3. The second-lecture effect.

Real-Time Reflections and Refractions - Ian Lilley
Software developers are familiar with the second-system effect that states developers tend to over-engineer their second system. This semester, I experienced something I call the second-lecture effect, which is the opposite of the second system - one's second lecture on the same topic is under-delivered.

For me, creating a new lecture took 12-15 hours; however, updating and prepping the same lecture a year later took 0-6 hours (0 for something I do everyday, and 6 for something I didn't touch all year). I, of course, expected the prep time to go down, but I didn't expect the quality of the lecture to go down too. Well, it did.

When I first create a lecture, the research is fresh in my mind, the topic is sometimes new to me, and the series of motivating questions to ask come naturally. My interest and excitement comes through in the lecture. However, the second time through is old news, and it is evident because the lecture is shorter, not at the same depth, and lacks the energy level.

We need to fight the second-lecture effect.

(OK, my lectures weren't that bad this semester, but they were not as good as the first time I taught the course).

4. Publicly available lectures have more benefits than drawbacks.

GPU-Accelerated Logo Detection - Yu Luo
When I first taught the course, I recorded every lecture, and made the wma files available upon request. Since it was my first time teaching, I wasn't sure if I was polished enough to post them publicly.

This semester, I made them available for the whole world. The benefits were:
  • More students used them!
  • I can point anyone interested in GPUs or rendering to them.
  • Giving back to the larger community makes me feel good.
However, there were some drawbacks:
  • Knowing that the audio will be posted tones me down: I am less likely to complain about the latest driver bug, tell some stories, or name names.
  • I'm not always right. For example, at one point, I said shared memory access takes the same number of cycles as registers on the G80, which is wrong. Shared memory takes two cycles (assuming no bank conflicts); and register access takes one. Although I correct these mistakes later, they are still embarrassing.

5. I don't scale well.

Procedurally Generating an Infinite City - Alice Yang
This semester I went from 12 to 20 students. It was still a small class, but it was also a 67% size increase for the one instructor and TA. This didn't increase lecture prep time, but it increased everything else. For example, I went from 550 to 740 gmail conversations over the semester, and had more student presentations and projects to mentor.

Given that I also started the semester beyond burnt out from OpenGL Insights (should be well worth it though), I was spread too thin.

Having more group, instead of individual, projects would allow me to spend more time on each project. We actually experimented with pair programming for an image processing assignment, followed by an in-class quiz with pretty positive results. The idea was to foster collaboration, but still ensure the knowledge of individuals; having less assignments to grade was a side-effect.

6. Student projects blew me away.

GPU-Accelerated Simplified General Perturbation No. 4 (SGP4) Model
Matthew Ahn
The final projects were outstanding. Screen shots of many are shown throughout this post. Many received external attention on twitter and blogs.

It helped remind me that this course is about projects, and to inspire me to really focus on them next semester. In fact, I am dropping written homework - with the exception of performance analysis - to focus on more projects. I am also re-branding homeworks as projects, and the project as the final project. No one wants to do homework, but everyone wants to do projects.

7. Grades measure rigor; rigor isn't everything.

GPU-Based Physically-Based Photorealistic Unbiased Pathtracer
Peter Kutz and Karl Li
I wrote before that organized and conscientious students get high GPAs, but that doesn't mean that they mastered the material or demonstrated the most passion; it means they carefully dotted their i's and crossed their t's in the quest for grades.

After this semester, I now take an even firmer stance on this position. Grades are all about not making mistakes: avoiding compiler warnings and errors; submitting all files on time; and answering questions carefully and fully. These are good rigorous traits, but not enough.

I want to create a culture of passion for graphics, and to facilitate the quest for knowledge, not the quest for grades. Next semester I'm doing away with grades for the most part. We'll give the students feedback on their projects, and they will grade themselves. My role will be to make sure the students fall into place relative to each other.

8. Apparently 9am is early.

I moved the class from 6pm to 9am thinking it would fit better into student's schedule; however, the most overwhelming course feedback I received was the course was too early. We're back to 6pm next semester.

9. Compute and graphics.

GPU-Accelerated RGB-D SLAM with Microsoft Kinect - Yedong Niu
Over the years, this course evolved along with the evolution of the GPU. Prior to this semester, we taught OpenGL for rendering and GPGPU before teaching compute with CUDA. This semester, I taught CUDA first, which made teaching the GLSL programming model trivial; however, its restrictiveness was even more evident.

Given the diverse backgrounds of the students taking the course - some are interested in rendering; others are interested in compute only; some are interested in both - we are going to split the course. This fall, it will focus on rendering, and we hope to offer something later that covers general compute with many-core GPUs and multi-core CPUs.

10. My success is student success.

Single Pass Order Independent Transparency - Sean Lilley
As I said before, I measure my success by my student's success. I even started a hall of fame for the course. Induction into the hall of fame isn't based on grades; it is based on how taking the course shaped a student's future, most often in the form of obtaining a related job or internship. This semester, Sean Lilley, who is spending the summer at AMD, and Ian Lilley, who is spending the summer with me at AGI working on Cesium, were inducted.

Varun Sampath, now at NVIDIA, was an awesome TA this semester, and was inducted into the hall of fame last spring.

Sunday, June 24, 2012

Picks for SIGGRAPH 2012

SIGGRAPH 2012 will be my fifth consecutive SIGGRAPH, and it is shaping up to be the best one yet. Here's what I'm looking forward to.


There is more OpenGL content this year than ever before

I highly recommend the Introduction to Modern OpenGL course taught by Ed Angel and Dave Shreiner for beginner and intermediate OpenGL developers. I attended the course twice in the past. See the slides and code from 2011 and 2008.

The new GPU Shaders for OpenGL 4.x course by Mike Bailey is a timely course covering the OpenGL 4.x pipeline, including tessellation shaders. Although I will miss it due to a scheduling conflict, I will be sure to catch the video since I plan to have a new lecture on this in my GPU Programming and Architecture course this fall.

For those of us teaching OpenGL, I'm glad to see quite a bit of SIGGRAPH content. Mike Bailey is organizing the Teaching OpenGL in a Post-Deprecation World and Khronos Institute for Training and Education (KITE) for Educators BOFs back-to-back (more on KITE here).

The OpenGL BOF organized by Khronos Group is usually the OpenGL developer event of the year. However, it has competition this year. I believe the OpenGL 20th Anniversary Party, following the BOF, will be the biggest OpenGL event ever and the highlight of SIGGRAPH for me. From what I can gather, there will be beer, food, tee-shirts, Kurt Akeley, and a ton of other people passionate about OpenGL. Want to help spread the word? Here are the creative banners with well-known 3D models used in graphics research.

Our new book, OpenGL Insights, will be released. Christophe Riccio and I served as editors, and worked with a large and amazing group of authors and reviewers to bring the book together in the true community spirit of OpenGL, OpenGL ES, and WebGL. Topics include performance, debugging, framework design, teaching, and more. The website with sample chapters will be up soon (totally my fault that it isn't up yet), in the meantime there are some older blog posts is up now with five sample chapters, an OpenGL pipeline map, and other goodies. There will be a book signing at the CRC Press booth at the expo on Tuesday afternoon (details TBA), 2-3pm, and, of course, we'll sign books at the Anniversary Party if you track us down. Given the number of contributions that will be there, it is a unique opportunity to get the book signed by several folks. Books will also be given away at the OpenGL, OpenGL ES, and WebGL BOFs. Better study the specs!

Those using OpenGL and OpenCL in Java may be interested in the JogAmp: 2D/3D & Multimedia Across Devices BOF. I attended the JOGL BOF several years ago, and recall it being worthwhile.

Real-Time Rendering

Given my interest in rendering massive ammounts of imagery for virtual globes, I'll be at the new Virtual Texturing in Software and Hardware course, by Juraj Obert, J.M.P. van Waveren, and Graham Sellers. JP presented virtual textures in id Tech 5 at SIGGRAPH 2009. I'm interested to see how traditional techniques compare to the new partially resident textures (PRT) GPU feature.

The Beyond Programmable Shading course organized by Mike Houston, Aaron Lefohn, and Johan Andersson is always awesome. In fact, it inspires much of the content in my GPU Programming and Architecture course. The course contents are not out yet, but if I had to take a guess based on current trends, they will include alternative rendering pipelines written in CUDA or OpenCL, systems-on-a-chip, and the future of rendering APIs. Check out the course slides from previous years (2011, 2010, 2009, and
2008), and the related courses at Stanford and University of Washington. This course is usually a full day, but it looks like it's only half a day this year.

The full-day Advances in Real-Time Rendering in Games course organized by Natalya Tatarchuk presents rendering techniques in the latest games. I somehow miss most of it every year, but hope to attend a good bit this year. Check out the slides from 2011 and 2010.

Given how awesome the course notes from their SIGGRAPH Asia 2009 course are, I am excited for the Efficient Real-Time Shadows course by Elmar Eisemann, Ulf Assarsson, Michael Schwarz, Michal Valient, Michael Wimmer.

The Game Worlds talks organized by a Corrinne Yu should be good. In particular, the Creating Vast Game Worlds - Experiences From Avalanche Studios talk by Emil Persson will cover a number of topics I am interested in for virtual globes. His related chapter in GPU Pro was also quite good.

Surf & Turf talks organized by Kenny Mitchell also look not to be missed.


I expect the WebGL BOF organized by Khronos Group (Ken Russell) to be awesome this year. Last year the room was packed - people standing, sitting on the floor, and crowding around the door. Let's hope the room is a lot bigger this year. I believe (I am!) I'm demoing Cesium, our WebGL virtual globe and map.

Graphics Programming for the Web is a timely new course by Pushkar Joshi, Mikaël Bourges-Sévenier, Ken Russell, and Zhenyao Mo covering WebGL and other relavant HTML5 techniques. It sounds like it will be pretty broad, which is great for C++ developers like me that recently started to pretend to be web developers.

Although not WebGL-specific, I'll be at the Rest 3D BOF organized by Rémi Arnaud. I'll even miss part of Beyond Programmable Shading for it! Rest 3D is defining a REST API for accessing 3D content over HTTP. If it gets widespread adoption from content providers, WebGL apps using the API will have access to a ton of content, which is a big win for everyone.


SIGGRAPH Mobile is new this year. I expect it will grow significantly in the coming years.

This year, the Understanding Mobile Graphics - GPUs and Platforms talks organized by Lars Erik Holmquist look like they will help me develop content for my GPU Programming and Architecture course. I suspect Saving the Planet, One Handset at a Time: Designing Low-Power, Low-Bandwidth GPUs by Tom Olson, Edvard Sorgard, and Dave Shreiner will cover tile-based rendering and other techniques. If Unity: iOS and Android - Cross-Platform Challenges and Solutions by Renaldas Zioma is anything like the How to Write Fast iPhone and Android Shaders in Unity Studio Workshop he presented last year with Aras Pranckevičius, it is going to be fantastic.


It's been a few years since SIGGRAPH offered the Fundamentals Seminar course by Mike Bailey, so I am happy it is back this year since I've never been to it. It's always worth going over fundamentals, especially with my educator's hat on.

I'll catch a few other BOFs, including OpenGL ES, COLLADA (WebGL best practices?), and OpenCL.

Although I rarely attend a lot of paper sessions, I always attend the Technical Papers Fast Forward to see new research, and perhaps more so, to be entertained by the short and creative paper pitches.

If anyone wants to meet at SIGGRAPH, send me a note,

Friday, May 11, 2012

Cesium on GitHub

Source code for our WebGL globe, Cesium (formerly Geoscope), is now on GitHub. To say the least, we are pretty pumped. This is a real open source project; we are not throwing the code out there and abandoning it, nor are we retaining complete control and just releasing source code. We're doing all development and planning out in the open with the community. There's a public roadmap, architecture overview, contributor's guide, and development mailing list.

Most of us are relativity new to github, and so far it is awesome. In particular, the code review tools are the best I've ever used. The ability to comment on commits and on individual lines of code as if we were commenting on a facebook post is useful. Combined with git's ability to quickly create and merge branches, we are really able to embrace peer review. In fact, our code quality has improved just because we know it will be publicly reviewed when merged into master.

As far as the project itself, we already implemented a lot of features, including streaming imagery from Bing, Esri, OpenStreetMap, and WMS; vector data rendering for polygons, polylines, billboards, and labels; various camera modes; a WebGL abstraction layer; etc. Check out the demos on One particularly exciting feature is that Cesium supports 3D, 2D, and columbus view (think 2.5D, see below), and morphing between them with one line of code.

We have a good start, but there is still a lot of core features left. We're starting to look at streaming terrain, COLLADA models, and precision improvements. If you're interested in using or contributing to Cesium, please jump in.

Tuesday, March 20, 2012

Student Projects

I am teaching GPU Programming and Architecture at Penn again this semester. My students are starting on their final projects, and have some outstanding ideas. Three students are using WebGL, up from one when I taught the course last spring. Check out their project blogs and feel free to comment:

Saturday, March 17, 2012

Cesium - Our New Virtual Globe

Over the past year, Kevin and I - and several other AGIers - have been working on Cesium: a virtual globe engine for the web built using JavaScript and WebGL. Our demos, including satellite and KML visualization, are now live: Use a recent version of Chrome or Firefox.

We are very pleased to announce that this engine will be open source. We plan to get the code up on github in the next month or so, and have an official release in August in time for SIGGRAPH.
We are looking to build a strong community around Cesium, and are interested in collaborating with potential contributors and users. Don't hesitate to email me.

For more information beyond the demos, check out my WebGL Camp Orlando talk, WebGL for Dynamic Virtual Globes [pdf]:

We have ported parts of our book's engine, OpenGlobe, to Cesium. In particular, the  Cesium renderer and polygon pipeline are quite similar to OpenGlobe. In some ways,  Cesium is our next generation version of OpenGlobe.