overv / open.gl Goto Github PK

yandex.st along with other Yandex domains is blocked in Ukraine. Please use other CDN, for example jsdelivr which is recommended on the download page of Highlight.js:

<script src="//cdn.jsdelivr.net/gh/highlightjs/[email protected]/build/highlight.min.js"></script>

Relevant code is here:

Are there any chances for epub version. Since this book is written in markdown, creating ebook with gitbook should be easy.

Hi. I noticed that some part of the sample code are using 4 spaces for indentation, while others are using 1 tab character.

Would you format them according to your preferred coding style?

e.g.

The Transform Feedback chapter source code file seems to be empty.

https://github.com/Overv/Open.GL/blob/master/content/code/c8_final.txt

I guess this is not intended :)

hello, and great site! thanks for taking the time to put it up.

i'm planning on basing some of my floss code on what you have here. would you mind specifying which license you'd like to offer your code with? i probably shouldn't entwine our code without knowing that's a-ok with you.

if you'd like to use a permissive license, i suggest apache 2.0 or CC0. thanks!

I just finished your tutorials and they are great. I noticed, however, that most of the examples deal with a single primitive. It would be awesome to have a tutorial explaining how to set up the pipeline for working with multiple different primitives. I guess that drawing 2 cubes and 2 tetras (one of each moving) should be enough to explain:

• how to set up multiple VAOs, with different EBOs, in an initialization step,
• how to update some of the model matrices in a loop,
• how to draw the different VAOs in a loop.

I think such a tutorial could be a good complement to the rest. It would give a feeling about how a "real-world" OpenGL program looks like.

Bests,
Gonzalo

I have a serious issue with this tutorial. It's the singlemost best tutorial on OpenGL I've ever seen, old glBegin() style and new VBO style combined. There is a distinct lack of all my money, because I keep shoving it at the screen and nothing happens. Shame on you for making things so clear and sensible and giving me something pleasant to read this afternoon. At least you use C++, or else I would have to admonish you for having no flaws whatsoever.

Thanks for your efforts on this great tutorial.

On line 33, you pass settings as 4th argument of window, this variable doesn't exist.
I'm pretty sure the variable to use is context, I changed it, the code compile without errors, but it still displays nothing on my Macbook Air.

The typo is: on page 9: after "When you run your application, you should see something like this:" -- no picture is really shown

On page 55 of the current version of the PDF (at https://raw.githubusercontent.com/Overv/Open.GL/master/ebook/Modern%20OpenGL%20Guide.pdf), the book includes these lines:

glm::mat4 trans;
trans = glm::rotate(trans, glm::radians(180.0f), glm::vec3(0.0f, 0.0f, 1.0f));

That doesn't work anymore, since glm v0.9.9.0 removed default initialization of vectors and matrices. It should probably be replaced with something like this:

float identmat[] = {
	1, 0, 0, 0,
	0, 1, 0, 0,
	0, 0, 1, 0,
	0, 0, 0, 1,
};
glm::mat4 trans = glm::make_mat4(identmat);
trans = glm::rotate(trans, glm::radians(180.0f), glm::vec3(0.0f, 0.0f, 1.0f));

In the Drawing Polygons chapter, the color animation is made dependent of time by dividing clock() by CLOCKS_PER_SEC. This is an obsolete method to get the elapsed time as per POSIX, CLOCKS_PER_SEC is always defined as 1000000, regardless of the actual clock ticks per second. On my machine, for example (Arch Linux 64-bit, Intel processor), this animation is extremely slow.

The recommended approach is to use clock_gettime(), like this:

#include <time.h>

...

struct timespec t;
clock_gettime(CLOCK_MONOTONIC, &t);
float time = t.tv_sec + t.tv_nsec / 1e9;

Left the site open while doing other stuff for a few hours, came back to this:

Win7, Google Chrome Version 36.0.1985.125 m, run in Incognito Mode (disables extensions)

To Reproduce:

1. Open any Open.gl page in Chrome
2. Watch memory usage slowly climb

Usage only grows when the page is in view. Minimizing will stop the growth.

Have not tested in other browsers.

A few days ago I happened to browse the site on a computer without AdBlock and noticed the ridiculous amount of ads the Disqus comment system has now.

Now I'm in the strange position of being a website owner and hoping the majority of the visitors use AdBlock, because then it's not really a problem. Since the site is targeted at programmers i.e. tech savvy users, I think most of them are already using AdBlock, but I could be wrong.

Do you guys think replacing the comment system is worth it? Do you know another good threaded comment system that doesn't require signing up for Facebook? Keep in mind that switching will likely mean losing all existing comments.

OpenGL tutorials have a peculiar place among programmers. Many neophyte programmers use them directly, often copying large parts into their projects and making only alterations that suit their needs.

As such, these tutorials are often where they get their first real exposure to the C++ language.

So I find myself dismayed when many newer OpenGL tutorials do things like this:

const GLchar* vertexSource =
    "#version 150 core\n"
    "in vec2 position;"
    "in vec3 color;"
    "out vec3 Color;"
    "void main()"
    "{"
    "    Color = color;"
    "    gl_Position = vec4(position, 0.0, 1.0);"
    "}";

C++11 added the raw string literal feature specifically for cases like this, where you're writing a literal that represents code that is in a different language.

New users need to be encouraged to use the language properly. OpenGL users ought to know that raw string literals exist in C++ and how to use them on shaders.

const GLchar* vertexSource =
R"glsl(#version 150 core
in vec2 position;
in vec3 color;
out vec3 Color;
void main()
{
    Color = color;
    gl_Position = vec4(position, 0.0, 1.0);
})glsl";

This is not a trivial matter of convenience; it affects how users debug their shaders. Your original version puts all of the shader code (save the #version declaration) on the same line. This means that, if the user makes a mistake, the error log will not help them, since it cannot point to the line where the error happened.

By contrast, the raw string literal version uses actual lines, which can in part help the user track down the specific problem.

I'm not asking that you litter your code with C++11-isms. I'm not saying that you should put auto and decltype and lambdas wherever you possibly can. But something like using raw string literals like this should be a no-brainer.

I can understand if you want to limit the compiler version to C++03 only.

If the browser screen is under a certain width, the ad snaps over to the right hand side and obscures the text. It makes the tutorial very frustrating to use when you have a small browser window.

There's an ad in the side bar that doesn't want to stay there

It disappears when zooming in (thanks to responsive layout mentioned in #48 ?), and doesn't obscure any text, but is still annoying.
I don't know exactly where the problem comes from, but found an oversized <iframe>:

<div id="adbox" class="adbox-side" ...> [160x600]
 <div ...> [160x250]
  <div id="google_ads_iframe_/..."> [160x250]
   <iframe id="google_ads_iframe_/..." ... width="300" height="250"> [300x250]

At least, that's how it works in
Tor Browser 8.5.4 (based on Mozilla Firefox 60.8.0esr) (64-bit)
Cannot check in other browsers since opening the website without VPN gives "connection timed out" for some reason (probably my provider carpet banning all websites on a single IP to satisfy the government's demands)

SFML 2.3+ supports using core profile and even the OpenGL version can be requested.

For me, using the simple ContextSettings instance given in the articles only creates a 3.0 context with shaders supported upto 130 only. Although, everything in the series still works after just downgrading the version at the top, it'd be much better if the context settings were explicitly given to allow OpenGL 3+ features.

The following code is sufficient:

    sf::ContextSettings settings;
    settings.depthBits = 24;
    settings.stencilBits = 8;
    settings.antialiasingLevel = 2;
    settings.majorVersion = 3;
    settings.minorVersion = 2;
    settings.attributeFlags = sf::ContextSettings::Core;

I put together an OpenGL quickstart boilerplate a while back while working through your tutorials and the LearnOpenGL tutorials. I opened an issue to add it to LearnOpenGL see LearnOpenGL#11. I figured this may be of interest to this series of tutorials as well. Basically it bundles all the dependencies as submodules and statically compiles/links to avoid any dll-copying or installation headaches. I've verified that it works across all major platforms.

Is this of any use to you?

So I just ran into an issue similar to this: https://stackoverflow.com/questions/23026612/gldrawelements-crash-opengl-3-2-windows-7

Perhaps it's worth noting that if you bind GL_ELEMENT_ARRAY_BUFFER before binding a VAO, it will use the (null) element buffer currently bound to an (empty) VAO. Just my 2 cents.

Maybe you can add an open asset importer (for drawing .objs) (and texturing them) guide?

A while ago you modified the example code so that the GLSL code went from looking like this:

const GLchar* vertexSource =
    "#version 150 core\n"
    "in vec2 position;"
    "void main()"
    "{"
    "   gl_Position = vec4(position, 0.0, 1.0);"
    "}";

to this:

const GLchar* vertexSource = R"glsl(
    #version 150 core
    in vec2 position;
    void main()
    {
        gl_Position = vec4(position, 0.0, 1.0);
    }
)glsl";

Okay, certainly an improvement, easier to type, etc. But at some point you also added that 'Shader Macro' #define, yet for whatever reason you didn't modify the format of the shader code such that said define was actually being used. I hope you'll agree that the following format is superior to the prior two and will update the example source files appropriately, as I found it more readable and easier to understand than the previous two valid but unwieldy formattings:

const GLchar* vertexSource = GLSL(
    in vec2 position;
    void main()
    {
        gl_Position = vec4( position, 0.0, 1.0 );
    }
);

As you can see, we can omit the #version line, and the syntax is even simpler and easier to remember(!). It may not be desirable for some edge-cases where you want to mix GLSL versions (is that even a good idea?), but for newbies it cleans things up a bit, IMHO.

Additionally, and not really related: I've gone through your tutorials and found them helpful, and I used SDL to handle window management, the GL context, etc., rather than SFML/GLFW. Accordingly, I have working, compilable versions using SDL2 and SDL2_image that I'd be happy to send your way if you wanted to add them to the repo. There may be a few slightly-differently named vars, and my preferred formatting is slightly different, but you should be able to see the relevant SDL-bits with a quick diff if you were so inclined. Let me know if you're interested, or if it's trivial enough that you don't want to bother.

The chapter about framebuffers suggests this:

Try changing the clear color of the scene and reading it back using glReadPixels to check if the scene renders properly to the new framebuffer.

Why not add a note somewhere about graphics debuggers? For example, I've been learning a lot from just looking at the output of CodeXL:

I don't have to worry about writing extra code with glReadPixels, I can just look at my debugger to make sure it's rendered okay. I guess using glReadPixels is a good excercise in itself, though.

I can visit the URL http://open.gl/drawing with Chromium and it works fine, but it always make Firefox crash. Logs in the console say:

ATTENTION: default value of option force_s3tc_enable overridden by environment.
Erreur de segmentation (core dumped)

I'm running Archlinux 64bits with Linux version 3.14.3-1-ARCH
Should I report this bug to the Firefox bugtracker?

I am using Transform Feedback to write the data of GPU operations to the buffer and obtain the number of generated entities through glGetQueryObjectuiv. However, unlike the example you provided in the following website, the number of vertices generated each time in the geometric shader is different. For example, I will add some if filtering conditions in the code, which results in a maximum of 3 vertices, but only 2 directly emitted vertices. So when I want to copy data from memory, how to fetch the number of vertices of each primitive to determine the size of the buffer is a very troublesome problem.
Therefore, I try not to filter vertices in the conditions, but instead return the default vertex. At the same time, I add a flag (Valid) for each vertex to determine whether the vertexe is valid or not. This method ensures that the maximum number of returned vertices is 3, so it can accurately calculate the buffer data size. However, this can lead to excessive data space for fetching copied data, and increasing the time consumed when re-filtering on the CPU.
So, I would like to inquire if there is a simpler way to fetch the number of vertices for each primitive, so that I can create a space of appropriate size to copy the data from the buffer. Thank you very much!

For SDL2, it is required to add this line to get a stencil buffer of 8 bits:

SDL_GL_SetAttribute(SDL_GL_STENCIL_SIZE, 8);

If you don't call this, there will be no stencil buffer. This isn't mentioned anywhere, so will go by unnoticed in the later page making the reflection of the cube. Perhaps this is worth putting somewhere in the "Context Creation" page?

In the texture page, it is explained that the bottom left corner has coordinates of (0, 0). However, in the code, the coordinates are (0, 1). The image comes out correctly because the texture is loaded in upside down.

Hi, i think it would be very comfortable for the readers if the #nav menu was kept visible as you scroll down.

It could be easily achieved by adding '#nav { position: fixed; }' to the CSS.

I was working through the pdf version and noticed that it's missing the transformations section that is on the website.

Product: Open.GL
Download: https://github.com/Overv/Open.GL
Vunlerable Version: latest version
Tested Version: latest version
Author: ADLab of Venustech

Advisory Details:
A Cross-Site Scripting (XSS) was discovered in “Open.GL latest version”, which can be exploited to execute arbitrary code.
The vulnerability exists due to insufficient filtration of user-supplied data in the “content” HTTP GET parameter passed to the “Open.GL-master/index.php” URL. An attacker could execute arbitrary HTML and script code in a browser in the context of the vulnerable website.
The exploitation example below uses the "alert()" JavaScript function to see a pop-up messagebox:
Poc:
http://localhost/.../Open.GL-master/index.php?content=%22%3E%3Cscript%3Ealert(1);%3C/script%3E%3C%22

There's a bug/typo (a syntax error) in the code of the geometry shader itself; the second line of code in the shader's main function:
gl_in[0].gl_Position = proj * view * model * gl_in[0].gl_Position;
should actually be:
gl_Position = proj * view * model * gl_in[0].gl_Position;
else the shader won't compile and the only graphical output you'll get (or at least I did) will be a white point at the center of the window. I added some debug output to the 'Shader Creation Helper' function in an attempt to figure out which shader(s) was/were broken:

// Shader Creation Helper
GLuint createShader( GLenum type, const GLchar* src )
{
    GLuint shader = glCreateShader( type );
    glShaderSource( shader, 1, &src, nullptr );
    glCompileShader( shader );

    GLint compileResult = GL_TRUE;
    glGetShaderiv( shader, GL_COMPILE_STATUS, &compileResult );
    if( compileResult != GL_TRUE )
    {
        std::cerr << "Failed to compile " << shader << std::endl;
        return -1;
    }

    return shader;
}

It output 'Failed to compile 2'.
I checked that it wasn't counting from 0 by intentionally adding a syntax error to the vertex shader, the error output became 'Failed to compile 1' 'Failed to compile 2'. Geo shader confirmed. Still, this wasn't much to go on, and I was stumped for a while. Saw that learnopengl.com has a section on debugging (specifically GLSL), which you don't really touch at all unfortunately, and found the GLSL Lang Validator: https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/

After making a temporary gShader.geom file (which omits the encapsulating const GLchar* fragmentShaderSource = GLSL( ... );) and running it against the Lang Validator, it informed me that gShader.geom
ERROR: 0:16: 'assign' : l-value required "gl_in" (can't modify shader input)
ERROR: 0:16: '' : compilation terminated
ERROR: 2 compilation errors. No code generated.

Which was a bit cryptic at first, but even my small amount of C++ ability was enough for it to sink in that it was telling me I was trying to assign a value to gl_in, which clearly was a no-no as it's immutable.

Modifying the assignment as I've shown above allows us to get our sexy, spinning wireframe cubes as desired:

Hi! It looks like you compiled the ebook with LaTeX. If so, do you mind using lstinputlusting to include the source code as it also offers syntax highlighting:

\usepackage{listingsutf8}
\lstinputlisting[language=C++, numbers=left, linerange=44-71, firstnumber=44]{main.cpp}

Regards

I tested on Firefox 25, Chrome 30 and Android Chrome 30, and none of them are showing the .livedemos (to be exact, the placeholder image is showing up, but the demo itself doesn't).

As far as I can tell, it's caused by this statement:

// Syntax highlighting
hljs.initHighlightingOnLoad();

crashing with this error:

ReferenceError: hljs is not defined

This causes the rest of this <script> tag not to be executed, including the WebGL demo part.

Highlight.js seems to be correctly included, but for some reason it doesn't work.

I'll try and fix this if I have time this weekend, but in the mean time a quick workaround would be to isolate them by putting a separate closure around each block: Syntax highlighting, Disqus, Google Analytics and WebGL demos

On the eBook formats, code are either cropped (ePub) or overflowing outside of the box (PDF).
I suggest to have the code wrapped to next line for both format.

ePub version:

PDF version:

Really awesome tutorial and thanks! but there isn't any mention of lighting, normals nor materials. I consider them to be quite important.

Since version 0.9.6.0, GLM broke compatibility with previous versions to use radians instead of degrees.

I'd gladly make a PR to fix this in the code/articles, but I was wondering if it was more desirable to do e.g glm::radians(45.0f), or simply 3.1415f/4.f, or use const float pi = std::acos(-1);, and do pi/4.f?

I personally think glm::radians(45.0f) is more understandable/readable to someone who is new to graphics programming and/or inexperienced in trigonometry.

I just found that I can disable the Disqus ads and I've done so. The comment section looks a lot cleaner now, so the custom system isn't a huge emergency anymore.

As an experiment, I've added Google Adsense under the navigation menu to help with paying for the hosting and domain. The majority of visitors is probably using AdBlock (including me), but if they make even $10/month, it would already help.

Do you think the ads are intrusive? Should I perhaps create just a horizontal banner between the content and comments instead of this?

In the section of drawing (https://open.gl/drawing) in the section "Combining shaders into a program
" you talk about drawing to buffers, but in this context I think you meant framebuffer, or I am mistaken? I'm a newbie in terms of OpenGL, but if you meant framebuffer you should have written "framebuffer" especially when earlier you talk about buffers as a structure for uploading data from the program, so it's becoming confusing.

a set of tutorials + examples to use OpenGL with Qt . that would be very helpful .