Looking for authors - submissions closed (Updated 4/27)
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.
Once I have learned everthing I can from the first I would hope to get the second to advance my skills.
Good Luck.
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.
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.
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!
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!
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.
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.
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.
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.
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.
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
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...
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...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement