• Advertisement
Sign in to follow this  

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

This topic is 4654 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


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

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.

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!

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.

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.

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.

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

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.

Share this post


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

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.

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?

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.

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

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)

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

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?

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.

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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By reenigne
      For those that don't know me. I am the individual who's two videos are listed here under setup for https://wiki.libsdl.org/Tutorials
      I also run grhmedia.com where I host the projects and code for the tutorials I have online.
      Recently, I received a notice from youtube they will be implementing their new policy in protecting video content as of which I won't be monetized till I meat there required number of viewers and views each month.

      Frankly, I'm pretty sick of youtube. I put up a video and someone else learns from it and puts up another video and because of the way youtube does their placement they end up with more views.
      Even guys that clearly post false information such as one individual who said GLEW 2.0 was broken because he didn't know how to compile it. He in short didn't know how to modify the script he used because he didn't understand make files and how the requirements of the compiler and library changes needed some different flags.

      At the end of the month when they implement this I will take down the content and host on my own server purely and it will be a paid system and or patreon. 

      I get my videos may be a bit dry, I generally figure people are there to learn how to do something and I rather not waste their time. 
      I used to also help people for free even those coming from the other videos. That won't be the case any more. I used to just take anyone emails and work with them my email is posted on the site.

      I don't expect to get the required number of subscribers in that time or increased views. Even if I did well it wouldn't take care of each reoccurring month.
      I figure this is simpler and I don't plan on putting some sort of exorbitant fee for a monthly subscription or the like.
      I was thinking on the lines of a few dollars 1,2, and 3 and the larger subscription gets you assistance with the content in the tutorials if needed that month.
      Maybe another fee if it is related but not directly in the content. 
      The fees would serve to cut down on the number of people who ask for help and maybe encourage some of the people to actually pay attention to what is said rather than do their own thing. That actually turns out to be 90% of the issues. I spent 6 hours helping one individual last week I must have asked him 20 times did you do exactly like I said in the video even pointed directly to the section. When he finally sent me a copy of the what he entered I knew then and there he had not. I circled it and I pointed out that wasn't what I said to do in the video. I didn't tell him what was wrong and how I knew that way he would go back and actually follow what it said to do. He then reported it worked. Yea, no kidding following directions works. But hey isn't alone and well its part of the learning process.

      So the point of this isn't to be a gripe session. I'm just looking for a bit of feed back. Do you think the fees are unreasonable?
      Should I keep the youtube channel and do just the fees with patreon or do you think locking the content to my site and require a subscription is an idea.

      I'm just looking at the fact it is unrealistic to think youtube/google will actually get stuff right or that youtube viewers will actually bother to start looking for more accurate videos. 
    • By Balma Alparisi
      i got error 1282 in my code.
      sf::ContextSettings settings; settings.majorVersion = 4; settings.minorVersion = 5; settings.attributeFlags = settings.Core; sf::Window window; window.create(sf::VideoMode(1600, 900), "Texture Unit Rectangle", sf::Style::Close, settings); window.setActive(true); window.setVerticalSyncEnabled(true); glewInit(); GLuint shaderProgram = createShaderProgram("FX/Rectangle.vss", "FX/Rectangle.fss"); float vertex[] = { -0.5f,0.5f,0.0f, 0.0f,0.0f, -0.5f,-0.5f,0.0f, 0.0f,1.0f, 0.5f,0.5f,0.0f, 1.0f,0.0f, 0.5,-0.5f,0.0f, 1.0f,1.0f, }; GLuint indices[] = { 0,1,2, 1,2,3, }; GLuint vao; glGenVertexArrays(1, &vao); glBindVertexArray(vao); GLuint vbo; glGenBuffers(1, &vbo); glBindBuffer(GL_ARRAY_BUFFER, vbo); glBufferData(GL_ARRAY_BUFFER, sizeof(vertex), vertex, GL_STATIC_DRAW); GLuint ebo; glGenBuffers(1, &ebo); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo); glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices,GL_STATIC_DRAW); glVertexAttribPointer(0, 3, GL_FLOAT, false, sizeof(float) * 5, (void*)0); glEnableVertexAttribArray(0); glVertexAttribPointer(1, 2, GL_FLOAT, false, sizeof(float) * 5, (void*)(sizeof(float) * 3)); glEnableVertexAttribArray(1); GLuint texture[2]; glGenTextures(2, texture); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture[0]); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); sf::Image* imageOne = new sf::Image; bool isImageOneLoaded = imageOne->loadFromFile("Texture/container.jpg"); if (isImageOneLoaded) { glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, imageOne->getSize().x, imageOne->getSize().y, 0, GL_RGBA, GL_UNSIGNED_BYTE, imageOne->getPixelsPtr()); glGenerateMipmap(GL_TEXTURE_2D); } delete imageOne; glActiveTexture(GL_TEXTURE1); glBindTexture(GL_TEXTURE_2D, texture[1]); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); sf::Image* imageTwo = new sf::Image; bool isImageTwoLoaded = imageTwo->loadFromFile("Texture/awesomeface.png"); if (isImageTwoLoaded) { glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, imageTwo->getSize().x, imageTwo->getSize().y, 0, GL_RGBA, GL_UNSIGNED_BYTE, imageTwo->getPixelsPtr()); glGenerateMipmap(GL_TEXTURE_2D); } delete imageTwo; glUniform1i(glGetUniformLocation(shaderProgram, "inTextureOne"), 0); glUniform1i(glGetUniformLocation(shaderProgram, "inTextureTwo"), 1); GLenum error = glGetError(); std::cout << error << std::endl; sf::Event event; bool isRunning = true; while (isRunning) { while (window.pollEvent(event)) { if (event.type == event.Closed) { isRunning = false; } } glClear(GL_COLOR_BUFFER_BIT); if (isImageOneLoaded && isImageTwoLoaded) { glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture[0]); glActiveTexture(GL_TEXTURE1); glBindTexture(GL_TEXTURE_2D, texture[1]); glUseProgram(shaderProgram); } glBindVertexArray(vao); glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, nullptr); glBindVertexArray(0); window.display(); } glDeleteVertexArrays(1, &vao); glDeleteBuffers(1, &vbo); glDeleteBuffers(1, &ebo); glDeleteProgram(shaderProgram); glDeleteTextures(2,texture); return 0; } and this is the vertex shader
      #version 450 core layout(location=0) in vec3 inPos; layout(location=1) in vec2 inTexCoord; out vec2 TexCoord; void main() { gl_Position=vec4(inPos,1.0); TexCoord=inTexCoord; } and the fragment shader
      #version 450 core in vec2 TexCoord; uniform sampler2D inTextureOne; uniform sampler2D inTextureTwo; out vec4 FragmentColor; void main() { FragmentColor=mix(texture(inTextureOne,TexCoord),texture(inTextureTwo,TexCoord),0.2); } I was expecting awesomeface.png on top of container.jpg

    • By khawk
      We've just released all of the source code for the NeHe OpenGL lessons on our Github page at https://github.com/gamedev-net/nehe-opengl. code - 43 total platforms, configurations, and languages are included.
      Now operated by GameDev.net, NeHe is located at http://nehe.gamedev.net where it has been a valuable resource for developers wanting to learn OpenGL and graphics programming.

      View full story
    • By TheChubu
      The Khronos™ Group, an open consortium of leading hardware and software companies, announces from the SIGGRAPH 2017 Conference the immediate public availability of the OpenGL® 4.6 specification. OpenGL 4.6 integrates the functionality of numerous ARB and EXT extensions created by Khronos members AMD, Intel, and NVIDIA into core, including the capability to ingest SPIR-V™ shaders.
      SPIR-V is a Khronos-defined standard intermediate language for parallel compute and graphics, which enables content creators to simplify their shader authoring and management pipelines while providing significant source shading language flexibility. OpenGL 4.6 adds support for ingesting SPIR-V shaders to the core specification, guaranteeing that SPIR-V shaders will be widely supported by OpenGL implementations.
      OpenGL 4.6 adds the functionality of these ARB extensions to OpenGL’s core specification:
      GL_ARB_gl_spirv and GL_ARB_spirv_extensions to standardize SPIR-V support for OpenGL GL_ARB_indirect_parameters and GL_ARB_shader_draw_parameters for reducing the CPU overhead associated with rendering batches of geometry GL_ARB_pipeline_statistics_query and GL_ARB_transform_feedback_overflow_querystandardize OpenGL support for features available in Direct3D GL_ARB_texture_filter_anisotropic (based on GL_EXT_texture_filter_anisotropic) brings previously IP encumbered functionality into OpenGL to improve the visual quality of textured scenes GL_ARB_polygon_offset_clamp (based on GL_EXT_polygon_offset_clamp) suppresses a common visual artifact known as a “light leak” associated with rendering shadows GL_ARB_shader_atomic_counter_ops and GL_ARB_shader_group_vote add shader intrinsics supported by all desktop vendors to improve functionality and performance GL_KHR_no_error reduces driver overhead by allowing the application to indicate that it expects error-free operation so errors need not be generated In addition to the above features being added to OpenGL 4.6, the following are being released as extensions:
      GL_KHR_parallel_shader_compile allows applications to launch multiple shader compile threads to improve shader compile throughput WGL_ARB_create_context_no_error and GXL_ARB_create_context_no_error allow no error contexts to be created with WGL or GLX that support the GL_KHR_no_error extension “I’m proud to announce OpenGL 4.6 as the most feature-rich version of OpenGL yet. We've brought together the most popular, widely-supported extensions into a new core specification to give OpenGL developers and end users an improved baseline feature set. This includes resolving previous intellectual property roadblocks to bringing anisotropic texture filtering and polygon offset clamping into the core specification to enable widespread implementation and usage,” said Piers Daniell, chair of the OpenGL Working Group at Khronos. “The OpenGL working group will continue to respond to market needs and work with GPU vendors to ensure OpenGL remains a viable and evolving graphics API for all its customers and users across many vital industries.“
      The OpenGL 4.6 specification can be found at https://khronos.org/registry/OpenGL/index_gl.php. The GLSL to SPIR-V compiler glslang has been updated with GLSL 4.60 support, and can be found at https://github.com/KhronosGroup/glslang.
      Sophisticated graphics applications will also benefit from a set of newly released extensions for both OpenGL and OpenGL ES to enable interoperability with Vulkan and Direct3D. These extensions are named:
      GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_memory_object_win32 GL_EXT_semaphore GL_EXT_semaphore_fd GL_EXT_semaphore_win32 GL_EXT_win32_keyed_mutex They can be found at: https://khronos.org/registry/OpenGL/index_gl.php
      Industry Support for OpenGL 4.6
      “With OpenGL 4.6 our customers have an improved set of core features available on our full range of OpenGL 4.x capable GPUs. These features provide improved rendering quality, performance and functionality. As the graphics industry’s most popular API, we fully support OpenGL and will continue to work closely with the Khronos Group on the development of new OpenGL specifications and extensions for our customers. NVIDIA has released beta OpenGL 4.6 drivers today at https://developer.nvidia.com/opengl-driver so developers can use these new features right away,” said Bob Pette, vice president, Professional Graphics at NVIDIA.
      "OpenGL 4.6 will be the first OpenGL release where conformant open source implementations based on the Mesa project will be deliverable in a reasonable timeframe after release. The open sourcing of the OpenGL conformance test suite and ongoing work between Khronos and X.org will also allow for non-vendor led open source implementations to achieve conformance in the near future," said David Airlie, senior principal engineer at Red Hat, and developer on Mesa/X.org projects.

      View full story
    • By _OskaR
      Hi,
      I have an OpenGL application but without possibility to wite own shaders.
      I need to perform small VS modification - is possible to do it in an alternative way? Do we have apps or driver modifictions which will catch the shader sent to GPU and override it?
  • Advertisement