44 replies to this topic

[Dave Astle]

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)

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

[Gor435]

Well I really hope you don't have to cancel this book I am looking forward to it [although I still am having problems learning with the first book mostly my fault and I use Dev-C++].

Once I have learned everthing I can from the first I would hope to get the second to advance my skills.

Good Luck.

[Dave Astle]

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.

[Krohm]

I had bought GL game programming. A thing which disappointed me is that the book is basically a collection of stuff taken from the net. I hope this does not happen this time. I also found the book rather weak in general and I rarely check it (just the vertex array section).

By the way, I'm not sure of some chapters.
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.
1.5 – User clip planes: I'm not sure those things are really supported, besides NEAR and FAR. Maybe I'm misunderstanding the functionality.
1.6 - Disabling VSync: this must be little. MSDN is rather self-exaplanatory on this.
Covering ARB_vertex_program and ARB_fragment_program, and possibly some of the newer vendor-specific extensions: I'm also a fan of ARB_vp and ARB_fp but I must admit that 1- "plain" ARB_vp is badly outdated 2- ARB voted against low level programming. While I still thing NV holds >50% of the installed base, I hardly believe there's future for ASM-like things. This chapters could be quickly outdated. Someone would say it's badly outdated even now.
5.2 - NPOT textures/texture rectangles: take my two cents, don't even think about RECT textures. They are a mess. I have support for them and they really blow up the complexity, assuming NV_rect or EXT_rect. If you're speaking of ARB_npot, then there's nothing much to say on that topic as I see it.
6.3.2 - Projective Shadows and 6.3.3 - Shadow Mapping: what's the difference? I hope this is referring to PSMs since everyone can get standard shadow maps in a week of work.

I hope you'll find those two cents useful!

[Dave Astle]

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.

[Krohm]

After reading this, I agree with most you replied in your message.

I also wanted to say my previous message reads a bit "too strong", I guess I should have written more extensive descriptions of what I meant to say. Looks like it hasn't been misunderstood anyway.

[rick_appleton]

I agree with Dave on the subject of ARB_vertex_program and ARB_fragment_program. I was recently doing a spell of development on a laptop, which didn't support GLSL, and only partially supported the ARB_*_programs. Laptop videocards are a lot less powerfull, and you don't upgrade a laptop as often as a desktop computer.

[s_p_oneil]

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

[s_p_oneil]

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.

[Dave Astle]

Sean: Thanks, I'll check out the demos. I'm sure that at least a few of them will fit in.

AP: Yes, the demos will be in C++. Basic STL is fine. My main goal is to have the demo code be easily understandable.

As for the detail level... with a book this size covering this many topics, you obviously can't go into excruciating detail. What I've tried to do in my own writing is provide just enough theory for the reader to have a decent understanding of how things really work, and have the main focus be on practice and application, without focusing on too much on one particular implementation. So, for example, with particle systems, I'd probably discuss what problems they are meant to solve, what attributes they might have, etc., and then discuss some different design choices for implementing them, accompanied by a simple implementation that can be extended by the reader.

Btw, I'll post an update later about which topics have been spoken for.

[phantom]

Dave, I assume you got my email re:glsl section... just checking it didnt get eatten [grin]

[Dave Astle]

Yeah, sorry, I still need to respond to everyone who has emailed me, but to be brief: you're pretty much spot on with what I'm looking for in that chapter. I'll send a more detailed response later, but I'm late picking up my daughter [grin]

[phantom]

heh, fair play [grin]

[python_regious]

Damn it, if only this was three months later... I don't have anywhere near the time right now [sad]...

[Prozak]

Idea: Create a closed WiKi, that you open up to possible Authors, and everyone can chip in a bit, although there will allways be "Chapter Supervisors" of course, to make sure everything falls into place.

I for one, although I don't see myself writing any of these chapters, I can do some assistant work, in researching examples, tutorials, code, etc...

I do feel that there aren't any game programming books out there that really sit down with the reader and guide them through two key areas: Multithreading and plugin designs.

These are areas that are either filled up with myths, or beginners coders just see them as too complex, when they're really not...

In regards to graphics code per se, there should be a book out there with a decent BSP primer, instead of historical snippets like "BSPs where used in Doom...", and a decent intro, backup up by a downloadable demo or library, shouldnt take more than 20 pages, if I'm not grossely underestimating it.

What do you guys think of my thoughts?

[phantom]

some good ideas there Prozak, the MT stuff definately, however kinda out of the scope of this book I feel [smile]

[soconne]

I'll definitely be buying a copy when it comes out.

[Dave Astle]

Prozak: I agree as well, but _the_phantom_ is right, both are outside the scope of this book.

Anyway, I just updated the ToC. Most topics have at least one tentative author at this point, but there are still a few topics that need to be covered:

1.6 - Disabling VSync (I'll probably just write about this)
1.7 – Framebuffer Objects (will probably be included in the render-to-texture section anyway - either way I can write about it as well)
3.0 - ARB_vertex_program and ARB_fragment_program
5.7 - Dynamic Light Mapping
5.8 - Detail Maps
6.8 - HDR lighting
6.9 – Explosions
7.1 – Skies
7.1.1 – Skyboxes
7.1.2 – Skyplanes
7.1.3 – Skydomes
7.1.4 – Dynamic methods
7.3 - Clouds

Originally, the skies topic was marked as taken because I have an article that I wrote for another book a couple of years ago that I was going to update, but the article was pretty basic (focusing on static skyboxes), and I think there are people here who are capable of writing about much more exciting techniques (perhaps I could include my stuff as an intro to the basics and someone else could add more on dynamic methods)

In regards to the additional chapter ideas, at this point, it looks like we'll definitely be including a chapter scene management/visibility determination, etc. Someone has offered to write an OpenAL chapter, but I'm beginning to feel that it's a little off topic for the book.

[Drew_Benton]

Quote:

Original post by Myopic Rhino Someone has offered to write an OpenAL chapter, but I'm beginning to feel that it's a little off topic for the book.

Darn! [wink] I think your right Dave, this book would be better just for the OpenGL specifics in relation to Game Programming. I mean it's not about making games with OpenGL, otherwise there would need to be info on the other components such as input, file i/o, etc...