• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Myopic Rhino

OpenGL
Looking for authors - submissions closed (Updated 4/27)

44 posts in this topic

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

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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!
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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]
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
*OT* being payed per page, what is the targeted font size it will be printed in? :)))))

(ignore me)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Myopic Rhino
Prozak: I agree as well, but _the_phantom_ is right, both are outside the scope of this book.

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 just has to sit down and tackle that issue, the lack of decent tutorials on the subject is appaling.

Thank you for taking my thougts on the subject into consideration.

*...goes back to finishing his own Lua tutorial...*
0

Share this post


Link to post
Share on other sites
Sounds like a good idea! It provides non-professionals with the chance to show their potential and knowledge through a book that addresses many in the industry.

A few questions:

Does this work as a competition - everybody submits and article and you choose the best or combine them or do you pick an author which will do the work?

Can the articles include pictures? How many? Generally I see books refrain from using too many pictures.

How long should one section of a chapter be?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Ilici
Does this work as a competition - everybody submits and article and you choose the best or combine them or do you pick an author which will do the work?
No, not exactly. I'm going to choose the author in advance based on a brief proposal and summary of what they want to cover. I'll also take their bio (or if they are active here, what I know about them from the forums) into account when determining whether or not I think they can deliver what they say they will. There are some people here (including you) that I would automatically approve, no matter what they wanted to write about.
Quote:
Original post by Ilici
Can the articles include pictures? How many? Generally I see books refrain from using too many pictures.
Yeah, they really *should* include pictures. I'd like to see at least one figure every 2-3 pages, though more isn't bad if it's appropriate for the topic.
Quote:
Original post by Ilici
How long should one section of a chapter be?
Depends on the topic. 2-8 pages should be enough for most of the topics listed here, though a few will be longer (and a couple can be a page or so). That's assuming minimal code listings.
0

Share this post


Link to post
Share on other sites
HI! i think this book is necesary for the OpenGL game dev comunity , i think that is very useful a topic in Editors and tools programing (GTK and MFC) some basic but useful tutorial what do you think?
see u
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By Toastmastern
      So it's been a while since I took a break from my whole creating a planet in DX11. Last time around I got stuck on fixing a nice LOD.
      A week back or so I got help to find this:
      https://github.com/sp4cerat/Planet-LOD
      In general this is what I'm trying to recreate in DX11, he that made that planet LOD uses OpenGL but that is a minor issue and something I can solve. But I have a question regarding the code
      He gets the position using this row
      vec4d pos = b.var.vec4d["position"]; Which is then used further down when he sends the variable "center" into the drawing function:
      if (pos.len() < 1) pos.norm(); world::draw(vec3d(pos.x, pos.y, pos.z));  
      Inside the draw function this happens:
      draw_recursive(p3[0], p3[1], p3[2], center); Basically the 3 vertices of the triangle and the center of details that he sent as a parameter earlier: vec3d(pos.x, pos.y, pos.z)
      Now onto my real question, he does vec3d edge_center[3] = { (p1 + p2) / 2, (p2 + p3) / 2, (p3 + p1) / 2 }; to get the edge center of each edge, nothing weird there.
      But this is used later on with:
      vec3d d = center + edge_center[i]; edge_test[i] = d.len() > ratio_size; edge_test is then used to evaluate if there should be a triangle drawn or if it should be split up into 3 new triangles instead. Why is it working for him? shouldn't it be like center - edge_center or something like that? Why adding them togheter? I asume here that the center is the center of details for the LOD. the position of the camera if stood on the ground of the planet and not up int he air like it is now.

      Full code can be seen here:
      https://github.com/sp4cerat/Planet-LOD/blob/master/src.simple/Main.cpp
      If anyone would like to take a look and try to help me understand this code I would love this person. I'm running out of ideas on how to solve this in my own head, most likely twisted it one time to many up in my head
      Thanks in advance
      Toastmastern
       
       
    • By fllwr0491
      I googled around but are unable to find source code or details of implementation.
      What keywords should I search for this topic?
      Things I would like to know:
      A. How to ensure that partially covered pixels are rasterized?
         Apparently by expanding each triangle by 1 pixel or so, rasterization problem is almost solved.
         But it will result in an unindexable triangle list without tons of overlaps. Will it incur a large performance penalty?
      B. A-buffer like bitmask needs a read-modiry-write operation.
         How to ensure proper synchronizations in GLSL?
         GLSL seems to only allow int32 atomics on image.
      C. Is there some simple ways to estimate coverage on-the-fly?
         In case I am to draw 2D shapes onto an exisitng target:
         1. A multi-pass whatever-buffer seems overkill.
         2. Multisampling could cost a lot memory though all I need is better coverage.
            Besides, I have to blit twice, if draw target is not multisampled.
       
    • By mapra99
      Hello

      I am working on a recent project and I have been learning how to code in C# using OpenGL libraries for some graphics. I have achieved some quite interesting things using TAO Framework writing in Console Applications, creating a GLUT Window. But my problem now is that I need to incorporate the Graphics in a Windows Form so I can relate the objects that I render with some .NET Controls.

      To deal with this problem, I have seen in some forums that it's better to use OpenTK instead of TAO Framework, so I can use the glControl that OpenTK libraries offer. However, I haven't found complete articles, tutorials or source codes that help using the glControl or that may insert me into de OpenTK functions. Would somebody please share in this forum some links or files where I can find good documentation about this topic? Or may I use another library different of OpenTK?

      Thanks!
    • By Solid_Spy
      Hello, I have been working on SH Irradiance map rendering, and I have been using a GLSL pixel shader to render SH irradiance to 2D irradiance maps for my static objects. I already have it working with 9 3D textures so far for the first 9 SH functions.
      In my GLSL shader, I have to send in 9 SH Coefficient 3D Texures that use RGBA8 as a pixel format. RGB being used for the coefficients for red, green, and blue, and the A for checking if the voxel is in use (for the 3D texture solidification shader to prevent bleeding).
      My problem is, I want to knock this number of textures down to something like 4 or 5. Getting even lower would be a godsend. This is because I eventually plan on adding more SH Coefficient 3D Textures for other parts of the game map (such as inside rooms, as opposed to the outside), to circumvent irradiance probe bleeding between rooms separated by walls. I don't want to reach the 32 texture limit too soon. Also, I figure that it would be a LOT faster.
      Is there a way I could, say, store 2 sets of SH Coefficients for 2 SH functions inside a texture with RGBA16 pixels? If so, how would I extract them from inside GLSL? Let me know if you have any suggestions ^^.
    • By KarimIO
      EDIT: I thought this was restricted to Attribute-Created GL contexts, but it isn't, so I rewrote the post.
      Hey guys, whenever I call SwapBuffers(hDC), I get a crash, and I get a "Too many posts were made to a semaphore." from Windows as I call SwapBuffers. What could be the cause of this?
      Update: No crash occurs if I don't draw, just clear and swap.
      static PIXELFORMATDESCRIPTOR pfd = // pfd Tells Windows How We Want Things To Be { sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor 1, // Version Number PFD_DRAW_TO_WINDOW | // Format Must Support Window PFD_SUPPORT_OPENGL | // Format Must Support OpenGL PFD_DOUBLEBUFFER, // Must Support Double Buffering PFD_TYPE_RGBA, // Request An RGBA Format 32, // Select Our Color Depth 0, 0, 0, 0, 0, 0, // Color Bits Ignored 0, // No Alpha Buffer 0, // Shift Bit Ignored 0, // No Accumulation Buffer 0, 0, 0, 0, // Accumulation Bits Ignored 24, // 24Bit Z-Buffer (Depth Buffer) 0, // No Stencil Buffer 0, // No Auxiliary Buffer PFD_MAIN_PLANE, // Main Drawing Layer 0, // Reserved 0, 0, 0 // Layer Masks Ignored }; if (!(hDC = GetDC(windowHandle))) return false; unsigned int PixelFormat; if (!(PixelFormat = ChoosePixelFormat(hDC, &pfd))) return false; if (!SetPixelFormat(hDC, PixelFormat, &pfd)) return false; hRC = wglCreateContext(hDC); if (!hRC) { std::cout << "wglCreateContext Failed!\n"; return false; } if (wglMakeCurrent(hDC, hRC) == NULL) { std::cout << "Make Context Current Second Failed!\n"; return false; } ... // OGL Buffer Initialization glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glUseProgram(myprogram); glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, (void *)indexStart); SwapBuffers(GetDC(window_handle));  
  • Popular Now