Update (4/27)

I still have a few people to respond to (in particular those who submitted for terrain or particle systems), but submissions are now closed. I got a lot of great responses and only regret that I can't have everyone write. This is going to be an excellent book.

Background

Kevin and I have been working on a book called More OpenGL Game Programming, which is a direct follow-up to Beginning OpenGL Game Programming and an indirect sequel to OpenGL Game Programming. The first part of the book will cover advanced OpenGL topics not covered in our previous books, and the second part will cover (mostly) graphics techniques that are useful to game programmers. The intent is to present the "standard" way of doing fairly common things, rather than introducing new techniques or covering niche topics. We feel that there is a big gap in the books available at this level, and hope that this will be useful to people who have a basic understanding of 3D game development and want to move to the next level.

The Problem

We've been working on this book for almost a year, and haven't been able to find much time to work on it. The problem is that many of the topics we want to cover require that the author either already have pretty extensive knowledge of it, or have at least several weeks free to dedicate to research. When you have more than 20 topics that fall into this category, it becomes pretty daunting. But rather than cancelling the book, or trying to scale back the content, we (or rather, I, since Kevin opted to drop out) decided instead to find (many) additional authors, each of which will cover a single topic (or in some cases, small number of topics), presumably which they already understand fairly well. Rather than have this be a "Gems-style" collection of unrelated articles, however, I have a table of contents that I'd like to follow, and I'll be adding "glue" to make sure all the sections flow together as naturally as possible.

Where you come in

So the point of all of this is that I'm looking for authors. You'll be fully credited for your work, as well as paid (haven't worked out the exact terms yet, but it'll be on the order of $10/page, to be paid once the final draft from you is received). If you're confident in your technical knowledge and skills, but not confident in your writing ability, don't worry; I'll be acting as editor for this, and there will be additional editors as well.

Table of Contents (Updated 4/8)

The following is the table of contents. Any topics listed in italics have either already been written by me or are tentatively spoken for by someone. The ToC is still mostly flexible, so even if you're not planning on contributing, if you think that there are topics that need to be added - or removed - I'd appreciate the feedback. Part I – Advanced OpenGL The purpose of this part of the book is to cover advanced OpenGL topics that weren't covered in the previous books. Chapter 1 – OpenGL Potpourri 1.1 – Vertex Buffer Objects 1.2 – Pixel Buffer Objects 1.3 - Multisampling 1.4 - Occlusion Queries 1.5 – User clip planes 1.6 - Disabling VSync 1.7 – Framebuffer Objects (may be better in the texture mapping chapter under render-to-texture) Chapter 2 – Introduction to Shaders Chapter 3 – Low-level Shaders Covering ARB_vertex_program and ARB_fragment_program, and possibly some of the newer vendor-specific extensions Chapter 4 – The OpenGL Shading Language Covering GLSL Chapter 5 – Advanced Texture Mapping 5.0 – Anisotropic Filtering 5.1 – Compressed textures 5.2 - NPOT textures/texture rectangles 5.3 - Floating point texture formats 5.4 - Bump Mapping 5.5 - Displacement Mapping 5.6 - Parallax Mapping 5.7 - Dynamic Light Mapping 5.8 - Detail Maps 5.9 - Projective Textures 5.10 - Splatting 5.11 - Refraction/the Fresnel effect 5.12 - Render to Texture Part II – The Elements of a Game(?) This section of the book will turn to showing how to do the types of things you'd do in a game using OpenGL Chapter 6 - Special Effects 6.1 – Billboarding 6.2 - Particle Systems 6.2.1 - point sprites 6.3 - Shadows 6.3.1 - Static Shadows 6.3.2 - Projective Shadows 6.3.3 - Shadow Mapping 6.3.4 - Shadow Volumes 6.4 - Volumetric Fog (maybe not necessary, since we already covered fog coordinates in BOGLGP) 6.5 - NPR (mainly just toon shading) 6.6 – Glow 6.7 - Reflections 6.8 - HDR lighting 6.9 – Explosions Chapter 7 – Rendering Nature 7.1 – Skies 7.1.1 – Skyboxes 7.1.2 – Skyplanes 7.1.3 – Skydomes 7.1.4 – Dynamic methods 7.2 – Terrain (probably just going to give an overview of various techniques, but focus on a brute-force method using hardware) 7.2.1 - Geomipmapping 7.2.2 - Chunked LOD 7.2.3 - Hardware based 7.3 - Clouds 7.4 - Fire 7.5 – Water 7.6 – Plants/vegetation? Chapter 8 - Working with 3D Models 8.1 – Static models (.obj?) 8.2 – Keyframe Animation (.md3?) 8.3 – Vertex Skinning (.mdl? .md5?) 8.4 - Summary Include 3ds in there somewhere? Chapter 9 – Game Engine Design Primer? This may be too big a topic to tackle in a single chapter, and we may be better off simply explaining design choices that were made for the game in the final chapter. Chapter 10 - Making a Game: Another Time to Kill (I'll probably just write this after the game is finished) Appendix A – ARB_vertex_program reference Appendix B – ARB_fragment_program reference Appendix C – GLSlang reference Additional chapter ideas: Scene management/Visibility determination? Physics/collision detection? Audio (OpenAL/SDL/fmod)? See below for my comments on the updated ToC

What you'll be writing

Chapters 3, 4, and 9 (if we include it) will pretty much require a single author. Chapter 8 should probably be a single author as well. The rest of the chapters can be split up with different authors for each subtopic. The total length of the book is going to be 400-500 pages. That's about 30 pages per chapter (except for chapters 3 and 4, which will be longer), and about 2-8 pages per topic (depending). Whenever appropriate, you should use figures, screenshots, tables, etc., to make the book more readable.

Demos

Each subtopic should include at least one demo. The demo should be straightforward, clearly illustrating the material presented in your section, while still being relevant to gaming. I'll provide a basic framework that you should use so there is some commonality among all the demos. If the demo needs extensions, it should use GLee. To be consistent with the previous books, the demos should be written using Visual Studio and Win32. However, I'd like to be able to provide SDL versions of all the demos as well.

Deadlines

I'll need to receive the first draft from you no later than the end of June. If any revisions are needed after I review the material, you'll need to submit a final draft by the end of July. This book is not shipping with a CD. Instead, the sample code will be made available via the book's website. So the demos won't be due until the end of August. That said, since you'll be writing at least a little about the demo and probably include a screenshot, you should at least have a working demo before you submit the first draft.

Interested?

If you're interested, please email me with the following: * Which of the above topics you want to cover * A paragraph or two summarizing what you're going to cover related to the topic. * A brief bio of yourself (basically, if I don't know you, I need you to tell me enough to convice me that you know what you're talking about and that you're going to be reliable) * An estimate of how many pages you'll need to cover the topic well. * A description of the demo (or demos) that you'll include. You can choose more than one topic if you want, but don't overcommit yourself. It's going to be very important that everyone does what they say they will do. I anticipate that for at least some of the topics listed above, I'll have more than one interested party. If you know people that may be interested in this, feel free to point them to this thread.

Thanks to the people who have emailed me so far. I'll get back to you soon.

Because of some questions brought up by a couple of people who emailed me, and because the number of responses I've received was smaller than I expected, I want to make a few additional comments.

In order to write for this, you don't have to be an expert in the topic you're writing about (though if you are, it'll be somewhat easier). All you really need is a basic understanding of the topic and a desire to learn more. For most of the topics I've listed, 3 months is more than enough time to research, experiment, and then write about it. I figure that most people here are already researching and experimenting all the time, so the only additional work would be the writing, which isn't too bad.

For your bio, I don't need you to convince me that you're a guru (nor do I expect it). I just need to feel comfortable that you know where to start, and I need to be confident that if I pick you to cover a topic, you'll come through for me. I don't want to have to scramble to find a replacement in 3 months when you don't come through for me.

I have no doubt that collectively, the members of this forum can write about every topic I've listed, so I hope that some of you take advantage of this opportunity. Besides the compensation, I know from experience that having writing credits on your resume is a big plus. If I have to, I know plenty of people in the industry that I can tap to help finish this book, but I think it'd be a lot better to have it be a product of the GameDev.net OpenGL community.

Thanks for the feedback, Krohm. Anyone else who would like to comment on the topics is welcome to do so, as they're still subject to change.

To respond to some of your comments.

The section on occlusion queries is pretty brief and discusses the potential issues with them.

The section on user clip planes just covers the usage of glClipPlane(), and it's less than a page.

Yes, the section on disabling VSync is also brief. Keep in mind that this book, along with BOGLGP, is intended to provide readers with a solid foundation in OpenGL for game programming. As often as people here and elsewhere ask about VSync, I think it's worth spending a page or so on it.

I definitely understand your arguments about the low level shaders. I wanted to include coverage of them because they are supported on a wider range of hardware than GLSL, and because there is a lot of sample code out there that uses them. The coverage would be as brief as possible, and would stress that the reader should stick to GLSL whenever possible.

NPOT and RECT textures are included for the sake of completeness.

When I say Projective Shadows, I'm referring to the classic projective planar shadow technique. It's included because it's simple and still occasionally useful.

Finally, I just wanted to mention that nothing from the original OGLGP was taken from the net. Everything was written from scratch by Kevin and myself. We of course used reference material (notably the spec and the Red Book), but we intentionally avoided reading any online tutorials to avoid the tendancy to plagiarize. Looking back now, yeah, the original book is pretty week, but I think that BOGLGP is a really strong introduction to OpenGL.

I have some demos you can include if you would like them, but I doubt I would have time to contribute any writing. I will probably barely have time to clean up the demos and get them presentable. Collectively the demos illustrate vertex buffer objects, floating point texture formats and render-to-texture, simple HDR lighting, billboarding (CPU and GPU), impostoring, sky domes with atmospheric scattering, terrain (normal ROAM and chunked LOD), and volumetric clouds (using 3 different modeling/rendering techniques). I also have a very simple game engine library based on GameDev's Enginuity series of articles, and I have recently ported some of my old demos over to use it to get rid of any redundant code and clean the rest up. Any shaders used in the demos are written in GLSL.

I only use a few third-party libraries like SDL, libjpeg, and Intel's GLSDK. I wrote the rest of the code and have released it under the BSD license, so you (and your readers) can do pretty much whatever you want with it. All of the project files are for MS Visual Studio 6.0. I've never ported it to any other platform, but given the libraries I'm using, I doubt it will be difficult.

Some of the demos, like the one using ROAM, are very old and use out-dated techniques. Still, you don't have to include the ones you don't like. I've already written articles on some of the demos, like the ROAM and atmospheric scattering demos. I haven't written any articles on the others, and I've retained the publishing rights for the source code of all of them except two (I won't send you those). Send me an email if you're interested in seeing them.

Sean

Quote:Original post by Krohm

1.4 - Occlusion Queries: I just wanted to say there has been some discussion on opengl.org's forum about these. Odds are it's difficult to make the m work right and this means building a decent test app could be difficult.
The latency introduced could be a performance hamper and for "demo-like" apps this always happens. It's difficult to explain their usefulness in simple conditions without showing this behaviour.

I just wanted to mention that GPU Gems 2 has a chapter on how to make occlusion queries useful (with the normal disclaimer that it's not useful for all scenes). To minimize the number of queries, you use a space partitioning tree and, of course, use other culling methods first. To avoid latency, you avoid waiting for the answer to come back. You take advantage of frame coherence and plod on ahead using the answers from the previous frame (intelligently), and collect the answers at the end of the frame for the next frame. Check the answers, and if anything changed that requires you to render something you skipped, go back and render it. It's a bit more complicated than that, but that's the basic gist of it.

Firstly, in which language would demos be written? If C++, would STL and such be allowable? I would guess that binding and fancy function objects should be avoided at least, but std::vector and friends would be nice to simplify code. Also, a standardised vector3f class ( or similar, and perhaps more for quaternions or matricies ) might be useful for example continuity. Just in general, what kinds of assumptions are allowed?

On a more topic-specific note, how much detail is needed? Things like sound or particle systems could be 2 page topics or 200 page ones...