Category Archives: Miscellaneous

Bokode – clever!

Not directly relevant to real-time rendering (although there might be some tangentially related applications in areas like augmented reality), this SIGGRAPH 2009 paper is just painfully clever. It exploits the phenomenon of bokeh (the large circular blobs that small intense light sources generate in out-of-focus images) to create tiny barcodes that can be seen from a distance by cameras. They put a lenslet over the barcode, so that when viewed in a defocused manner you see a large circular blob – with a sharp image of the barcode in the center!

7 Things for July 26th

Books, books, and more books: I received review copies of two books. Best of Game Programming Gems is as it sounds, certainly cheaper than buying the seven books in this series, no real review needed (look inside). Game Engine Architecture is about just that, how to make a professional-grade game rendering system, from soup to nuts (you can look inside). Eberly’s two books are the previous notable works in this area, but are quite different than this new volume. While they focus almost exclusively on algorithms, this book attempts to cover the whole task of developing an engine: what to use for source control, dealing with memory management and in-game profiling, input devices, SIMD, and many other practical topics. There is also algorithmic coverage of rendering, animation, collision detection and physics, among other areas. Naturally, the amount of information on each area is limited by page count (the book’s a solid 860 pages), but in my brief skim it looks like most of the critical areas and concepts are touched on. You won’t become an expert in any one area from this volume, but it looks like you’ll have some reasonably deep understanding of the elements that go into making a game engine. Quite an impressive work, and I know of nothing else in this area that is so detailed. I hope I get a chance to read it (who am I fooling? Though I do wish I had the time…) – well, at the least, it’s a place I’ll first go if I want to learn about a topic in game development that I know little about. If you’d rather wax nostalgic about great game engines you have known, as well as what the state of the are is, this article is for you (oh, yeah, the author of this new book works at the company that made #3).
Looking around for titles I’d like to look over at SIGGRAPH, I found these: Game Graphics Programming, Programming the Cell Processor: For Games, Graphics, and Computation, Introduction to 3D Game Programming with DirectX 10, Ultimate Game Programming with DirectX, 2nd Ed., Advanced Game Programming, Game Coding Complete. Which all sort of sound the same (except for the Cell book), but I’d be happy to page through each and see if it looks promising.
There’s a worthwhile comparison of average vertex normal computation methods on the MeshLab blog. He gives the nod to Thürmer and Wüthrich’s method. You can try each of the three using MeshLab itself.
Sure, Spore didn’t light the world on fire as many of us hoped, but a lot of cool technology was explored. Chris Hecker has a worthwhile rundown of some of the great stuff they worked on.
There are some surprisingly affordable 3D stereolithography objects available on Shapeways. I bought Spiral Cage (tiny, but impressive, and so cheap), Clematis (looks delicate, but is quite springy), and Gyroid (pricier, but more sizeable and a fun form). It’s great to see so many people exploring such areas; here’s a detailed summary of resources. Even if you never plan on getting involved, the Flickr area dedicated to such techniques is worth a browse.
This one amused me: a cloud computing company had a contest that was meant to show off Ruby and cloud computing strengths. It was won by people brute-forcing the problem with GPUs: 16 used by the first-place winner (plus 117 CPU cores, which had less performance total than the 16 GPUs), 4 by the second. Steve Worley and others talk about the GPU approach on the CUDA forum (his program, shared with the community there, was used to win second place).
I admire the dedication.

The evils of fps

I completely agree with this blog post by Humus on the uselessness of the performance numbers in most rendering papers. This is something that often comes up when reviewing papers. Frames-per-second (fps) numbers are less than useless, since they include extraneous information (the time taken to render parts of the scene not using the technique in question) and make it very difficult to do meaningful comparisons. The performance measurement game developers care about is the time to execute the technique in milliseconds.

Some papers do get it right, for example this one. The authors use milliseconds for detailed performance comparisons, only using fps to show how overall performance varies with camera and light position (which is a rare legitimate use of fps).

7 Things for July 20th

While at SIGGRAPH I like to look at new books at the booths. One you may wish to check out is Graphics Shaders: Theory and Practice, from AK Peters (or just use “Look Inside” on Amazon). I received a review copy and skimmed through it. If you’re interested in programming in GLSL 1.2 (part of OpenGL 2.1), consider looking at this one. A minor problem is that it’s not quite as up-to-date as the Orange Book (now on OpenGL 3.1), but the difference in core concepts between language versions is not large. The Graphics Shaders book is full color and comes with a lot of GLSL code examples. It has a bias towards scientific visualization, though not so much that it neglects the basics. I particularly enjoyed the chapter on noise, as it gave one of the clearest explanations I’ve seen on the differences between various types of basic interactive noise functions. One or two elements in the book are a little weak – the flowcharts for pipelines are often too small and difficult to read, for example – but all in all this looks like a solid contribution to the field. Don’t expect more elaborate effects, e.g., shadows are not touched upon. It does cover the basics, plus some additional topics like image post-processing (not normally covered in texts I’ve seen). One of the authors wrote a nice learning tool for GLSL, glman, free for download. If you find you like this tool, definitely consider the book.

Another book I noticed recently is Fluid Simulation for Computer Graphics. This is a topic I know little about, I was just interested to see that there’s any book at all. It looks pretty equation-filled, so is definitely for the serious practitioner.

Speaking of fluid simulation, Intel has an article on this topic for games. One of the chief strengths of any publication is that its staff makes a decision based on merit as to what is published and what is culled. So, I have to admit to being leery of anything that says, “Sponsored Feature”, as that means editorial review and decision-making are gone. I tend to err on the side of ignoring such articles (there’s plenty to read already). That said, Intel’s had quite a number of these articles recently, including such topics as instancing, ocean fog, FFT’s for image processing, and quite a few on parallelism.

In the “clearing the queue” category of links, I don’t think I ever pointed out this handy page, which presents all AMD/ATI and NVIDIA presentations at GDC 2009.

There’s now a (not very active, but at least it exists) Microsoft DirectX blog.

On the OpenGL front, NVIDIA has introduced bindless graphics to help avoid L2 cache misses. I will be interested to see how APIs evolve, as the elements in the current APIs that are bottlenecks are not so much CPU or GPU limitations as due to the API constructs themselves.

Thing for the day: an advertisement with interesting stippling.

7 Things for July 19th

Seven more:

Michael Abrash has an in-depth article on rasterization on Larrabee. Perhaps a little too in-depth at times; just skim past the assembly instructions. I also found myself asking, “why do that?” – the key is to just keep reading. He tries to make his examples simple and comprehensible, but at the cost of sometimes feeling like they’re oversolving the problem. They aren’t, it’s just that the solution is in fact used in different circumstances in order to be efficient.
SIGGRAPH has an interactive rendering event summary page. This page is more for the art production side of things, though; Naty’s course, talks, and production sessions summaries are more comprehensive and more useful for programmer attendees.
NVIDIA has a number of events they’re involved in at SIGGRAPH 2009. Here’s the list.
I love this sort of madness: a business-card ray tracer that does depth of field.
Accumulated SSAO: the idea of reprojection, of using previous results by finding where they lie on this frame’s view, is one that seems a tad expensive for interactive rendering. It’s hard to know anything about performance and quality from this page, but I thought it was interesting to see.
I mentioned Processing in the last post. Another language-related resource for graphics and game programming is pygame, a set of Python modules for writing games. A friend said he found this system to be pretty great, that he could whip up a fairly involved game idea in a few hours.
Scribblenauts sounds like the coolest game that will ever come out, period. Even if it’s only 1/10th as good as the previews read, it looks to be pretty darn entertaining.

JGT is now the Journal of Graphics, GPU, and Game Tools

The name change for the journal formerly known as Journal of Graphics Tools was announced today. This does not reflect a change in focus; rather, the new name more accurately reflects the existing focus of the journal. The Journal of Graphics Tools was originally conceived as an ongoing successor to the Graphics Gems book series, and it has since been a great place for practical “nuggets” of graphics tech. Many of the best articles were also collected in a recent book.

I recommend subscribing to this journal, but contributing to it is even better. JGT is an excellent choice for any game developer who would like to publish a bit of tech they have created; while it is a fully peer-reviewed and citable publication, the focus is squarely on practical applications. Authors are not expected to spend a lot of time writing up previous research, summary, conclusion, future work, etc. For more information see the online author’s guide.

In the interests of full disclosure, I should note that all three authors of Real-Time Rendering are on the JGT editorial board.

Game Engine Gems CFP

As I mentioned in a previous post, Eric Lengyel is heading up a new project, a book series called “Game Engine Gems”. It turns out that we ran across the website before it was announced (moral: there’s no hiding on the internet). He’s sent out an official call for papers today – see the book’s website for basic information.

I’m posting today to mention a few dates not currently shown on the website (though I expect this will change soon):

August 1 – Final day to submit article proposals
August 15 – Authors notified of acceptance
October 15 – Final day to submit completed articles

Contact Eric for more information.

Computer-modeled stop motion in “Coraline”

This is a bit old, but still cool: the film Coraline (based on a great book by one of my favorite authors) was stop-motion, not CG. However, the facial animation was extremely smooth, due to a unique process. The expressions were modeled by computer, exactly as they would have been for a CG animated feature. Then for each frame, the faces were “printed” out on a “3D printer” (rapid prototyping machine). These tweened “frame faces” were swapped in for each stop-motion frame. CGSociety has an article describing the production pipeline for this film, an intriguing combination of CG and stop-motion animation.

Left-Handed vs. Right-Handed Viewing

In my previous post I talked about how I think about left-handed vs. right-handed world coordinate systems. The basic idea is simply that there is an underlying reality, and the coordinate system choice is yours.

I compared notes with Jeff Weeks, a topologist friend (who wrote this cool book The Shape of Space that is not full of math symbols, but is just the opposite – approachable and fun, and what you should read after Flatland and Sphereland). Happily, he agrees. He also introduced me to another word for handedness: chirality, coined by Lord Kelvin. Jeff notes an interesting distinction:

You can ask whether the object’s own intrinsic coordinate system agrees with the ambient world space coordinate system (same chirality) or disagrees with the ambient world space coordinate system (different chirality), but you can’t meaningfully call either one of them “left-handed” or “right-handed”.

In other words, the only time you can meaningfully introduce the words “left-handed” and “right-handed” into the discussion is when a human being enters the picture. Once an object (or a space) gets drawn into the human’s physical space, then “left-handed” means “same chirality as the human’s left thumb-index finger-middle finger” and “right-handed” means “same chirality as the human’s right thumb-index finger-middle finger”.

So in particular, data sitting in a file on disk has no intrinsic chirality. What it has is the author’s intention that it be drawn into the human’s physical space with one chirality or the other (so that, for example, the steering wheel in a car model appears on the left-hand side of the vehicle, as perceived by the human viewing it).

OK, so only for viewing you must also know the handedness of the data. We also know it’s fine to have local coordinates that are RH or LH inside a world that is LH or RH, e.g., you create a frog model by mirroring the right half of your frog model with a mirror matrix, but the world itself is one or the other. So far so good.

Where things get tricky in computer graphics is when we talk about something like a right-handed coordinate world and a left-handed viewing system. Right-handed coordinates are pretty common: all Autodesk applications I know use them. It’s a natural extension of a 2D Cartesian plane to make the Z axis point upwards – a 2D floor-plan that is extruded would be thought to extend upwards from the ground, for example. Also, the determinant of a right-handed viewing matrix is positive; left, negative.

However, a left-handed viewing system is used by default by DirectX: the viewer’s X axis goes to the right, the Y axis is up, and Z goes into the screen. This also feels natural, as you label the screen’s X and Y axes from the lower left corner of the display and Z increases with depth into the screen. OpenGL’s viewing system is right-handed by default, the difference being that +Z goes towards the viewer. This negation leads to a fair bit of confusion in documentation with what near and far mean, but it’s consistent with right-handed world coordinates.

So what if you want to use a left-handed viewing system with right-handed data, or vice versa? All it means: there must be a conversion from one to the other, or expect mirrored images. Like my first post notes, the world coordinate system chosen is arbitrary: your RH system or the mole men’s LH system are both fine, you just have to decide which one to use. However, once you choose, that’s it – the view itself ultimately has to be working in the same system, one way or another. It is honestly meaningless to say “I want to use LH viewing with RH world coordinates”, if you want to do so “without conversion”.

Some transform has to be done to go from RH to LH, but which one? Any mirroring transform can mirror through any arbitrary plane will convert from one chirality to the other. Mirroring along the world’s Z axis is one common solution, i.e., set Z’ = -Z for vertices, normals, light positions, etc. If the scene’s data is converted once to LH space, case closed, your LH camera will work fine.

However, say you don’t want to touch the data. Microsoft gives a way to convert from RH to LH, which boils down to again mirroring along the world’s Z axis as the first transform on the view matrix, i.e., done every frame. No time is lost, since the mirroring is simply part of a different view matrix. The funny bit is that you have to deal with the world in RH, the view in LH, as far as defining where the camera goes and how it is oriented. A common way to define a view is by giving a camera position, a target it is looking at, and an up direction. From this you can form a view basis, a matrix to transform from world to view. By Microsoft’s method, you have to make sure to use LH positions and vectors for forming your camera (with Z negated), vs. the RH coordinate you use for your data. Confusing.

There’s another somewhat sensible place to perform mirroring: go from RH to LH at the end of the transforms, after projection to clip space. You’re given a right-handed camera position, target, and up vector and you use these to make a left-handed view matrix – there’s nothing stopping you. None of these coordinates need to be transformed, they can be defined to be the same in RH and LH spaces. However, what will happen is that the image produced will be mirrored along the vertical axis. That is, left and right sides will be switched, since you didn’t compensate for the difference in chirality. Lots of models are symmetric, in fact, so this sort of mistake is not often immediately noticeable. By adding a simple mirror matrix with X’ = -X you can swap the left and right of the screen. This comes down to negating the upper-left value in the projection matrix.

By using this mirror matrix at the end, you’ve made your left-handed coordinate system into a right-handed one. Each time you move the camera, you’re essentially defining a new and (usually) different mirroring plane in world space, one that passes through your eye, target, and up vector. This mirror matrix will then not affect the eye, target, and up directions, since they lie in this plane. Maybe that’s fine for your system. However, this solution can also mess up basic operations and queries. Say you want to pan the camera to the left. So you query your camera for which direction it thinks is left. It hands you one, you move the camera that direction, but the view shifts the other way. This is because you have a mismatch in chirality: your camera’s basis is in LH, but you correct it at the back-end to be RH. The view matrix returned a left-vector which was also in LH, and needs to be converted to RH. Also confusing.

The whole point of the camera is to transform some chunk of visible space into clip coordinates, which then convert (by dividing by W) to NDC coordinates (visible space being -1 to +1 in X and Y, -1 to +1 in Z for OpenGL, 0 to +1 in Z for DirectX). Neither OpenGL nor DirectX in any way requires LH or RH coordinates, you can feed in whatever view transforms you like. Just make world and view chirality match and be done with it.

That’s about it – just make them match, and do so by setting the view (lookat) matrix to match the world’s chirality. At least, that’s my take, this week (which sounds flip, but I’ve been trying to get a good handle on this area for a long time; I like to think I now have one, as of today). If there are other ways to think about this area, and especially if I’ve made any mental errors, please do comment.

By the way, if you want an enjoyable book about handedness and symmetry, get Martin Gardner’s The New Ambidextrous Universe. It talks about some surprising stuff, such as experiments where parity in the universe is not conserved (so if you’re ever mirrored a few times through the fourth dimension on your way to a distant planet, you’ll know how to test which way you came out).

Oh, and also check out Jeff Weeks’ site – some fun and beautiful OpenGL math applications there for free, Mac and Windows, with source. I should note that he uses LH throughout for his OpenGL applications, the rebel. There’s no “correct” coordinate system, so choose your own.

Fast and Furious

Given my last links post referenced “The Fast and the Furious”, I might as well call this post by the 4th movie in that series. Which is bizarrely titled by simply removing two “the”s from the original title. So the 5th movie will just be “Fast Furious”? I can imagine this subtract-a-the for other movies: “Fellowship of Ring”, “Silence of Lambs”, “Singin’ in Rain”, “Back to Future”. Anyway, the goal of this post is to whip through the rest of my links backlog.

I’m still catching up with reading the post-GDC flurry of resources and blog posts and whatnot – you’re on your own. Well, mostly. One or two things: watch the last half of the Unreal 3 new features demo – some nice-looking stuff. Also, the GDC tutorials are available for download; the first set of 7 are what you want. Lots of DirectX 10 and 11 material, from my quick skim. The third talk, by the DICE guys, looked to have some interesting things to say about cascaded shadow maps. Here’s another older presentation, about the Frostbite rendering engine, parallelism, software occlusion culling, ray tracing, and other nice tidbits. What’s also interesting about this one is that it uses a slide hosting site, SlideShare, to hold the presentation. Speaking of slidesets, there are also these from the parallel graphics computing course at SIGGRAPH Asia 2008.

But, you found you’re required to attend a conference between GDC and SIGGRAPH (If so, I want your job). In that case, EGSR 2009 is coming up at the end of June, in Girona, Spain. This is the conference for rendering research in general. There’s still a week before abstracts are due, so get cracking.

In my last links post I asked for open source that loaded and exported a variety of model types and allowed mesh manipulation. Two people answered back: MeshLab. The blog about this package is also worth skimming through.

Also in the previous links article I mentioned the server-side graphics computation model presented by OnLive. I should also mention AMD’s Fusion Render Cloud project, in the same space. Hmmm, maybe this really could work, with compression, and if you don’t mind some lag.

In Gamasutra is a “sponsored” article, but a good one, on Intel’s Threading Building Blocks. I can attest that this component truly does help you take advantage of multiple cores. Knowing at least a bit about TBB is worth your while. Also on Gamasutra is part two of the data alignment article.

There’s a nice rundown of Killzone 2’s graphical features on Brian Karis’ blog.

The sIBL site has some HDR environment maps and manipulation software for download.

Paul Merrell has made plugins available for Max and Blender for his city synthesis procedural modeling research at UNC Chapel Hill.

This diagram of Windows’ graphics makes me think, “it’s just that easy.”

NVScale is an OpenGL-based SDK that lets you use up to four GPUs to store and render extremely large models. It’s nice to see NVIDIA supporting this (non-gaming) area of rendering.

Well-produced tutorial on volume rendering, along with demo code, by Kyle Hayward: part 1, part 2.

There are lots of articles about XNA graphics programming getting put at Ziggyware.

Nothing to do with computer graphics, but this seems like the best computer science class ever.

When nerds and lace-making meet: fractal doilies.