Sunday, October 31, 2010

Renderer Design

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

Sunday, October 24, 2010

Game Engine Gems, Volume 2

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!

Tuesday, October 12, 2010

Welcome Kevin

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.