Virtual Globe and Terrain Rendering

OpenGlobe moved to GitHub

2011-11-09T22:42:00.007-05:00

OpenGlobe, the virtual globe 3D engine we developed for our book, is now on GitHub!

We think GitHub is really cool because it makes it easy to collaborate on open source projects. Please fork at will, and if you do something cool, send us a pull request.

WebGL in Internet Explorer

2011-10-17T21:00:00.000-04:00

Currently, even Internet Explorer 10 will not support WebGL. Meanwhile, all the other major browsers support this new standard. I'm still confident that Microsoft will add WebGL support to IE, but as WebGL developers what can we do in the meantime?

Chrome Frame - an IE plugin that uses the Chrome engine to render web-pages that request so. If an IE user has this plugin installed, all we need to do is include a single meta tag in our WebGL-enabled pages:
```
<meta http-equiv="X-UA-Compatible" content="chrome=1">
```
The major downside is Chrome Frame is a plugin, and, therefore, requires an install. However, we don't need administer privileges to install Chrome Frame, making this option very attractive.
IEWebGL - an IE plugin that implements WebGL. It is lightweight, and was fairly simple to port our large engine to. Unlike Chrome Frame, IE's JavaScript engine still runs our JavaScript, and only the WebGL calls are forwarded to the plugin. The advantage over Chrome Frame is the install is smaller.
jebgl - uses a Java applet to emulate WebGL in IE by forwarding WebGL calls to JOGL. This sounds really promising because it does not require installing a plugin. Unfortunately, I have not been able to get it to work.
webgl-compat - a work-in-progress that implements WebGL with Canvas. I can't imagine that this is going to perform well. The first proof-of-concept rendered 25 rotating triangles at 42 fps without depth testing. Today's hardware pushes billions of triangles per second.
cwebgl - implements WebGL using JavaScript and Canvas, similar to webgl-compat. Again, I don't think this will meet the performance needs of most applications.

Today, I think our best bet is to use Chrome Frame. It worked well in my tests, can be installed without admin privileges, and supports even IE6 (admittetly, I only tested using IE9). Even when IE supports WebGL, we will need to consider these options for our users who can't upgrade right away.

WebGL: GPU acceleration for the open web

2011-09-26T20:00:00.000-04:00

For the past six months, I've been developing with WebGL full-time. Coming from C++, I was not exactly thrilled about the idea of doing web development and coding in JavaScript. To my surprise, I really enjoy JavaScript, and the development tools are quite good.

Joe Kider kindly allowed me to share my enthusiasm for WebGL with his students in CIS 565: GPU Programming and Architecture at the University of Pennsylvania. My talk focused on the motivation for WebGL; WebGL support in current desktop and mobile browsers; and basic JavaScript:

Download the ppt.

The Google Resume Book Review

2011-09-05T11:37:00.000-04:00

I'm not prepping for a job search, but I did just read The Google Resume by Gayle Laakmann McDowell. Gayle is a Penn alum (me too) so I wanted to check out one of her books.

Overall, this is a really outstanding book on the entire hiring process process for technical jobs: networking, career fairs, resumes, references, programming interviews, negotiating an offer, excelling once you are hired, etc. It is useful for developers of all experience levels, but it will be most useful for undergraduate and masters students in computer science or a similar major. Its technical focus makes it hit home more than the general advice given by a university's career services department.

Being on both sides of the hiring process many times myself, I can say that the advice is practical and modern. It also includes lots of stories, like a candidate who used himself as a reference, and when the author interviewed with Microsoft.

Some of the advice you've probably heard, and some you may not have. The advice I like includes getting to know your professors; GPA isn't everything - excel at something; customize your resume for each company; keep your resume concise; use twitter for networking; have an online presence such as a blog, portfolio, or active forum participation; your initial email is really a cover letter; focus on accomplishments over responsibilities; map out your career 7-10 years ahead; find a mentor; and build relationships. There are also a number of subtle tips like watch what you write in an email because it may get forwarded (side note: I also recommend watching what you write about competitive works in a book proposal because it might get forwarded to the work's author. I am two for two on this!).

The chapter on programming interviews and the appendix on behavior questions are quite good. There is a great section on approaches to algorithm design that is useful way beyond an interview.

The section on evaluating an offer is great because it includes important considerations that I think many people ignore. For example, we all consider location from the perspective of do we want to live there and cost of living, but do we consider if there will be other job opportunities there in the future? Also, when looking at an offer, we should consider what the average annual raise is.

This book is really excellent, but if I had to critique a few minor things I would have liked to see more emphasis on contributing to open-source to gain project experience, especially considering that companies like Google and IBM contribute significantly. The chapter on getting into gaming had lots of quotes but appeared to be less based on experience than the other chapters - and also focused more on social and casual games than AAA games that many people aspire to. In fairness, an entire book could be written on gaming though.

All in all, I really recommend this book, especially for students before they start searching for their first internship or co-op.

Electronic Version of Our Book

2011-08-22T07:00:00.004-04:00

We have had several requests for an electronic version of our virtual globe book. I'm happy to say that it is now available on VitalSource. You can read it on your desktop or transfer it to your iPhone, iPad, or iPod Touch. This electronic version is discounted, and there are rental options that cost even less. Pretty cool.

Update: Unfortunately, VitalSource only accepts credit cards from the US and Canada because of rights issues with some publishers. Our publisher, CRC Press, is working on a new website that will solve this problem. We'll keep you posted.

SIGGRAPH 2011 Trip Report: Day Five

2011-08-14T22:32:00.002-04:00

I spent the morning in the Mobile BOF. One theme I am very happy with is that using HTML5, including WebGL, sounds like a viable strategy for targeting mobile devices. In his talk, Jon Peddie predicted HTML5 will have 100% penetration on mobile platforms by late 2012. In all fairness, flash already has 100%. Jon's claim, which was echoed elsewhere during the conference, is that WebGL's biggest problem will be misinformation, not technical.

Neil Trevett also highlighted WebGL in his talk, which included a demo of the WebGL Aquarium with 100 fish running on a Tegra 2 tablet! This was an early, pre-optimized WebGL implementation in WebKit on Android, but it is very promising.

Someone brought up an interesting question: if we develop in HTML5 instead of native apps, how is Apple, who makes a lot of money through their App Store, going to respond? Are they going to treat it like they did flash? I don't recall how this was answered, but my take on it is Apple will have to allow it; otherwise, consumers will reject Apple's products if HTML5 is not supported. HTML5 is not some corner-case technology; it is the web.

There were several other great presentations at the BOF, but my favorite was Tom Olson's talk on writing portable OpenGL ES 2 code (similar GDC 2011 slides). Between this talk and Aras Pranckevičius' talk earlier in the week, I really gained an appreciation for targeting multiple mobile devices. Although mobile segmentation is better than it use to be, there are still several different operating systems and a wide array of hardware with varying performance.

Just like in desktop OpenGL, OpenGL ES has implementation-dependent limits like number of vertex attributes and number of textures. In my own code, I usually try to stay within these limits by doing things like packing multiple values into a single vertex attribute. In Tom's talk, I also learned that the precision qualifiers can cause cross-platform issues. lowp guarantees at least 10-bits, mediump guarantees 16, and highp guarantees 24. This sounds OK at first, except that some platforms may always use 32-bits, so if we only test on these platforms, we never test with lower precision. In addition, highp isn't always supported in fragment shaders; some platforms will silently ignore it, and others will fail to compile the shader. Ugh. This reminds me of shaders that compile with warnings on NVIDIA, and fail to compile on AMD.

It sounds like some platform-compatibility problems can be solved by cleaning up drivers, and others can be solved by cleaning up the specification. Tom noted that the spec doesn't say what to do with bad code. For example, what does divide-by-zero yield? Nan? Infinite? Zero?

Overall, this was a great BOF. I want to thank Tom Olson for organizing it, and for giving me a time-slot to announce the call for authors for OpenGL Insights.

Books

No SIGGRAPH would be complete without checking out all the new books. For starters, Real-Time Shadows by Elmar Eisemann, Michael Schwarz, Ulf Assarsson, and Michael Wimmer is out, and looks excellent. At first glance, techniques like shadow mapping and shadow volumes seem simple, but the devil is in the details; efficient, robust implementations that yield high visual quality are quite difficult. Therefore, a lot can be said about shadows even though it is a sub-field of real-time rendering, which is a sub-field of rendering, which is a sub-field of computer graphics, which is a sub-field of computer science, etc.

I was also happy to see proofs for the second edition of Graphics Shaders: Theory and Practice by Mike Bailey and Steve Cunningham. I am a huge fan of the first edition and am glad to see the second edition is updated for OpenGL 4. However, I was surprised to see that immediate mode, built-in vertex attributes, and built-in uniforms were still used in the example code. Perhaps the code will be updated before the book is printed.

I'm also excited about two intro graphics books that I browsed during the conference. I like to go over the fundamentals once in a while because it keeps me somewhat broad, fills gaps (and I have plenty of them!), and seeing material over again from a different perspective is a great way to deepen knowledge. 3D Graphics for Game Programming by JungHyun Han looks like a pragmatic, concise introduction to graphics.

I was pleasantly surprised to see a partial draft of the 3rd edition of the classic Computer Graphics: Principles and Practice (3rd Edition) by James Foley, Andries van Dam, Steven Feiner, and John Hughes. At almost 1800 pages, this thing is heavy and appears to cover just about every topic in computer graphics, from 2D with WPF to GPU architecture with an NVIDIA GeoForce GTX 9800 case-study. I am definitently getting a copy of this when it comes out (March 2012 according to Amazon), but reading it cover-to-cover is going to take some effort.

Of course, our book, 3D Engine Design for Virtual Globes, was also new this SIGGRAPH. I was happy to meet many people who were excited about it, and glad to hear that it was selling well. I'm taking my 75 cents to Vegas. Kevin is risking his in biomedical startups.

Final Thoughts

This was my fourth SIGGRAPH; each one keeps getting better. I didn't spend as much time in courses as I usually do, but I enjoyed many BOFs and met several people submitting to OpenGL Insights. As I said after attending my first SIGGRAPH, SIGGRAPH is all about meeting people and sharing ideas.

Full SIGGRAPH Trip Report: day one | two | three | four | five

SIGGRAPH 2011 Trip Report: Day Four

2011-08-14T22:31:00.002-04:00

Today had two very important events: the WebGL BOF and the OpenGL BOF. Over the past six months, I have been developing with WebGL full-time, so I have been watching it closely (mainly through the WebGL Camps and Gile's Learning WebGL blog). The WebGL BOF exceeded my already high expectations; it was standing room only and even people outside of the room were trying to peak their heads in. There was a bit of news and lots of demos.

WebGL 1.0.1 is expected to be out in the fall to cover some corner-cases. We can also expect compressed textures soon The most exciting news is that web workers will be able to pass typed arrays without cloning them! We'll have to see how fast it is, but this will make web workers much more useful and suitable for a wider array of tasks like computing bounding volumes and vertex cache optimization, since hopefully thread communication overhead will not be the bottleneck. Even more interesting is that Microsoft worked on this specification. Perhaps they are adding WebGL support to IE. If they want to continue to be a player, I don't see how they will not support WebGL.

The BOF was full of exciting demos, which are on the WebGL Wiki. I'll highlight a few that I really enjoyed. Ken Russell showed a 3D cloth simulation used to flip through Chrome tabs written by a few Google interns. Very cool. Neil Trevett showed the WebGL Aquarium demo running on a Xoom Tablet using a to-be-released version of the native browser. This is super-important to me because we are banking on using WebGL to target both cross-platform desktop and mobile devices.

Mark Danks demoed My Robot Nation, which is a creative business-idea combing WebGL and 3D printing. Users model a robot using a WebGL application. A full-color 3D-printed version of the robot can then be ordered. Pricing wasn't discussed, but I wonder if this will be cheap enough to get wind-spread adoption among our youth. Mark discussed some interesting implementation details, including that the robot's mesh is never actually stored. Instead, the commands to recreate the robot are stored, which can be used to generate the rendering and 3D-printing.

Erik Möller gave an excellent talk and demo on using WebGL and HTML as a game platform. Erik works for Opera, whose browser only has 2-3% market-share, but is used on the Nintendo Wii and has more than 20% market-share on mobile devices. He discussed a platform game developed in HTML5, Emberwind, developed by three summer interns (full original version). It has the very handy feature of being able to switch between Canvas 2D and WebGL for rendering, showing WebGL to be significantly faster. Some numbers I saw showed Canvas 2D at 15 fps and WebGL above 60 fps. Part of this was due to batching draw calls together in WebGL using a texture atlas. Erik made the excellent point that WebGL has a higher barrier to entry but allows more flexibility.

This bird smelled my English Muffin

The BOF included several other exciting demos, including the BrainBrowser by Nicolas Kassis, which uses XHR2 for transferring binary data over HTTP; PhiloGL by Nicolas Garcia Belmonte; and Chrysaora by Aleksandar Rodic, which is doing the bone simulation on the server. See the wiki for the full list of talks and demos. I want to thank Ken Russell for organizing an awesome event and for giving me a time-slot to announce the call for authors for OpenGL Insights.

The OpenGL BOF was also excellent this year. Of course, the big news was the release of OpenGL 4.2. This release has a number of new features that expose hardware features, including ARB_shader_atomic_counters and ARB_shader_image_load_store. Both of which allow shader instances to communicate to some extent. Shaders can now have side-effects. GLSL shaders are starting to feel an awful lot like CUDA (and OpenCL) kernels.

GL 4.2 also introduces ARB_texture_storage, which helps guarantee a texture is complete. This reminds me of using templates for immutability in Longs Peak. I'm glad to see those API designs making their way into OpenGL. For much, much more information on GL 4.2, check out Christophe Riccio's review.

In other OpenGL news, a version of the conformance test suite for OpenGL 3.3 and selected extensions is expected to be complete in November. GL drivers have been getting much better in recent years, and this test suite is a huge step in the right direction. In his ecosystem update, Jon Leech also mentioned they are tidying up the spec to have less undefined-behavior. I want to thank him for mentioning our call for authors for OpenGL Insights.

The BOF ended with an excellent talk, Brink Preferred Rendering with OpenGL, by Mikkel Gjøl. He described the rendering in Splash Damage, including its deferred rendering pipeline, use of occlusion queries, and virtual texturing. He said OpenGL works for AAA games, and had several useful requests including a lower-level API (not the first time we heard this at SIGGRAPH); performance warnings; and display lists, which are widely used on consoles.

Full SIGGRAPH Trip Report: day one | two | three | four | five

SIGGRAPH 2011 Trip Report: Day Three

2011-08-11T19:00:00.003-04:00

I spent the morning in the Out of Core talks - a topic quite dear to me considering my master's thesis.

Won Chun's talk, Google Body: 3D Human Anatomy in the Browser, was a modified version of a similar talk from WebGL Camp 3. He discussed the mesh compression and WebGL rendering used in Google Body. My favorite part was how vertex cache optimization, which is used to optimize rendering, also helped improve compression by increasing coherence. There was lots of other goodness like how rendering with float vertex components was faster than using short components even though floats require more data. Won's compression code is now open source.

Cyril Crassin gave a very impressive talk titled Interactive Indirect Illumination Using Voxel Cone Tracing: An Insight. It showed fast, approximate, two-bounce global illumination by grouping coherent rays of reflected light in a pre-integrated cone. I obviously do not work in GI, but if you do, this talk is definitively worth checking out.

Another very impressive talk was Out-of-Core GPU Ray Tracing of Complex Scenes presented by Kirill Garanzha. They interactively rendered the Boeing 777 model, a classic "massive model", on an NVIDIA GeForce GTX 480 at 1024x768. For many views, it looked like it was 200-300 ms per frame with a cache size of 21% of the model (360 million polygons). I'm pretty sure only diffuse shading was used, but even so, this is outstanding work.

One course I never miss at SIGGRAPH is Beyond Programmable Shading. A lot of material from this SIGGRAPH course makes its way into our course at Penn. I wasn't able to make all the sessions this year, but I will certainly catch the rest on SIGGRAPH Encore.

A major course theme was system-on-a-chip (SOC), where both CPU and GPU cores are on the same chip. This has the benefit of eliminating the system bus between the CPU and GPU, which is often a bottleneck.

I really enjoyed the panel What Is the Right Cross-Platform Abstraction Level for Real-Time 3D Rendering? with David Blythe, Chas Boyd, Mike Houston, Raja Koduri, Henry Moreton, and Peter-Pike Sloan. They discussed the tension between application developers, middleware developers, OS developers, and hardware vendors when it comes to APIs like Direct3D and OpenGL. It was generally accepted that D3D/OpenGL are at the right level of abstraction, but need tweaking. Various ideas were discussed, including shorter specs; merging compute and rendering APIs; new APIs for system-on-a-chip; and even having one low-level rendering API and multiple high-level rendering APIs, with the argument that there are many abstractions (programming languages) that do the same thing: change the CPU's instruction pointer.

My favorite part about the panel was the discussion on what goes on in the driver. There is significant pressure for hardware vendors to do well on game benchmarks so many hacks are added to optimize for specific games. The games may not be using best practices, so they are "rewritten in the driver" making the driver really bloated - what a mess. This reminds me of the special allocator mode added to Windows 95 to workaround a bug in SimCity, who was using memory right after it was freed.

All of these game-specific hacks (I almost called them optimizations) lead to non-obvious fast-paths. What vertex-format should I use? As an application developer, I don't know. Well, I sort of know, but when killer-next-gen-game comes out, which uses double-precision texture coordinates, should I also switch to make my application run faster? Introducing a low-level rendering API would fix many of these problems and remove the bloat from the drivers.

Another interesting topic in this discussion was why closed-source drivers are higher quality than open-source drivers. The reasons are quite understandable: closed-source drivers can hide hardware bugs, hide intellectual property that isn't patented, and hide third-party code. It also sounds like there are a lot less open-source developers (40-to-1?) and changes in the Linux kernel can affect the drivers.

Every year, the Beyond Programmable Shading ends with a thought-provoking panel, but this panel was by far the best one!

Full SIGGRAPH Trip Report: day one | two | three | four | five

SIGGRAPH 2011 Trip Report: Day Two

2011-08-10T01:03:00.002-04:00

I started off today at some of the NVIDIA exhibitor sessions. In the OpenGL & CUDA-Based Tessellation talk, Philippe Rollin made an excellent point about tessellation shaders: the result can be cached using transform-feedback, and used for several frames. This is just one of the many examples of the synergy among recent hardware features. He also convinced me that tessellation can be useful for real-world terrain data by reducing the amount of preprocessing - and everyone hates preprocessing! In the final part of this talk, Miguel Ortega talked about tessellation in Thor. An interesting stat he mentioned is that the biggest asset used 900 4K textures - wow! Movies are quite a bit different than real-time rendering.

I also stayed for the Parallel Nsight 2.0 and CUDA 4.0 for the Win talk by Jeff Kiel. Parallel Nsight has some very impressive Direct3D debugging capabilities, and I'm looking forward to full OpenGL support. I will be ecstatic when I can set breakpoints in a shader. Parallel Nsight is also a great tool for GPU Compute debugging. I want to work this into our GPU course, but requiring two GPUs will call for some careful logistics. However, it will run on some laptops.

I spent some time in the Advances in Real-Time Rendering course, but I spent the bulk of my afternoon in the How to Write Fast iPhone and Android Shaders in Unity Studio Workshop by Aras Pranckevičius and Renaldas Zioma. So far, this was my favorite talk of the conference. It was full of battle-won tips on optimizing shaders for mobile platforms. I haven't done any mobile development yet, but it sounds messy with all the different architectures. For example, on some architectures you should pack varyings into a vec4, and on others you shouldn't. Some architectures scale better than others as more ALU instructions are used. Some architectures care what precision qualifier you use (lowp, mediump, highp), some don't, and some are slow when swizzling lowp precision variables.

Some themes were uniform across all architectures though: baking lighting into textures to avoid heavy ALU instructions like the pow() function in specular lighting; combining several post-processing passes into a single pass to avoid fill-rate; and pragmatic front-to-back rendering for early-z, e.g., render the large player, followed by the environment, followed by enemies which are likely occluded, and finally the skybox. I really enjoyed how this talk was realistic, and even mentioned the reality of optimizations not working and tools crashing. These things happen to me too, and I always tell my friends so you really want to be a graphics developer?!?!? I hope they give a similar talk next year, and that SIGGRAPH gives them a bigger room with more seats.

Full SIGGRAPH Trip Report: day one | two | three | four | five

SIGGRAPH 2011 Trip Report: Day One

2011-08-08T12:55:00.002-04:00

Vancouver is awesome. It is clean; the people are unbelievably nice; and the convention center is right on the water and easy to navigate. Let's stop going to LA every other year, and start going to Vancouver!

I spent the afternoon in the Introduction to Modern OpenGL Programming course taught by Edward Angel and Dave Shreiner. It was packed, which shows how important OpenGL has become, especially given OpenGL ES and WebGL. I've been a big fan of this course since I first attended it in 2008. They've done a great job of keeping it up to date. It is a nice introduction to OpenGL, including VBOs, VAOs, GLSL, uniforms, transforms, lighting, and texture mapping. They briefly covered tessellation and geometry shaders, but time was tight. I'm looking forward to this class being a full day in the future.

I usually don't make it to the paper sessions, but I always attend the papers fast forward to get an overview of the research being presented. Even the overflow room was packed this year. One paper that jumped out at me was HDR-VDP-2: A calibrated visual metric for visibility and quality predictions in all luminance conditions by Rafal Mantiuk et al. It describes an algorithm for comparing images. They suggest use-cases like determines the quality-loss due to compression. I am interested in it for a much simpler use-case: unit tests. That is, I want to compare images rendered by our 3D engine on different hardware and different drivers, and I don't what false failures for slight differences. This is a surprising hard problem to solve, and at some point, I'd like to look into HDR-VDP for doing so.

A tip for SIGGRAPH attendees: you can buy merchandise from previous SIGGRAPHs at a steep discount at the SIGGRAPH Store. I bought two tee-shirts for $3 each. They also have things like polo shirts, hats, and coffee mugs for dirt-cheap.

One more tip: there is a separate registration line for contributors that is much shorter than the normal line.

Full SIGGRAPH Trip Report: day one | two | three | four | five

The Passionate Programmer Review

2011-08-06T07:00:00.001-04:00

Jon McCaffrey's review of The Passionate Programmer by Chad Fowler motivated me to read it myself. I used to read lots of books like these, but over the past six or seven years, I’ve buried myself so deep in graphics that I've read very little general development books. It’s time to change that.

The Passionate Programmer is well worth a read. At about 200 pages, it is short, readable, and inspiring. It contains 53 bitesize chapters on being productive, marketing yourself, staying sharp, etc. I agree with the vast majority of the book's advice. It is a particularly great read for students and new developers; it will get them in the proper mindset to be awesome developers as Chad would say. If you are more experienced, you are probably already doing many things in this book; if not, you should consider them.

One of my favor chapters is 4. Be the Worst, which suggests surrounding yourself with the best developers you can, because doing so makes you grow faster and perform better. I couldn't agree more!

You would think that 14. Be a Mentor contradicts the advice of being the worst, but it does not. It is important to be a mentor to new developers because teaching is one of the best ways to learn. Do I really know how the automated build and test system works? I will once I try to explain it to someone.

Being a mentor also helps a team gel and integrate new developers quickly. If there is one thing our industry needs to get better at, it is mentoring. Electricians, plumbers, and tattoo artists do apprenticeships. Software developers do not. How often do we sit down with the experts in our development teams and learn from them? Probably never, or not often enough at best.

In 28. Eight-Hour Burn, Chad argues to only work eight-hour days but work with the utmost intensity. Working longer days leads to burning out, wasting time, and less overall long-term productivity. I agree; however, I am a hypocrite. Given my outside writing and teaching activities, I am consistently over 70 hours a week, and sometimes much higher. The only justification I have is writing and teaching are different enough from developing that the burn out isn’t as severe. I know I can't maintain this pace forever though.

Perhaps 39. Let Your Voice Be Heard is my favorite piece of advice. Chad suggests thinking beyond your current employer and contributing to the industry as a whole, first with a weblog (I don't know why he didn't just say blog), and eventually through publications and presentations. I really like this advice because there are a lot of sharp people in our field, and it is great to have everyone share ideas.

I don't think any advice in the book is terrible, but some needs to be put into perspective. For example, in 27. Learn to Love Maintenance, it is argued that maintenance development can allow for freedom, creativity, and direct-customer interaction. For old, large applications, this isn't always true. If you are working on a twenty-year old, multi-million line application that has seen the hands of hundreds of developers at various stages in their careers, maintenance is often a test of patience. For example, do we really want to continue to design legacy APIs using COM? Is making our code const correct easy when all the code we call is not? Do we really want to integrate old code using a struct for vectors with new code using a class? No. we want to build our skills using modern technology and techniques.

I advise interns and new grads to get in on the ground floor of a new project. They will be given the best opportunity and most responsibly. They will see the big picture, and will accelerate their skills faster than being bogged down by long build-times, legacy code, and legacy mistakes. The contractor who built the house learned much more than the contractor who remodeled the bathroom. With all this said, if you get an opportunity to work on a large, outstanding piece of software - say the Linux kernel, for example - you should go for it.

One final comment: this book is a revised edition of the book My Job Went to India: 52 Ways to Save Your Job. Naming a book is really important, just like naming software, classes, functions, variables, etc. With the original title, I would not have paid this book any attention. The revised title – and I assume content – made it really appealing. Naming is hard.

Overall, The Passionate Programmer is an inspiring, worthwhile read.

Book Signing and More at SIGGRAPH 2011

2011-07-05T11:00:00.002-04:00

Stop by the A K Peters / CRC Press booth at the SIGGRAPH exhibition on Tuesday, 08/09/2011, from 1:15-2pm for our virtual globe book book signing. Even if you don't have (or want) a copy of our book, stop by to chat about anything related: OpenGL, 3D engine design, computer science education, etc. If you have a copy you want me to sign but can't make the signing, email me (pjcozzi@siggraph.org), and we'll meetup sometime during the conference. If you're interesting in submitting a proposal for OpenGL Insights, also email me if you want to chat during SIGGRAPH.

If you really want to stalk me, and I fully encourage it, stop by the poster session either right before the book signing on Tuesday, 12:15-1pm, or on Wednesday, also 12:15-1pm. I will be presenting a poster I worked on with Deron Ohlarik called A screen-space approach to rendering polylines on terrain. We are quite happy with the technique and are even using it in commercial code. We are also honored that it was mentioned on the Real-Time Rendering blog (full disclaimer: Eric reviewed the abstract before we submitted it. He also reviewed the abstract for the poster I presented last year. Man, I owe him).

In other book-related news, Brano Kemen from Outerra wrote the first book review we are aware of, and there has been some book-related discussion on the NASA World Wind forums. We're excited that a lot of people are excited about our work.

Virtual Globe Book Updates

2011-07-02T16:30:00.004-04:00

We recently added several things to our book's website, including a zip of the example code with build instructions for Windows and Linux (Ubuntu); a zip of most of the book's figures, available under fair use; the bibliography with hyperlinks that all work as of today; and the back cover:

Posting the figures and bibliography is a great idea we borrowed from Real-Time Rendering, who has set the bar for book websites quite high.

More exciting news: Amazon says our book is "in stock but may require an extra 1-2 days to process." Hopefully it is shipping by the time you read this.

Resume Tips for Computer Science Students

2011-06-24T07:15:00.004-04:00

Here are some resume tips I've learned over the years. I've interviewed about 100 computer science candidates, mostly interns, and have been a technical recruiter at least a dozen times at university career fairs. I've seen thousands of resumes, and have hopefully learned some things you will find useful. For the most part, I've left out obvious recommendations and, instead, focused on tips you may not have heard - or heard from the same point of view. In my youth, I was heavily influenced by Joel, so I probably borrowed some of these ideas from him.

1. Backup your Buzzwords

Almost every computer science resume has a section that looks like:

Skills:  C, C++, C#, Java, .NET, WPF, OpenGL, Direct3D, GLSL, Visual Studio, Eclipse, NUnit, JUnit, NAnt, ...

I'm tempted to recommend removing this section entirely. It does have some uses though; it is good for google searches and HR/manager buzzword hunters. It can also paint a quick profile: is this person a client-side graphics developer? a server-side PHP/MySQL developer? An architect astronaut?

In order to play the game with the less technical folks, I am OK with candidates including this section, but these skills need to be backed up throughout the resume. For example, if OpenCL is listed but I don't see any evidence elsewhere in the resume, I will be skeptical. If I ask about it in an interview and the candidate doesn't have any experience or even exposure to the topic, they have just lost integrity points.

If you list something in the skills section, make sure it is proven elsewhere in your resume, e.g., "Implemented a GPU-accelerated cloth simulation using OpenCL, which resulted in a 30x performance improvement over a multithreaded C++ version." The buzzword hunters will give you extra points for having multiple instances of the buzzword, and technical folks are more likely to believe you.

2. List Coursework Strategically

This motorcycle has nothing to do with
resumes but it sure is fun to ride.

For a student or recent graduate, it is a great idea to including a "Selected Courses" or, better yet, "Favorite Courses" section that highlights some unique courses you have taken. It is an even better idea to tailor this section, and your resume in general, to each employer. Applying to Google search? Include Distributed Systems and Machine Learning. Applying to Pixar? List Computer Graphics and Physically-Based Animation.

Do not list a course that you cannot discuss intelligently. You should have a reasonable grasp of the subject and a story about a related project. For example, I took machine learning in grad school. I got an A and somehow even passed the PhD qualifier, but I can't do machine learning to save my life. I can pronounce fancy algorithms like boosting and principle component analysis, but I can barely tell you the difference between them - not something worth discussing in an interview.

Do not list required courses! This is common with underclassmen, but I still see it done by upperclassmen who have more interesting things to list. If I know your major is computer science and you go to a reputable school, I also know you took intro to programming, calculus, and discrete math. Don't list them; they get in the way of the good stuff.

3. Include Your GPA

If you are an undergraduate, masters student, or recent graduate, include your GPA in your education section. Why? Because if you don't include it, the recruiter is going to think it is low - really low - like 1.5 low. What if you don't have a 3.0 GPA? Study more and play World of Warcraft less. More seriously, if your cumulative GPA is not great, still include it but also consider listing your in-major GPA or last-semester GPA - clearly marked. Some students do not practice drinking enough in high school and party too much freshmen year, resulting in poor grades (disclaimer: underage drinking is bad.). Listing the previous semester's or year's GPA gives the student a chance to talk to their improvements - in school work, not alcohol tolerance. I recommend listing your in-major, or even in-minor, GPA only if it is higher than your cumulative GPA. If it's not higher, think twice about your field.

Wait a minute. I thought GPAs only matter if you are going to grad school. No one in industry looks at those things, right? Given my extensive teaching experience (one semester), I can say that some of my brightest students had some of the worse grades. They were too busy raising money for their startups or going on job interviews to do every assignment rigorously. Students with the best grades were really organized and conscientious - absolutely fantastic characteristics to have, but not necessarily a guaranteed indication of raw brilliant. Case-in-point: I had a 3.97 in grad school and I am continuously humbled by the intelligence of people in our field. A great GPA can help you by showing your rigorousness; a poor GPA isn't necessarily going to bury you but it will mean you have some explaining to do. Many companies have a minimum GPA require, so I'd play the game to show that you can.

Some people will say that your GPA is only important for getting your first job. After that, leave it off your resume. Baloney. Why not drop the name of your university too? Why should I care that you went to CMU 20 years ago? Because you got in! If your GPA was low or average, OK, drop it. If your GPA was really high, leave it. If you were an over-achiever in college, you are probably still an over-achiever unless your motivation changed.

I don't have a PhD so I can't say if a PhD student should list their GPA but I will anyway. I have never seen a candidate with a PhD be evaluated on their GPA. I'm not saying it doesn't happen, but I've never seen or heard of it. I have heard that if a PhD student's GPA is too high, they should be focusing more on research. If that is really the case, then why do they take classes at all? Go ask someone who is qualified.

4. Don't Ignore What You Did in High School

When you are looking for an internship, don't think that high school isn't important, especially if you are a freshmen or a sophomore. Yes, freshmen can and should land internships. I had two offers from Intel for the summer after my freshmen, and I didn't know anything. Well, at the time I thought I knew everything.

If your high school class rank was really high, put it. Valedictorian - put it. President of the computer club? Put it. Fail history class because you were busy coding Android games in Java? PUT IT. Sell your Android-based startup to Google on your 18th birthday? I should be working for you.

It is espeically important to include self-started personal programming projects, even if you coded them when you were 14. Hell, say "Implemented a pacman clone for the Xbox 360 using C# and XNA when I was 14." If I see that on a freshmen's resume, I want to hire them even if they don't know what a skip list is. They'll never use one anyway.

As you gain experience, it is OK to remove things you did in high school with more recent and stronger experiences.

5. Include Books and Conferences

You're passionate. You read books, go to conferences, and argue with your smart friends to sharpen your skills. Everyday, you make yourself a better developer.

Let your passion show through on your resume and include a section with a few of your favorite technical books. How about Code Complete, Peopleware, The Pragmatic Programmer, Effective C++, and Real-Time Rendering? Those are my favorites. Pick your own. Be ready to discuss them. If your interviewer has read the same books, there's a good chance you will hit it off. If they haven't read the classics, you probably want to work somewhere else. If you haven't read the classics, start yesterday.

As an aside, my first day as an intern at Intel, I asked if I should read any books. My mentor, John Spotswood, recommended Code Complete. Reading that book brought me to a new level in software development - granted I was 18 so I had no where to go but up. Intel was nice enough to pay for any technical books I wanted to read, so Code Complete was just the beginning. Peopleware, The Pragmatic-Programmer, and others followed. I always let the interns I work with now borrow these books and others.

In addition to listing your favorite or most influential books, list the conferences you have attended, or better yet, volunteered at, or even better yet, had work accepted at. This sends the message that you are keeping your skills current, know what's on the cutting edge, or are even defining the cutting edge.

6. Be Specific

In 2003, the stars aligned in such a way that I was accepted into IBM's Extreme Blue internship program. This is an outstanding program that I encourage all passionate computer science students (BS, MS, and PhD) to apply to. I believe much of the program's success is due to Kieran Lal, the program's co-founder and one of our mentors for the summer. Kieran is a great culture-building leader that is truly interested in the long-term success of every intern. Kieran gave great advice, and here I share one piece of it: be specific.

What is stronger:

   "Implemented a distributed storage system"

or

   "Implemented a Linux-based distributed filesystem in C (~20K lines) tested with 20K concurrent users"?

Being specific backs up your buzzwords and gives the reader context and scope. What does this mean?

   "Implemented an application to track chipset validation"

Is it:

   "Implemented a database front-end to track chipset validation in MS Access 97 in an afternoon"

or:

   "Lead a team of five developers creating a chipset validation tracking application with an HTML5 and Android front-end. Used SQL Server with stored procedures on the back-end."?

A fun side story about Kieran is on the first Friday of our internship I organized a party with all the interns at my lovely apartment IBM was paying for. As the party started picking up, I got a phone call from...Kieran. I figured I was in trouble. No, he was at the apartment's entrance and needed me to buzz him in! I don't know how he found out about it, but I'm glad he did.

7. Keep it to One Page

When I was a know-it-all intern at Intel, I spent an afternoon toying with SQL Query Analyzer. So I thought it was a good idea to beef up my resume:

"Optimized SQL queries using Microsoft SQL Query Analyzer"

I added lots of things like this, which turned me into an 18 year old intern with a two page resume. I brought it to an internal job fair, and people didn't know what to do with it. Staple it? Paperclip? More importantly, they couldn't see the meat in the resume because all the SQL Query Analyzer junk got in the way.

As a recruiter, I got lucky one time at a university career fair and noticed that a resume was actually two-sided - and all the good stuff was on the back side! I wonder how many two-pages resumes I missed.

If your an undergraduate, keep your resume to one page if your going to the career fair. A PhD student or developer with a few years experience can definitively have multiple pages. I actually keep two resumes: a short academic-focused CV and a longer industry-focused resume.

Need to save space? Leave off "References available upon request." That is always implied.

8. Link to Your Personal Website

The top of your resume should have a link to your personal website, which acts as a portfolio with screen shots of your work and possibly code examples. You don't have a personal website? Make one. Everyone else is doing it so you need it to be a player. A development blog is also appropriate and perhaps even better.

In 2000, I had a personal website that included some games I wrote in Turbo Pascal and assembly when I was 15. When I started my internship at Intel that summer, I learned that one of the developers downloaded my code and reviewed it, and that played a big role in me getting the job offer.

In Closing

In an interview, I always try to bring out the best in a candidate. I hate walking out of an interview thinking the candidate might be good but I wasn't able to elicit it. In that case, I have to say no hire. When looking at a resume, I have to go by what's on paper. I can't interact with the candidate hoping to see them shine. Hopefully, some of these resume tips will help our computer science students put their best foot forward.

Other tips? Comments? Criticisms? Let's discuss.

OpenGL Insights: Call for Authors

2011-05-22T13:50:00.004-04:00

Christophe Riccio and I are starting an exciting new book project. Please join us:

It is with great enthusiasm that we invite you to contribute to OpenGL Insights, a book containing original articles on OpenGL, OpenGL ES, and WebGL techniques by the OpenGL community and for the OpenGL community: from game programmers to web developers to researchers. OpenGL Insights will be published by A K Peters, Ltd. / CRC Press in time for SIGGRAPH 2012.

Given the wide array of OpenGL platforms, from Mac desktops to Android phones to web browsers, we invite you to submit article proposals on all aspects of OpenGL development, including performance tuning, recent GL features/extensions, application architecture, vendor-specific techniques, WebGL, and interoperability with other APIs. We are interested in proposals based on your unique real-world experience using OpenGL. Some ideas include:

OpenGL performance, for example:
- Best performance practices for using vertex buffers
- Best performance practices for texture streaming
- Performance and memory profiling techniques
- 64-bit performance considerations
- Multithreading with OpenGL
Modern OpenGL 3 and 4 programming, for example:
- Introduction to tessellation
- Image load and store
- Programmable multisampling
- Using shader subroutines effectively
- Managing uniform data
- Strategies for debugging OpenGL applications
Application architecture, for example:
- Porting between Direct3D and OpenGL
- Writing portable code between OpenGL, OpenGL ES, and WebGL
- Designing an OpenGL-based graphics engine
- A testing framework for OpenGL applications
- Shader architecture best practices, e.g., shader binaries and separate shaders
- Cross-platform programming with OpenGL
- Tools, libraries
Vendor-specific techniques, for example:
- Understanding and optimizing for specific hardware and driver implementations: AMD, Apple, ARM, Imagination Technologies, Intel, NVIDIA, Qualcomm, S3 Graphics, etc.
- Bindless Graphics: GL_NV_shader_buffer_load and GL_NV_vertex_buffer_unified_memory
- How VAO works on AMD drivers
- Taking advantage of deferred tile rendering on PowerVR
- How GLSL compiler works
- Understanding multithreaded OpenGL drivers
OpenGL ES, for example:
- Best practices for targeting both desktop and mobile devices
- Targeting multiple mobile device platforms
- Developing with power consumption in mind
- Differences between desktop and mobile devices
WebGL, for example:
- Introduction to WebGL for web developers
- Introduction to WebGL for OpenGL developers
- Optimizing WebGL applications
- Writing large-scale software in JavaScript
- Understanding web browser implementations of WebGL
- WebGL interoperability with WebCL
Interoperability, for example:
- Hybrid OpenGL and OpenCL/CUDA rendering pipelines
- Working with both OpenGL and Direct3D
- OpenGL interoperability with OpenCL and CUDA
Inspirational thoughts and experiences:
- OpenGL's 20th anniversary: history and evolution
- ARB members and OpenGL developers interviews
- OpenGL software making of
- Daily programmer experiences with OpenGL

These are, of course, examples. Please don't feel limited to these areas.

The planned schedule is:

August 15, 2011	Proposals due
September 1, 2011	Authors selected
November 1, 2011	Articles due
December 1, 2011	Peer review feedback due
December 15, 2011	Revised articles due, all articles sent to publisher
January 1, 2012	Supplemental material due, e.g., videos, source code, etc.
SIGGRAPH 2012	Book released

Please send proposals to editors@openglinsights.com using this example proposal as a template by August 15th.

Proposals should include the title, your name and affiliation, a one-page abstract, and anything else you feel helps convey your article such as related images or references. Proposals must demonstrate the author's real-world OpenGL experience and ability to write clearly. Proposals can have multiple authors, and a single author can submit multiple proposals. There is no required article length, but we expect most articles will be 5-20 pages. Example code can be written in any language on any platform.

Please feel free to contact us for additional discussion. We're looking forward to putting together a valuable book for the OpenGL community.

Thanks,
Patrick Cozzi and Christophe Riccio, Editors
www.openglinsights.com

Book Update

2011-05-16T20:00:00.003-04:00

We have some exciting book-related updates. For starters, we made a small website for our book, www.virtualglobebook.com, and posted several samples:

Detailed table of contents
Chapter 1: Introduction
Section 3.1: The Need for a Renderer
Section 4.3: GPU Ray Casting
Section 12.1: Level of Detail

We also found our book on the cover the latest CRC Press catalog. Exciting! Finally, we wrote a short book-related article in our company's newsletter.

Things are wrapping up nicely and I suspect the manuscript will be off to the printer any day now.

Reflections on Teaching GPU Programming and Architecture

2011-05-08T08:15:00.003-04:00

I just finished teaching CIS 565: GPU Programming and Architecture, a graduate-level course on programming GPUs using mostly GLSL and CUDA, at the University of Pennsylvania. Being my first time teaching, I gained a lot of valuable insights, which I will share here. These ideas are on teaching computer science in general, not necessarily about the GPU.

For eye candy, I sprinkled screenshots of our student projects throughout this post.

1. Exams have a hidden agenda.

At least my exams. On the surface, exams are used to evaluate students, and ultimately assign grades. Historical, this course never had exams. Given its pragmatic, hands-on material, grades were primarily based on coding assignments and a final project.

Screen Space Fluid Rendering - Leftheris Kaleas

This year I added a final - not because I wanted to evaluate students on their ability to think about the GPU under pressure, but because I wanted them to study for the final. It is a valuable exercise to go over material a second time, especially after we've had hands-on experience, to gain new insights. For example, the performance implications of register pressure will seem trivial once the student has some coding experience, but may have been foreign when first introduced. Likewise, going back and looking at GLSL after learning CUDA, will lead to a deeper understanding of GLSL.

In general, one reason people go to grad school is to gain a deeper understanding of topics they already have some exposure to. Studying for a final has the same effect on a more local scale.

So if I am only interested in students studying for a final, but not so much in how they do, what did I do? Two things. First, I made the final only worth 10% of the semester grade. That is not enough to ruin someone's grade if they perform poorly, but it can be the difference between an A and a B. The second technique I use is a bit more interesting...

2. Crowdsourcing the final is fun.

To help students study, I requested they make a ten question exam (and answer it!) with questions of different types, e.g., short answer, coding, etc., and of different difficulties, e.g., easy, medium, hard, and challenge. I made this "take-home" portion of their final worth 10%. It is a good studying technique to get in the instructor's head and think about what they are going to ask. I also joked that I might take all of their exams in the time they take my final.

After I handed out the final, I told the class that their exams were so good and hard that I wouldn't be able to take them while they took my final. In fact, I didn't even make their final - they did. Every single question on their final was from one of their exams. The class got a big kick out of it.

When looking through the student-made exams, I was simply amazed at the collective breadth and depth of knowledge of the class. It was also interesting to see different students with different specialties - each exam covered diverse topics, but some where biased towards GPU architecture, while others were heavy on GPU compute, while others favored rendering. Overall, the quality of their questions were quite good. Some of the exams were really hard too - harder than I made the final.

Am I nervous that a student taking this course in the future will read this post or hear from previous students how the final is made? Maybe the entire class will self-organize and send their exams to each other before the final. If a student reviewed every exam, they would know every question that will be on the final. Is that cheating? I don't know, but students rigorously studying for a final sounds like a great problem to have. After all, the main point of my final is to have them revisit the material.

Mobile Depth of Field as Post-Processing using
OpenGL ES 2.0 - Han Li and Qing Sun

3. Student confidence is important.

Perhaps this is my most controversial idea...

Fast Human Detection on GPU - Fan Deng

Some courses have notoriously difficult exams and homeworks. The mean score may be in the 50s, 40s, or even lower, and the standard deviation is large indicating that some students get it, or at least can handle difficult problems, and some students don't. This is common in algorithms courses across universities.

I believe the rational is challenging students to push their limits and think rigorously ultimately leads to a deeper understanding of the material. At the least, it leads to a certain respect for the subject.

I think this approach has some merit, but I am on the other end of the extreme. I want to see a mean around 90% with a tight standard deviation, indicating that everyone is getting it for the most part. In practice, I saw means from 75 to 94 and standard deviations from 4 to 33.

A higher mean and tighter standard deviations means I didn't make every question incredibly difficult. I like to build the student's confidence by allowing them to answer most questions if they have a solid understanding of the material. I want them to finish the course and feel that they can program CUDA in a production environment. I don't want them to think "I couldn't do the CUDA assignments in class; there is no way I can program GPUs in the real world."

With that said, this doesn't imply that I make homework problems trivial. Have a look for yourself. In future semesters, I will continue to add harder questions, but perhaps weight them lower.

Regardless of difficulty, it is actually hard to answer most of my questions by looking at the slides alone, which leads to our next topic...

4. Build an interactive classroom.

Tile-based Techniques in Deferred Shading - Sean Thomas

With only 12 registered students, plus some lurkers as they are called, we were very successful in building an interactive culture in the classroom. In an average 80 minute lecture, there might be 20-60 student comment/questions. The best situation is when students start talking to each other and I largely remove myself from the discussion and just facilitate.

To create an interactive culture, my slides rarely have answers, but often have questions. I start each topic with a question. For example, when introducing memory coalescing, I ask if given a matrix in row-major order, is it better for a thread to access elements column by column or row by row? Some questions are quite fun because the answer for a CPU and GPU are different.

I think I got lucky with an interactive classroom. I didn't realize it until Milo pointed it out, but students in my class self-selected; they were there because they wanted to learn about the GPU, not because it was a required course. They could have taken any number of courses instead. The other thing that helped with interaction was the class size. With 12 students, I knew all of them reasonably well, and many of them knew each other. I imagine it is a significant challenge to maintain interaction as class size increases.

5. Teaching at the graduate level requires depth of knowledge.

There is, of course, a downside to an interactive classroom: hard questions. Students are looking for deep discussion beyond the surface of the slides.

Efﬁcient Real-Time Shadow Rendering - Stuart Summerﬁeld

I'm a graphics guy, so I could handle most graphics questions with reasonably deep answers, usually from battle-tested experience.

I'm also pretty familiar with the compute side of GPU programming, but I don't have the same day-to-day experience with it, so fielding some compute questions was hard. I'm embarrassed to admit that one lecture early in the semester I was asked if the warp size is 32 threads and an SM (streaming multiprocessor) only has 8 SPs (stream processor) on the G80, how is the warp executed? Good question. Actually, great question. It even appeared on our final. At the time I didn't know.

I suggest two ways to handle questions you don't know. First, say you don't know and turn the question back to the class. Sometimes someone will know. Second, write it down and cover it at the start of the next lecture. That is what I did for the above question and a handful of other questions throughout the semester.

The wrong way to answer these questions is to make something up.

6. Reusing other instructor's material is hard.

GPU-Accelerated Fluid Simulation - Kalin Gochev

I have a minor case of Not-Invented-Here Syndrome when it comes to code, but I have a major case when it comes to course material, particularly slides. I find it very difficult to teach off other people's slides. I want to present topics in a certain order, in a certain manner (usually with lots of questions), and I want certain examples (usually from my real-world experience). I want slides with lots of images and not a lot of text.

Even though this course was taught for five years prior, the vast majority of my lectures were new or changed significantly - not because the old course material was bad, actually, it was quite good, but because I wanted a certain style. This came at significant effort. I found, on average, preparing an 80 minute lecture requires 12 to 15 hours, assuming some background in the material. For example, even though I am familiar with GLSL, preparing a lecture is time consuming because I need to carefully craft the discussion and double check everything. Preparing a lecture on topics I know less about, e.g., Fermi, is even more time consuming.

I did reuse slides in one lecture though. Kayvon Fatahalian's presentation, From Shader Code to a Teraflop: How GPU Shader Cores Work is the best introduction to GPU architecture that I have ever seen - and it made teaching CUDA afterward much easier. Reusing the slides was still quite a bit of work; I watched Kayvon's talk on SIGGRAPH Encore a few times and went over his slides and notes several times before I felt comfortable giving the talk. By the way, Kayvon's slides are from the Beyond Programmable Shading SIGGRAPH course, which is a great resource in general (2008, 2009, 2010).

7. Teaching takes a tremendous amount of time.

On the surface, teaching one class doesn't sound like much work. Teach two 1.5 hour lectures a week, hold another three hours of office hours, prepare lectures, and read and write some email. What is that? Maybe 10-20 hours a week? For me, it was more like 30-40 hours: 3 hours lecture + 3 office hours + 24-30 hours preparing lectures + 3-8 hours email.

Email, really? For this past semester, I have over 500 gmail conversations, each averaging between two and ten emails. I feel staying on top of email is a huge part of teaching well.

I'm under the impression that teaching a course for the second time is much less work. I suspect the 12-15 hour prep time drops to 1-4 hours depending on how much material you change. Also, as obvious as it sounds, make sure to create the homework/exam answers at the same time you make the questions!

There were a few weeks were I didn't have to prepare lectures because the student's gave presentations...

8. Student presentations are for building experience.

A tradition Joe Kider started a few years ago, and I continued, is for each student to use half a lecture to present a GPU-related topic. The motivation was to help them research their project, give them experience presenting, and provide the class with exposure to diverse GPU topics.

CBench: Analyzing Compute Performance for Modern
NVIDIA and AMD GPUs - Varun Sampath

As instructor, I helped provide the presentation's outline and gave the presenter immediate, detailed feedback. I also tried to ask a lot of questions during their talk. Depending on the topic, this can be challenging. If a student presents on a topic I know a lot about, e.g., WebGL, I will have insightful comments and perhaps even thought-provoking questions, but if they present on something I know very little about, e.g., computer vision on the GPU, I have much less interesting things to say, but I still try to absorb as much as I can by asking questions that are probably obvious to them.

Based on student feedback, their presentations were great for experience, but not necessarily for learning new material. There are, of course, exceptions like Varun's Larrabee presentation; he probably covered the material better than I would have.

9. Recruit and empower a killer teaching assistant.

Rendering Massive Game Worlds on a WebGL
Based Browser - Krishnan Ramachandran

I had the pleasure of working with Jon McCaffrey, a bright masters student who is (by the time you read this) now at NVIDIA writing OpenGL drivers. As an avid OpenGL developer, it makes me feel good to know that people like Jon are writing the drivers I rely on.

I would say something like "let's do an assignment on SSAO" or "let's have the class code a globe with a gloss and bump map" to Jon, and suddenly his answer key would be coded over night, shortly followed by the assignment writeup. I don't think I would have gotten through the semester without his hard work. It's obvious to me that the TA plays a key role in a course; having a good one makes a world of difference. I owe a big thanks to Joe for recruiting Jon, and encouraging me to teach this course in the first place.

10. Teaching students with diverse backgrounds is hard.

Over the years, GPUs have evolved from fixed-function rasterization pipelines for graphics to fully-programmable massively-parallel processors. As such, this course covers both the graphics and compute side of GPU programming. Therefore, the course attracts computer engineering students who don't know the difference between a pixel and a fragment (well, they do now!) and computer graphics students who ask "Cycle? What's a cycle?" (I think he was joking though).

It is very hard to serve everyone well. This is an area I need to improve. More flexible "choose your own graphics or compute adventure" assignments will help, but ultimately, there needs to be two courses: a rendering course and a programming massively-parallel processors course.

11. Embrace openness.

I like to do things out in the open, so I encouraged my students to do the same. The result is many students open sourced their projects and all students had public project blogs. To be fair, the blogs were required for their projects, another excellent tradition Joe started a few years ago. Many students told me they plan to continue their project and/or blog beyond the class. Great! The more open source software - the better. The more bright people sharing ideas via blogs - the better.

Radio Propagation Modeling via Fourier Optics - Cem Karan

12. Know how to measure your success.

I don't have the official university-given survey results yet, but when asked to rate "knowing what I know now, I still would have taken this course" from 1 to 10 on my in-class survey, the average answer was 9.25. Does this mean I was successful in teaching this course? On one level, perhaps.

But I really judge my success by the success of my students. One student came running into the lab so excited that I thought he won the lottery. Actually, he just received a job offer. He went on to tell me that a big part of his interview success was explaining how he could improve the performance of their cloth simulation by running it on the GPU with CUDA. I'll take that ten to one over an answer on a survey.

When we ended the semester I reminded students of one way to be successful - by immersing yourself with the best and brightest people you can find.

Full disclaimer: These are my own opinions and do not necessarily reflect those of the University of Pennsylvania or the Department of Computer and Information Science. My entire teaching experience is teaching this course once, so you shouldn't consider me an authority or even take me very seriously.

Under the Hood of Virtual Globes

2011-04-04T20:00:00.010-04:00

Update: We have posted a pdf of our slides on our book's website.

We are teaching a half-day course, Under the Hood of Virtual Globes, at COM.Geo this May in Washington D.C. COM.Geo is a conference on computing for geospatial research and applications. Looks like a number of interesting papers were accepted.

We'll post slides from our course when we are finishing making them; in the meantime, here is the course outline.

GPU Course Projects

2011-03-29T21:00:00.003-04:00

This semester I am teaching GPU Programming and Architecture at the University of Pennsylvania. My students have chosen some interesting projects ranging from rendering to simulation to GPU computing and beyond. Here are their blogs:

Modeling and Simulating of a Candle Lifecycle - Matthew Ahn
Fast Pedestrian Recognition on the GPU - Fan Deng
Semi-Lagrangian Fluid Simulation - Kalin Gochev
Centralized GPU Process Handling - Arthur G
Screen Space Fluid Rendering - Terry Kaleas
Fourier Optics - Cem Karan
Rendering of Massive Game Worlds on a WebGL based Web Browser - Krishnan Ramachandran
Depth of Field on Mobile Devices - Han Li and Qing Sun
AMD Radeon HD 69xx and NVIDIA Fermi Benchmarks - Varun Sampath
Efficient Shadow Rendering - Stuart Summerfield
Deferred Shader with Screen Space Classification - Sean Thomas

I'm sure they would love to hear ideas from outsiders so don't be shy!

Our Book Cover

2011-03-09T19:00:00.003-05:00

We are pumped that the cover for our book is ready:

When you work out a book contract, one thing you can negotiate is say on the cover. We did not negotiate for this - thankfully, we didn't need to. Our publisher was nice enough to take our suggested cover pretty much as is. We, of course, can't take credit for the work; I would be quite embarrassed to reveal the original artwork I created. Instead, two of our fellow AGIer's, Fran Kelly and Jason Martin, did a bang up job designing the cover and creating the artwork. Even cooler, they used a product we work on, STK, to create the visuals. Total overkill perhaps, but cool nonetheless.

GLSL Engine Uniforms Revisited

2011-03-04T18:45:00.000-05:00

A few months back, I mentioned my two articles in Game Engine Gems 2. Now that the book is available, I want to revisit a piece of advice in one article, A Framework for GLSL Engine Uniforms.

This article is about implementing a framework for GLSL uniforms that are automatically set by the engine. A shader author simply declares the uniform to use it. Since the engine has a list of names for all engine uniforms, it can identify what engine uniforms a shader uses, and track them accordingly. A shader author is ensured that the engine will update a uniform to the appropriate value before the shader is invoked. In addition to standard stuff like transformation matrices, these uniforms are also used for more engine-specific values, e.g., time, sun position, etc.

At the end of the article I suggest:

If you are up for parsing GLSL code, you could also eliminate the need for
shader authors to declare engine uniforms by carefully searching the shader's
source for them. This task in nontrivial considering preprocessor transformations,
multiline comments, strings, and compiler optimizations that could eliminate
uniforms altogether

Well, I should have thought more about this because you do not need to parse GLSL for uniform names to eliminate the need to declare engine uniforms. Foruntently, it is much easier; since glShaderSource takes an array of strings, just have one string contain the declarations for all the engine uniforms and let the compiler throw out the unused ones.

I've used this approach for a few months now and am quite happy with it. At first, I was not sure about how useful it would be, but I've found it makes copying and pasting code among shaders much easier because I don't have to remember to declare engine uniforms.

Syntax highlighting C# and GLSL source code with LaTeX and the 'Listings' package

2011-02-03T19:04:00.017-05:00

We wanted to syntax highlight the source code listings in our book in order to make them easier to read. Unfortunately, the languages used for most of the listings, C# and GLSL, are not supported out of the box by the LaTeX Listings package. What to do?

Well, C# and GLSL both have roots in the C language, so we started out tagging our code listings as C++ in order to get some minimal highlighting. The results aren't very good with that approach. Keywords that are shared with C++, like float and return, are nicely highlighted, but not so with

GLSL-specific keywords like vec3. And wouldn't it be nice if built-in GLSL functions like sqrt

and cos were highlighted, like they are in NShader?

I should mention before I get too far that I'm far from a LaTeX expert.

What I'm about to describe worked for me, but please let me know if I'm doing something odd.

C# and GLSL language definitions

The Listings LaTeX package makes it fairly easy to define new languages. Several language definitions for C# can be found around the web. Here's ours:

\lstdefinelanguage{CSharp}
{
sensitive=true,
morekeywords=[1]{
abstract, as, base, break, case,
catch, checked, class, const, continue,
default, delegate, do, else, enum,
event, explicit, extern, false,
finally, fixed, for, foreach, goto, if,
implicit, in, interface, internal, is,
lock, namespace, new, null, operator,
out, override, params, private,
protected, public, readonly, ref,
return, sealed, sizeof, stackalloc,
static, struct, switch, this, throw,
true, try, typeof, unchecked, unsafe,
using, virtual, volatile, while, bool,
byte, char, decimal, double, float,
int, lock, object, sbyte, short, string,
uint, ulong, ushort, void},
morecomment=[l]{//},
morecomment=[s]{/*}{*/},
morecomment=[l][keywordstyle4]{\#},
morestring=[b]",
morestring=[b]',
}

Surprisingly, we weren't able to find a language definition for GLSL. It was pretty easy to put one together based on the GLSL spec, though:

\lstdefinelanguage{GLSL}
{
sensitive=true,
morekeywords=[1]{
attribute, const, uniform, varying,
layout, centroid, flat, smooth,
noperspective, break, continue, do,
for, while, switch, case, default, if,
else, in, out, inout, float, int, void,
bool, true, false, invariant, discard,
return, mat2, mat3, mat4, mat2x2, mat2x3,
mat2x4, mat3x2, mat3x3, mat3x4, mat4x2,
mat4x3, mat4x4, vec2, vec3, vec4, ivec2,
ivec3, ivec4, bvec2, bvec3, bvec4, uint,
uvec2, uvec3, uvec4, lowp, mediump, highp,
precision, sampler1D, sampler2D, sampler3D,
samplerCube, sampler1DShadow,
sampler2DShadow, samplerCubeShadow,
sampler1DArray, sampler2DArray,
sampler1DArrayShadow, sampler2DArrayShadow,
isampler1D, isampler2D, isampler3D,
isamplerCube, isampler1DArray,
isampler2DArray, usampler1D, usampler2D,
usampler3D, usamplerCube, usampler1DArray,
usampler2DArray, sampler2DRect,
sampler2DRectShadow, isampler2DRect,
usampler2DRect, samplerBuffer,
isamplerBuffer, usamplerBuffer, sampler2DMS,
isampler2DMS, usampler2DMS,
sampler2DMSArray, isampler2DMSArray,
usampler2DMSArray, struct},
morekeywords=[2]{
radians,degrees,sin,cos,tan,asin,acos,atan,
atan,sinh,cosh,tanh,asinh,acosh,atanh,pow,
exp,log,exp2,log2,sqrt,inversesqrt,abs,sign,
floor,trunc,round,roundEven,ceil,fract,mod,modf,
min,max,clamp,mix,step,smoothstep,isnan,isinf,
floatBitsToInt,floatBitsToUint,intBitsToFloat,
uintBitsToFloat,length,distance,dot,cross,
normalize,faceforward,reflect,refract,
matrixCompMult,outerProduct,transpose,
determinant,inverse,lessThan,lessThanEqual,
greaterThan,greaterThanEqual,equal,notEqual,
any,all,not,textureSize,texture,textureProj,
textureLod,textureOffset,texelFetch,
texelFetchOffset,textureProjOffset,
textureLodOffset,textureProjLod,
textureProjLodOffset,textureGrad,
textureGradOffset,textureProjGrad,
textureProjGradOffset,texture1D,texture1DProj,
texture1DProjLod,texture2D,texture2DProj,
texture2DLod,texture2DProjLod,texture3D,
texture3DProj,texture3DLod,texture3DProjLod,
textureCube,textureCubeLod,shadow1D,shadow2D,
shadow1DProj,shadow2DProj,shadow1DLod,
shadow2DLod,shadow1DProjLod,shadow2DProjLod,
dFdx,dFdy,fwidth,noise1,noise2,noise3,noise4,
EmitVertex,EndPrimitive},
morekeywords=[3]{
gl_VertexID,gl_InstanceID,gl_Position,
gl_PointSize,gl_ClipDistance,gl_PerVertex,
gl_Layer,gl_ClipVertex,gl_FragCoord,
gl_FrontFacing,gl_ClipDistance,gl_FragColor,
gl_FragData,gl_MaxDrawBuffers,gl_FragDepth,
gl_PointCoord,gl_PrimitiveID,
gl_MaxVertexAttribs,gl_MaxVertexUniformComponents,
gl_MaxVaryingFloats,gl_MaxVaryingComponents,
gl_MaxVertexOutputComponents,
gl_MaxGeometryInputComponents,
gl_MaxGeometryOutputComponents,
gl_MaxFragmentInputComponents,
gl_MaxVertexTextureImageUnits,
gl_MaxCombinedTextureImageUnits,
gl_MaxTextureImageUnits,
gl_MaxFragmentUniformComponents,
gl_MaxDrawBuffers,gl_MaxClipDistances,
gl_MaxGeometryTextureImageUnits,
gl_MaxGeometryOutputVertices,
gl_MaxGeometryOutputVertices,
gl_MaxGeometryTotalOutputComponents,
gl_MaxGeometryUniformComponents,
gl_MaxGeometryVaryingComponents,gl_DepthRange},
morecomment=[l]{//},
morecomment=[s]{/*}{*/},
morecomment=[l][keywordstyle4]{\#},
}

GLSL has a ton of keywords, especially since we've included the built-in functions and variables in separate keyword lists so that they can be highlighted separately.

Coloring the source code

Now that the languages are defined, we can specify how they are highlighted. The color scheme presented here is loosely based on Visual Studio and NShader:

\lstset{
backgroundcolor=\color[rgb]{0.95, 0.95, 0.95},
tabsize=2,
rulecolor=,
basicstyle=\scriptsize,
upquote=true,
aboveskip={1.5\baselineskip},
columns=fixed,
showstringspaces=false,
extendedchars=true,
breaklines=true,
prebreak = \raisebox{0ex}[0ex][0ex]{\ensuremath{\hookleftarrow}},
frame=single,
showtabs=false,
showspaces=false,
showstringspaces=false,
identifierstyle=\ttfamily,
keywordstyle=\color[rgb]{1.0,0,0},
keywordstyle=[1]\color[rgb]{0,0,0.75},
keywordstyle=[2]\color[rgb]{0.5,0.0,0.0},
keywordstyle=[3]\color[rgb]{0.127,0.427,0.514},
keywordstyle=[4]\color[rgb]{0.4,0.4,0.4},
commentstyle=\color[rgb]{0.133,0.545,0.133},
stringstyle=\color[rgb]{0.639,0.082,0.082},
}

I was surprised to learn that the Listings package does not allow styles be defined per language; a single style is applied to all languages. This is not as limiting as it at first appears, however, because we can define multiple groups of keywords and specify a style for each group individually.

With the languages and style defined, we can write LaTeX code like this:

\begin{lstlisting}[language=GLSL]
// Vertex shader
in vec4 position;
uniform mat4 og_modelViewPerspectiveMatrix;

void main()
{
gl_Position = og_modelViewPerspectiveMatrix * position;
}

// Fragment shader
out vec3 fragmentColor;
void main() { fragmentColor = vec3(0.0, 0.0, 0.0); }
\end{lstlisting}

To generate a nice listing like this:

Highlighting type names

You may have noticed that the Visual Studio editor highlights the names of classes, structs, interfaces, and enums. How can we do that with LaTeX? LaTeX, of course, has no idea which identifiers in our source listings are class names and which are the names of variables, methods, etc., so we have to tell it. We can do that by specifying, for each listing, the identifiers that belong to a keyword group:

\begin{lstlisting}[language=CSharp,classoffset=2,morekeywords={GL,EnableCap}]
GL.Enable(EnableCap.DepthTest);
// ... Set other states
Render();
\end{lstlisting}

Which produces the following:

Notice that GL and EnableCap are highlighted because they have been explicitly listed, using classoffset and morekeywords, as belonging to keyword group 3 - an offset of 2 from the base.

Limitations

The Listings package has a couple of limitations that we were unable to work around:

Highlighting is entirely keyword based and cannot take context into account. It's fairly common in C# to have a single identifier that is a class name in one context and a property name in another context. If both usages of the identifier occur in a single listing, there does not appear to be any way to highlight the identifier only where it refers to a class name. Either it's highlighted everywhere, or nowhere. Update 2011/05/27: I found a way to do this after all. See below.
The Listings package allows us to specify a keyword prefix so that all keywords starting with a character sequence are highlighted. Unfortunately, only a single prefix can be specified. It would have been helpful to highlight all identifiers in GLSL listings that start with gl or og.
There does not appear to be a way to highlight numeric literals (such as 1.23) or operators (such as ==).

If you know a solution to any of these problems, please let me know!

Update 2011/05/27

I wrote above that I was unable to find a way to highlight some occurrences of an identifier but not others within a single listing. It turns out there is a way after all. The trick is to insert a do-nothing "escape to LaTeX" somewhere in the middle of the occurrence of the identifier that you don't want highlighted.

First, define an escapechar. It can be any character you want, so long as the character will not otherwise occur in your listings. Here I've used backtick (`) as my escapechar:

\lstset{
...
escapechar=`,
...
}

Then write your listing like this:

\begin{lstlisting}[language=CSharp, caption={RenderState Properties.},classoffset=2,morekeywords={RenderState,PrimitiveRestart,FacetCulling,RasterizationMode,ScissorTest,StencilTest,DepthTest,DepthRange,Blending,ColorMask}]
public class RenderState
{
public PrimitiveRestart P``rimitiveRestart { get; set; }
public FacetCulling F``acetCulling { get; set; }
public RasterizationMode R``asterizationMode { get; set; }
public ScissorTest S``cissorTest { get; set; }
public StencilTest S``tencilTest { get; set; }
public DepthTest D``epthTest { get; set; }
public DepthRange D``epthRange { get; set; }
public Blending B``lending { get; set; }
public ColorMask C``olorMask { get; set; }
public bool DepthMask { get; set; }
}
\end{lstlisting}

Notice the double backticks (``) in the names of the properties. The first backtick escapes to LaTeX mode, and the second returns to listing mode. You could include LaTeX commands between the backticks, but there's no need; the interruption alone is enough to cause the identifier to not be highlighted. LaTeX will render the listing above like this:

Manuscript Submitted

2011-01-02T14:00:00.000-05:00

Kevin and I submitted our manuscript today. Writing this book was even harder than I thought. It was particularly time consuming because of the amount of code we also wrote. It was great fun though, and all the reviewers kept us engaged.

We'd like to post some samples in the next month or two. Check out the

Table of contents [pdf]

and let us know what we should post by leaving a comment or emailing us:

authors@virtualglobebook.com

Also, those readers subscribed to our blog may have noticed a draft of this post in your reader a week ago. Sorry, I scheduled the post for 2010 instead of 2011!

Book Title and OpenGlobe Update

2010-12-20T20:00:00.007-05:00

Previously, I mentioned we were working on finalizing our book's title. Now it's finalized:

3D Engine Design for Virtual Globes

I think the "3D Engine Design" branding will help get the book more attention by developers who might not initially think they are interested in virtual globes. Many book's have nicknames, so we're calling ours the Virtual Globe Book for short. Let's see if it sticks.

This blog still remains as Virtual Globe and Terrain Rendering. Since it is about more than just our book (or at least it will be), it doesn't need to stay in sync with the book's title. The url will not change either.

In other news, all of our example code now runs on Linux. After our first port, two examples needed more work.

Finally, we changed the license for the example code from the boost license to the MIT license, mainly because the MIT license is more popular. All we care about is that readers, and random people that stumble upon our code, can use it unrestricted, including in commercial applications.

Math Foundations

2010-12-18T11:00:00.000-05:00

We haven't been writing chapters in the order they will appear in our book. The most recent chapter, Math Foundations, is no exception. It will be Chapter 2, but is basically the last chapter I am writing. After this, I only have to finish the introduction and smooth out a few other sections. Kevin has a similar amount of work left, so we are on schedule!

This chapter is not on math foundations for general 3D graphics; rather, it is on useful mathematics for virtual globes, with a focus on ellipsoids. This chapter is unique in that it contains some derivations, but we are computer science practitioners, not mathematicians, so it also provides working code in a handy Ellipsoid class. Our colleague, Jim Woodburn, helped significantly with the derivations.

This chapter covers:

Geographic (longitude, latitude, height) and WGS84 (x, y, z) coordinates.
Ellipsoids

Oblate spheroids (Earth's shape).
Surface normals: geodetic vs. geocentric.
Conversion between geographic and WGS84 coordinates.
Scaling a arbitrary point in space to the ellipsoid surface.
Curves on ellipsoids.

I also wrote two related examples applications, one demonstrating geodetic and geocentric surface normals, and another for computing curves on an ellipsoid by slicing a plane through it. Here's a video of the later:

A Tip for Finishing Chapters

2010-11-29T19:00:00.075-05:00

It's always fun to start writing a chapter, especially if it is on a particularly interesting topic. Finishing the chapter can be a bit harder - sounds like a software project, right?

Finishing involves lots of details: rewording, double checking equations, actually doing TODOs (or sometimes just removing them), etc. After reading and writing so much about a topic, I want to move on to the next chapter - but I can't, not until I finish what I started.

A tip that helps me finish a chapter is I tell people when I'm going to finish it. In particular, I email potential reviewers asking them if they are interested in reviewing it, and telling them when I expect to be done. I have to finish it now; I can't ask these kind people to do me a favor, and not follow through.

This tip doesn't work magic, but it helps keep me on track. I can't expect to write 30 pages overnight just because I told someone I would. But if I'm 2/3 through a chapter, I can predict how long it will take to finish at a reasonable pace, and tell reviewers to help ensure I keep that pace.

OpenGlobe on Linux

2010-11-24T17:00:00.075-05:00

We develop the example code for our book using Windows, but we realize not all readers use Windows. The good news for them is, over the past few days, we got the vast majority of our code to build and run on Linux using Mono. Here's a screen shot of one example from the globe rendering chapter:

We tested using Ubuntu 10.04, which comes prepackaged with MonoDevelop 2.2 and Mono 2.4.4. Our code builds cleanly with no warnings, and, thankfully, all of our unit tests pass:

(Yes, we actually write unit tests for the book code.) We need to investigate our examples that use a third party Shapefile reader a bit more, but we may wind up writing our own Shapefile reader when the manuscript is done.

I have to say that I am quite impressed with Mono, MonoDevelop, OpenTK, and NVIDIA's Linux drivers. Porting to Linux was even easier than I hoped.

We also plan to test on Mac when Apple releases OpenGL 3.3 drivers.

Vertex Transform Precision

2010-11-21T14:00:00.001-05:00

I just finished writing a chapter on a rendering artifact that many people don't even know exists until they try to use massive world coordinates, and suddenly objects start to bounce or jitter as shown in this video:

Eliminating jitter is important for high precision rendering in virtual globes, and in massive-world games, like flight simulators. When world coordinates are large, yet users can zoom in very close to objects, floating point round-off errors manifest themselves as jitter.

This chapter is on techniques for eliminating jitter. Major topics include:

Why exactly jitter artifacts occur.
Eliminating jitter by rendering relative to center, i.e., using a floating origin [code].
Rendering relative to eye.

A slow CPU implementation that I only recommend for certain cases [code].
A fast GPU implementation we use in Insight3D [code], an even more precise GPU implementation [code], and a technique I've called Precision LOD [code].

Lots of details on the trade-offs between approaches.

If you love (or hate) jitter like I do, also read our coworker's article, which served as the primary reference for this chapter. Also see the DSFUN90 Fortran library, which contains routines for performing double-single arithmetic, i.e., emulating doubles in software.

A K Peters Catalog, Amazon, and More

2010-11-16T18:00:00.061-05:00

I just received a hard copy of A K Peter's 2010-2011 catalog in the mail. Exciting. What's even more exciting is our book is listed - with an ISBN and all!

To add to the excitement, I just found our book on Amazon. It is also on the CRC Press website. (A K Peters is now part of CRC Press.)

If you visit the Amazon or CRC Press page, you may wonder why the title is 3D Engine Design for Virtual Globes, not Virtual Globe and Terrain Rendering, which is listed in A K Peter's catalog and our blog. They are actually the same book (check the ISBN).

In the original book proposal, I suggested the title 3D Engine Design for Virtual Globes. After a few months of writing, I suggested a title change to Virtual Globe and Terrain Rendering since there is more content on rendering algorithms than engine design, and I wanted to stress our coverage of terrain. The title still isn't final though. Once we firm it up, we'll let everyone know. Of course, the content remains unchanged.

I also wanted to supplement the description of our book in the AK Peter's catalog. I am listed as the only author, but I assure you, Kevin is the coauthor. The catalog must have went to press before Kevin came on board. Our book is listed as approximately 350 pages. We actually already surpassed that, and Kevin and I will still be writing furiously for another six weeks. The page count could climb as high as 450 in our draft, but once it goes through copyediting, layout, etc., I can see it becoming shorter as figures are organized, fonts are selected, etc.

Finally, we plan on posting some sample content in February or March, after the manuscript goes through copyediting. In the meantime, we'll continue writing posts on chapters as we finish them.

Twitter

2010-11-02T22:00:00.022-04:00

Short version: I'm on twitter now: pjcozzi.

Longer version:

I remember when I first learned what a blog was back in 2000. I was an intern at Intel, and stumbled across Joel's now famous blog. The first post I read was The Guerrilla Guide to Interviewing. After that I was hooked, and followed Joel almost religiously until 2006 or so. I kept following after that, but not as frequently (maybe grad school had something to do with it). At the start of 2008, AGI launched a blog for Insight3D, and I wrote my first blog post. I also started reading dozens of graphics blogs, many of which are in our blogroll.

Since then, I've gotten use to the idea of writing blogs to share technical ideas or products news, so it was natural to launch this blog for our book. During all this blogging, I somehow managed to ignore twitter. Clearly, I was missing out, so I'm on twitter now: pjcozzi. All I need to do now is make a LinkedIn page and I'll be completely connected! Maybe once the manuscript is done...

Renderer Design

2010-10-31T12:00:00.003-04:00

With about two months left to complete the manuscript, Kevin and I are in overdrive. I suppose it helps that I wrote the example code for the latest chapter almost a year ago, so writing the chapter was just writing, selecting code snippets, and creating figures - in theory anyway. Since this chapter is code-heavy, I went back and fine-tuned a lot of code.

This chapter is on renderer design, that is, designing the layer of a 3D engine that sits between the underlying rendering API, like OpenGL or Direct3D, and the rest of the engine. Since my experience is largely with OpenGL, the chapter focuses on OpenGL, but it still mentions Direct3D in many places for comparison. Although I'd love to fill an entire book on the topic (hmm), the chapter is only 70 pages, so it requires some previous experience with OpenGL or Direct3D, as does our book in general.

As I said a while back, this is the third time I've designed such an abstraction layer, so much of my advice is battle tested. I've learned to favorite ease of use and flexibility over performance, although I mention where performance can be improved, perhaps only marginally in the grand scheme of things, at the cost of something else.

The major components of our renderer are shown here:

The highlights of this chapter include:

Motivation for a renderer layer: ease of development, portability, flexibility, robustness, performance, additional functionality. I can't come up with a reason not to do it except for "hack something together as fast as possible."
Big picture: the device [code] and contexts [code].
State management: global render state vs. state objects [code], draw state [code], clear state [code], sorting by state.
Shaders: compiling and linking [code], built-in constants [code], vertex attributes [code], uniforms [code], automatic uniforms [code], and shader caching [code].
Vertex data: vertex buffers [code], index buffers [code], vertex arrays [code], meshes [code], creating vertex arrays from meshes [code].
Textures: read and write pixel buffers [code], 2D textures [code], samplers [code], texture units [code].
Framebuffers [code].

Game Engine Gems, Volume 2

2010-10-24T10:00:00.072-04:00

I'm excited that the table of contents for Game Engine Gems, Volume 2 is now available. The book is scheduled to be released at GDC 2011, this coming March.

Although I don't know anything beyond the titles and authors, I am looking forward to many of the articles.

Rémi Arnaud's 3D in a Web Browser sound timely and is always a hot topic where I work. Recently, I've played with JOGL Java Applets, but I'd also like to look at WebGL. I'm curious to read what Rémi has to say.

Noel Llopis's High-Performance Programming with Data-Oriented Design also sounds worthwhile. I feel my design skills have plateaued over the past year or two; I couldn't even give you a completely legit definition of "Data-Oriented Design." Some reading in this area will be good for me.

I'm happy to see that the Systems Programming part has a good bit of threading coverage, including Julien Hamaide's Thread Communication Techniques, Martin Fleisz's A Cross-Platform Multithreading Framework, and Matthew Johnson's Producer-Consumer Queues. I can't imagine that anyone is writing a new engine without at least some multithreading support. I'm curious to read about communication between threads. I have to admit to being a big fan of message queues but I'm sure they are not the be all end all. (P.S. Our book also has a chapter on multithreading.)

Finally, I contributed two articles on OpenGL techniques. Here are their abstracts:

Delaying OpenGL Calls

It is a well known best practice to write an abstraction layer over a rendering API such as OpenGL. Doing so has numerous benefits that include improving portability, flexibility, performance, and above all, ease of development. Given OpenGL’ s use of global state and selectors, it can be difficult to implement clean abstractions for things like shader uniforms and frame buffer objects. This chapter presents a flexible and efficient technique for implementing OpenGL abstractions using a mechanism that delays OpenGL calls until they are finally needed at draw time.

A Framework for GLSL Engine Uniforms

The OpenGL 3.x and 4.x core profiles present a clean, shader-centric API. Many veteran developers are pleased to say goodbye to the fixed function pipeline and the related API entry points. The core profile also says goodbye to the vast majority of GLSL built-in uniforms, such as gl_ModelViewMatrix and gl_ProjectionMatrix. This chapter addresses the obvious question: what to use in place of GLSL built-in uniforms.

I'll write an actual review when the book comes out (excluding my articles, of course, and with the disclaimer that, as a contributor, I am biased) and I am going to finishing reading and reviewing GPU Pro 2 as soon as I am done writing the manuscript for my own book!

Welcome Kevin

2010-10-12T23:00:00.002-04:00

My coworker, Kevin Ring, has joined me as a coauthor to write a few of the final, but core, chapters. Kevin has served as a reviewer for many of the chapters I already wrote, has contributed quite a bit to the book's example code (including the message queue and administering the continuous integration server). He even contributed some book content to the section on implementing a message queue. At this point, he is practically a coauthor anyway.

He will be writing about terrain LOD and imagery tiling, while I finish up chapters on renderer design and precision. We have plenty to do by the end of the year but I think we are in good shape, and I am not one to wait until the last minute to panic.

Writing Captions for Figures

2010-09-21T20:00:00.004-04:00

Before reading a book or paper, I always browse its figures and read their captions. If it seems the content will interest me, I go back and actually read it. I suspect almost everyone does this.

Jim Kajiya makes an excellent point about this in How to Get Your SIGGRAPH Paper Rejected, which I believe applies equally to books:

Ivan Sutherland once told me that Scientific American articles are constructed so that you can get the point of the article just by reading the captions to the illustrations. Now, I'm not suggesting that you write a technical comic book; but you should take a look at those SIGGRAPH papers you were initially attracted to and see how they went about getting their point across.

Given that a reader is likely to read captions for figures before reading the main text, it is important to write good captions! A trick I use is to write the captions before writing the main text. This has worked pretty well so far. You need to be careful that you don't include too much in the caption but a little redundancy isn't bad: I like captions to reiterate a key point from the main text.

Multithreaded Resource Preparation

2010-09-12T20:00:00.008-04:00

I gave myself three weeks to write our chapter on multithreaded resource preparation. I manged to come in right on time even with Labor Day weekend in the mix. I am exhausted.

This is not an introduction to multithreading but rather how to apply multithreading to improve the performance and responsiveness of a 3D engine by moving I/O, CPU intensive algorithms (think triangulation, vertex cache optimization, etc), and renderer resource creation to worker threads.

The chapter highlights include:

Brief review of hardware parallelism

CPU: Pipelining, superscalar, SIMD, multithreading, Hyper-Threading, multi-core.
GPU: Pipelining, shaders, CPU/GPU parallelism.

Architectures for multithreaded resource preparation

Using message queues to communicate between threads [code contributed by Kevin Ring].
Coarse grain threads [code].
Pipeline of fine grain threads.

Multithreading with OpenGL

One GL thread, multiple worker threads.
Multiple threads, one context.
Multiple threads, multiple contexts.

Shared contexts.
CPU vs GL synchronization. Fences [code].

Also, here's a list of resources on OpenGL multithreading that I found useful:

Appendix D of the OpenGL spec is on shared objects and multiple contexts.
Multithread texture loading using OpenGL and WGL
The Hacks of Life blog posts:
opengl.org forum posts:
- Threads rendering to different contexts
- Specific Multi Threading usage in OpenGL
- OpenGL thread loading
- multithreaded OpenGL WTF? - on threading in the driver, not application level threading.
- glFlush or glFinish with mulithreading?
- Compiling/linking shaders on a thread on NVIDIA
GameDev.Net forums posts
- Multithreading and OpenGL contexts
- VBO and Multithreading
Direct3D 11 Multithreading - not OpenGL but still nice to know.

Proofreading your own Writing

2010-09-01T19:00:00.002-04:00

Proofreading our own writing is hard because, well, we wrote it. We tend to read what we think we wrote and not what we actually wrote.

When I first write something, it usually isn't that great. That doesn't worry me, I want to get ideas down and avoid staring at a blank screen. I write a few pages, create a pdf, proofread it, and immediately rewrite the parts I don't like or that have blatant grammar errors.

This type of proofreading isn't enough though.

The next day I work on the book, I reread what I wrote the previous day, hopefully after forgetting most of it. I'm able to improve the quality to the point where I'm not ashamed, or perhaps even proud, to show it to reviewers.

This second proofreading also helps me get back into the zone for writing the next section and helps each section flow into the next one. I find getting into the zone for writing much hard than getting into the zone for coding so I feel this trick goes a long way.

I always proofread my previous day's work before writing. Sometimes, I even proofread previous work from a few days. By the time I "finish" a chapter, I've probably read it five times - and reviewers still find things!

Rendering Vector Data

2010-08-22T14:15:00.005-04:00

I just finished writing our chapter on rendering vector data on a globe. Leave it to me to write 60 pages on something as simple as rendering polylines, polygons, and points! Of course, it is not quite as simple as it sounds. I'd like to share an overview of the content and screen shots of the example code, which you can download now: Chapter07VectorData in OpenGlobe.


Country polygons, state and river polylines, and city points (billboards)	Country polygons and river polylines

This chapter begins with two short sections on sources of vector data and on avoiding z-fighting between vector data and the globe it is drawn on. The bulk of the chapter is then in these three sections:

Polylines

Layouts: strips, loops, and indexed lines.
Batching and static vertex buffers.
Rendering wide lines using a geometry shader [code].
Shaders for rendering outlined (two color) lines [code].

Polygons

Overview of raster techniques for polygon rendering.
A pipeline for geometry-based polygon rendering, including:

Triangulation: ear clipping [code], including a nifty way to ear clip polygons on an ellipsoid without projecting to a tangent plane [code].
Subdivision to make a polygon's triangulation better approximate the ellipsoid [code].

Billboards

Rendering billboards with a geometry shader [code].
Using and packing texture atlases [code].
Text rendering.

The example code also includes a partial ESRI Shapefile reader. The vector, raster, and icon data used is included in the example and can be downloaded from our data page.

Of course, the chapter contains much more than the above bullets but these are the highlights. Now, I'm off to write the chapter on moving much of this work (disk/network access, triangulation, texture atlas packing, GL resource creation) off the main thread. Since most the code for this is already done, I'm hoping this is a pretty easy chapter to write.

SIGGRAPH Notes

2010-08-02T20:00:00.181-04:00

I'd like to share some of my notes from SIGGRAPH. I promise this will be my last SIGGRAPH post, then I will return to directly book-related things.

Courses: Morgan McGuire organized an excellent course: Stylized Rendering in Games. There was lots of talk on rendering silhouettes, where, like a lot of things, "the devil is in the details." I liked how the Borderlands talk went into almost painful detail on using a Sobel filter for silhouette rendering. BTW, a Sobel filter is also useful for computing terrain normals.

Beyond Programmable Shading was a hit as always. I go to this course ever year and it always has new content. In particular, Jonathan Ragan-Kelley gave a great talk on scheduling the graphics pipeline. It's rare to find good information on this kind of stuff. The course ended with a panel on programmable vs fixed function hardware. For me, the takeaway was fixed function hardware is fast and uses very little power so it will remain for algorithms that are unlikely to change (e.g. video decode, rasterization, etc.). My opinion from a developer's perspective is: fixed function is fine for things I have no interest in changing but I want everything else to be programmable.

Panels: There was a really unique panel called "CS 292: The Lost Lecture." In which, Richard Chuang, co-founder of PDI, and Ed Catmull, president of Pixar and Disney Animation Studios, reflected on a graphics course Ed Catmull and Jim Blinn taught at Berkley in 1980, which Richard Chuang attended. The panel included video clips from the course and several memoriable quotes (disclaimer: I tried to write these down word for word but no promises):
- "It's the kind of thing where you understand it and it is still hard." - Ed Catmull on visible surfaces in 1980.
- "It would be nice if this thing could do a little more. In fact, it would be good if it were programmable." - Ed Catmull on the GPU in 1980.
- "Because we didn't know any better, we were on the forefront of a brand new field." - Richard Chuang.
- "The result of teaching these two classes created our biggest competitor" - Ed Catmull speaking about PDI/Dreamworks.
- "If we don't have any major surprises then we are becoming too conservative." - Ed Catmull.
When asked during the panel, Ed Catmull did not object to having the videos of his 1980 course released. It would be great to have such historic videos available.

Books: One of my favorite things about SIGGRAPH is all the new books. I'm happy to see the fifth edition of the OpenGL SuperBible is out, and it only covers the core profile! It's about time we got a book covering just "modern" OpenGL. Another book that looks interesting is Writing for Computer Science. Its been out since 2004 so I'm surprised that I haven't ran into it before. I probably should have read it before starting on my own book!

Posters: Stefan Elsen had an interesting poster on real-time procedural generation of planets using fractals: "WorldSeed: Fractal Worlds in Realtime." His website has much more information including an impressive video. Our poster, GPU Ray Casting of Virtual Globes, was also well received. I actually ran out of hard copies of the abstract!

OpenGL: Those notes are in my previous post.

There was a whole lot more to see at SIGGRAPH but these were the highlights for me. Now that all the SIGGRAPH fun is behind us, I need to lock myself in my house and finish this manuscript!

OpenGL 4.1 and more at SIGGRAPH

2010-07-31T15:00:00.108-04:00

After attending SIGGRAPH, I am convinced now, more than ever, is a great time to be using OpenGL. There was lots of exciting news:

The OpenGL 4.1 and GLSL 4.1 specs were released, very shortly followed by NVIDIA drivers. This includes long requested features such as ARB_separate_shader_objects and ARB_get_program_binary. I was pleasantly surprised to see the extra debugging information now available with ARB_debug_output. This will be the first thing I try out.
Of particular interest to virtual globe developers is ARB_vertex_attrib_64bit which will help the common "jitter" problem on machines with GL 4.x hardware. Dealing with this problem on pre-4.x hardware is a topic in our book. Until it comes out, check out Deron's Precisions, Precisions article.
The OpenGL SDK reference pages were updated for 3.3 and 4.1 core profiles! You no longer have to dig through the spec to find reference material for the latest GL features (not that it was that bad). The 2.1 reference pages are still around if you need to look up deprecated functions.

If you didn't get to attend the OpenGL BOF (or even if you did), I recommend reading through the slides. There's lots of exciting news, including a lightweight texture file format, KTX, for OpenGL and OpenGL ES, a 0.9 version of a modern GLU: GLU3, and progress towards OpenGL conformance tests.
As lame as it sounds, I am pumped about the conformance tests. They should really improve the quality of OpenGL drivers, which have already been increasingly stable on recent hardware and operating systems.

NVIDIA's OpenGL 4.0 for 2010 presentation is also worth a look. I was glad to see how crowded this session and the BOF were!

Even though I am thrilled with the direction of OpenGL, there are two things I'd like to see:

3.4 - I was expecting to see 3.4 released at the same time as 4.1 but instead 3.x gained new ARB extensions, including the ones listed above minus ARB_vertex_attrib_64bit. Since not all vendors support all ARB extensions, I would have rather seen these great features rolled into 3.4. This way the features are guaranteed to be implemented, and application developers can simply say their application requires 3.4 instead of saying 3.4 plus whatever extensions. I would not mind seeing 3.4 released with 4.2 (or 5.0?) and include all possible extensions from 4.1 and 4.2.

I'd also like to see debugging support for modern GLSL shaders. If OpenGL really wants to be a Direct3D superset, it needs better tool support. Right now, there is glslDevil but it does not support core profile development. There is also NVIDIA's Parallel Nsight (see their SIGGRAPH presentation), which currently has very little OpenGL support and the support requires the paid version. Although, I am under the impression that NVIDIA is working on more OpenGL and GLSL features. They will hit a home run if we can seamlessly debug GLSL shaders!

Geometry Shader Silhouettes without Adjacency Information

2010-07-19T07:00:00.026-04:00

Rendering silhouette edges is a classic problem in NPR. It has other uses to - for example, in terrain rendering, it can convey quite a bit about where ridge lines are:

Of course, the above comparison is not very fair. The image on the left is just shaded by height (no lighting) which can hide terrain features, especially for horizon views. Regardless, silhouettes are cool and most graphics developers are familiar with the standard geometry shader approach based on adjacency information (if not see Inking the Cube: Edge Detection with Direct3D 10 or Single Pass GPU Stylized Edges). What I'd like to briefly share with you is a geometry shader approach that does not require adjacency info, which means you won't need one index buffer with adjacency info and another without it!

I should mention that Deron came up with this and I am sharing it so he can keep busy on the book! The idea is simple - use the geometry shader to do a procedural geometry technique called triangle fattening (see Image Precision Silhouette Edges) in screen space. In the first pass, the model is rendered normally with backface culling. In the second pass, it is rendered with front face culling and a geometry shader that transforms the triangle to screen space and expands each edge by a given number of pixels. To eliminate elongated corners, the three input vertices are turned into six as shown here:

The original triangle is gray and the expanded "triangle" is black. The result is a uniform width silhouette. This method is similar to a fixed function algorithm, which renders the second pass in wireframe mode using a wide line. But in OpenGL 3, line widths greater than one were deprecated.

In our method, the geometry shader outputs six vertices for all backfacing triangles. Most of those fragments should get thrown away by early z since the front facing triangles were laid down in the first pass. The geometry shader could output more vertices to reduce the rasterization load but we found this to slow things down quite a bit. Performance is commonly bound by geometry shader output and this algorithm will output a lot more triangles than the standard geometry shader algorithm that only outputs triangles for edges on the silhouette. We think this algorithm is still worth mentioning since it is so easy to integrate into a rendering pipeline, especially if you have the shader source. Here: SilhouetteGS.glsl.

OpenGL at SIGGRAPH 2010 Update

2010-07-13T14:30:00.008-04:00

The OpenGL Community Drink at SIGGRAPH has now been scheduled:

Monday, July 26th, 6pm
Veranda Bar in the Figueroa Hotel

The Figueroa Hotel is one of the closest hotels to the convention center. See the Hotel Map. There is no need to RSVP but you are welcome to chime in here, email Christophe, leave a comment below, or just show up, we're not exactly going for anything formal.

OpenGL at SIGGRAPH 2010

2010-07-09T16:30:00.027-04:00

One of the many reasons I love SIGGRAPH is it allows me to stay current with the now quickly moving world of OpenGL. This year there are many sessions covering OpenGL:

OpenGL BOF: Always has the latest OpenGL news. It might even be the most attended BOF at the conference - the free beer doesn't hurt. It is on Wednesday, 5:15-7:15pm
OpenGL 4.0 for 2010: Hosted by NVIDIA on Wednesday, 10:15-11:30 am.
OpenGL Community Drink: Currently being organized by Christophe Riccio (creator of GLM and the OpenGL Samples Pack). This will be a great opportunity to meet people that are active on the opengl.org forums or just using OpenGL in general. The time and place have not been set yet but it is likely to be Monday night. Join the planning discussion here. This is an informal meeting and not an official SIGGRAPH event.

GPU Ray Casting of Virtual Globes at SIGGRAPH 2010

2010-07-01T17:04:00.000-04:00

SIGGRAPH is just around the corner! I am excited to present our poster: GPU Ray Casting of Virtual Globes. The papers and presentations page contains the abstract, video, and all that good stuff.

The poster sessions are Tuesday and Wednesday, 12:15-1:15pm. If you are interested in GPU ray casting, rendering ellipsoids, or anything related, stop by our poster at location 80B in the West Lobby.

GPU Pro Review - 3D Engine Design Section

2010-06-30T10:30:00.000-04:00

I recently started reading GPU Pro and it is outstanding! I love the full color and syntax highlighting! Many of the articles are even useful research for our own book. I'd like to write a full review but who knows when I'll get through the 700+ pages. So I'm going to write a review as I read each section. These reviews will be more about the ideas the articles give me than a complete review of the contents, writing style, etc. But isn't that the point of reading anyway - to get new ideas?

The 3D Engine Design section was the first section that peeked my interest. Of which, I read two of the four articles:

Porting Code between Direct3D 9 and OpenGL 2.0 - Wojciech Sterna

A chapter in our book is on designing an abstraction layer over OpenGL so the rest of the book can contain API agnostic discussion and code examples (with the exception of the use of GLSL for shaders). This isn't just important for book writing, all major graphics applications should have a renderer abstraction layer for flexibility, portability, performance, and most importantly, ease of development.

If you count a graduate class project, this is third time I've designed such a layer (check it out on sourceforge). Every time, I've done so with OpenGL so I was excited to see this article on the differences between Direct3D and OpenGL. While designing the layer, I looked at the Direct3D documentation from time to time but I am not positive that it is ideal for both APIs so I looked forward to learning more from this article.

And I did learn quite a bit. Perhaps I should be embarrassed to say, but I didn't know anything about the fine grain control available in Direct3D with memory pools. I also felt good learning that many things like vertex buffers and textures seem very similar between the two APIs.

I liked the mention of Cg - since I was recently asked why not use Cg instead of duplicating shaders in GLSL and HLSL. Although it sounds like two slightly different Cg shaders would need to be written anyway. If anyone has experience with maintaining shaders for different APIs, I'd like to hear about it.

Overall, this article was pretty good and I like that it was only 11 pages and right to the point. If I had to criticize it, I would have liked it to be about Direct3D 10/11 and OpenGL 3.2 core profile. But I understand that Direct3D 9 is still widely used and OpenGL 3.2 might not of even been out when this article was written. It would have also been nice to see more tips on designing an abstraction layer that allows for reasonable implementations using both APIs instead of just the API differences - although, the example code more than makes up for this.

Practical Thread Rendering for DirectX 9 - David Pangerl

This article also jumped out at me since I am preparing to write the threading material for our book. My focus is on using threads for out-of-core rendering: reading data from secondary storage, CPU intensive processing of that data (.e.g, computing normals, etc), then finally creating renderer resources (e.g., vertex buffers, textures, etc) - assuming I get all the example code working!

This short article is on another use of threading: using a dedicated thread for issuing rendering commands. The basic idea is to fill a command buffer instead of directly issuing Direct3D calls (I'm pretty sure this would also work with OpenGL). A dedicated rendering thread then executes the command buffer. Filling the command buffer is much faster than calling Direct3D functions, which reduces the CPU usage of your main thread. An interesting statistic from the article is the author found an average Direct3D function call takes 15,231 instructions. Using the dedicated rendering thread, the author saw improvements up to 200% in tests, and a 15% in a real-time game. Considering all that is going on in a game, 15% is great!

One thing I'm curious about is what happens when uploading large objects like vertex buffers and textures? Its not clear to me if a copy of the data is made for the rendering thread or if this falls into their category of commands that synchronize with the rendering thread and execute immediately. I'm also curious about operations like compiling and linking shaders which may be threaded by the driver anyway. I suppose this can happen offline in Direct3D.

It's worth mentioning that if you have an abstraction layer over your rendering API (and you should!), this could all be done behind the scenes with the user having no idea that there is a dedicated rendering thread.

In closing, I think this is a worthwhile idea that I'd like to implement myself at some point. Also, I'm not sure how this compares to multithreaded rendering in Direct3D 11.

Now onto the Game Postmortems section!

Welcome

2010-06-26T08:51:00.001-04:00

Welcome to our graphics blog! This will be a journal of sorts for our upcoming book tentatively titled Virtual Globe and Terrain Rendering to be published by AK Peters, Ltd. in time for SIGGRAPH 2011. We'll talk about our experiences preparing the manuscript and the heaps of example code (which you can download as we work on it, before the book is available!). The about page has more information on our book, including the planned contents.

Even if you don't think you're interested in our book project, our blog should be useful for real-time computer graphics in general. Many of the techniques used for virtual globe rendering are applicable in all sorts of places - GIS, games, simulations, etc. We anticipate at least as much general graphics content as we do book-related content.

Stay tuned!