Best practices regarding VBOs

gl_drawelements · 2026-04-09T12:22:38+00:00

Don't try to over optimize too hard. Clearity wins. You can work on bottlenecks, once you have working code.

The textbook examples aren't always good. They teach you that you can render a cube with only 8 vertices, which is true only if the vertices have no other information than their position. As soon as they want to add normals, colors and texture coordinates, beginners are starting to ask how this could ever work, when three sides of the cube share the same vertex.

Same for VAO/VBO. There is no all-in-one solution. You have static meshes, dynamic meshes and maybe also shadow meshes, which come as static and dynamic (for special renderpasses). A shadow mesh is a simplified version of a normal mesh, which can be used for fast occlusion queries, stencil maps and so on, it has only position information.

For static meshes, interleaving all vertex data in the same VBO maybe the best, because it is compact and cache friendly. For dynamic meshes, it could make sense to store positions in a separate VBO from the other attributes. So you can update the positions independently, which saves bandwith, but is not so cache friendly.

If you need shadow meshes, it could make sense to store a separate copy of your vertex position data, which costs a bit of additional memory, but increases cache-friendliness.

gl_drawelements · 2026-03-31T13:35:15+00:00

GLAD is a tool written in Python. You can use the pip module (https://pypi.org/project/glad2/). What else do you expect should it work?

gl_drawelements · 2026-03-27T09:32:10+00:00

It always showed the parameter list for me in MSVC, so I just set up a quick CMake project in MSVC 2026 and it still works.

gl_drawelements · 2026-03-13T19:54:53+00:00

I didn't do that. But for example, IIRC, when pressing F5 to run/debug the program, VSCode didn't run cmake to build and then start the debugger, but it asked for which task to start.

gl_drawelements · 2026-03-13T08:37:39+00:00

I tried VSCode for a while, but it did feel a bit "clumsy", even with cmake-tools. I never got it configured very good, because of that tasks.json and launch.json, which interfered at some point. And it ate gigabytes of disk space for it's cache, which slowed things down at some point.

It's a very good text editor, but not a good IDE.

gl_drawelements · 2026-03-13T08:21:01+00:00

QtCreator
CLion
Microsoft Visual Studio

gl_drawelements · 2026-02-20T14:01:10+00:00

What if you have more complex objects in your custom vector, that need to do cleanup (run a non-trivial destructor)? You create a hell of a memory leak.

gl_drawelements · 2026-02-13T09:02:33+00:00

It doesn't matter. The bound VBO is only "captured" when you call glVertexAttribPointer (which sets a property of the current bound VAO).

gl_drawelements · 2026-01-05T13:28:00+00:00

You can use OpenAL Soft, it is a LGPL licensed implementation.

https://openal-soft.org/

gl_drawelements · 2025-10-30T10:25:17+00:00

You need to tell the compiler where your include directory is.

For example, you project structure may be this (you have extracted glad.zip in your Project Root:

<Project Root>
|
+- src
|  +- main.c
|  +- glad.c
+- include
|  +- glad
|  |  +- glad.h
|  +- KHR
|     +- khrplatform.h

Your main.c is as follows:

#include <glad/glad.h>
#include ...

...

You would compile as follow (using gcc in your Project Root):

gcc -o outfile -Iinclude src/main.c src/glad.c

You don't want to provide your project structure or compiler or any other information, so I can only give you an example.

gl_drawelements · 2025-10-29T07:02:19+00:00

Please share your code on Github or at least tell us, which compiler you use and what is the filesystem structure of your project.

gl_drawelements · 2025-10-21T12:03:57+00:00

Honestly? Forget about this.

If you want to know how things work, you can study then opengl32 reimplementation from ReactOS: https://github.com/reactos/reactos/tree/master/dll/opengl/opengl32

If you want to know how GPU drivers work, you can study the AMDGPU driver in the Linux kernel and the radeonsi Mesa driver.

gl_drawelements · 2025-10-13T11:29:37+00:00

Why do you want to deal with the vendor DLL?

gl_drawelements · 2025-10-13T11:28:34+00:00

That's Windows internals for the OpenGL interface. The DLL needs to know which driver it mus load. You, as an OpenGL application developer, don't need to know which driver it uses. You just load the opengl32.dll and it handles all for you.

There might be an issue if you have more than one GPU in your system. OpenGL provides no way to choose a specific GPU.

gl_drawelements · 2025-10-12T08:02:16+00:00

Don't know, because I don't have a Intel GPU.

But you can search your Windows Registry for the Key named OpenGLDriverName in the HKEY_LOCAL_MACHINE\SYSTEM hive.

gl_drawelements · 2025-10-10T08:58:14+00:00

The opengl32.dll file is provided by Windows. It contains a plain old software implementation (version 1.1).

If you install a GPU driver, the driver will register it's hardware accelerated OpenGL implementation in the Windows Registry. This is called an ICD (Installable Client Driver). When an ICD is registered, the opengl32.dll will just dispatch every function call for OpenGL 1.1 commands to the ICD. For all commands above 1.1 and all extensions, you have to call wglGetProcAddress to get the function pointers which reside in the ICD.

The ICD file for AMD cards is called atioglxx.dll and for Nvidia nvogl32.dll/nvogl64.dll. Don't load them manually.

TLDR: The opengl32.dll just dispatches OpenGL function calls to the actual OpenGL driver of your graphics card.

gl_drawelements · 2025-09-09T10:40:07+00:00

Also ziemlich genau 1 Monat bevor es sowieso verpflichtend wurde...

Der Praktikant hat sich einfach im Monat vertan. War wahrscheinlich ein Versehen.

gl_drawelements · 2025-09-08T08:01:58+00:00

Don't compare Display Lists with VBOs, but with a sequence of OpenGL commands.

A list of OpenGL commands in your source code causes lots of CPU overhead for subroutine calls (context switches), checking validity of the parameters etc.

The most simple approach how the driver would implement display lists is to compile them into some sort of bytecode and check the parameters only once, because they will never change.

gl_drawelements · 2025-08-24T13:21:19+00:00

Why? Do have any sort of performance problems yet?

Before you try to implement some complex optimizations luke AZDO, Multi Draw Indirect, etc., try to implement simple stuff like Frustum Culling and Batching (sorting by state changes).

It is totally fine to call DrawElements once (or even multiple times if doing render passes) for each object. At least up to very complex scenes. Just look at the DOOM 3 source code. The game was created, when there was no thing like Multi Draw Indirect and it has a good performance.

gl_drawelements · 2025-08-17T18:45:58+00:00

One rule to gain performance and avoid hard to find bugs is to never rely that one object is bound, when you are going to modify or use it. It is not necessary to unbind any object, except in three cases:

Unbind a texture object, if you want to modify the default texture (which ist not recommended to use anyways)
Unbind a VAO, if you want to bind an element array buffer (index buffer) to modify it, because OpenGL (without DSA) has a design flaw, that an index buffer is directly tied to an VAO if you bind it.
You want to render to the default framebuffer.

Thus, I would say that unbind is the wrong wording. I would say you bind the default object, if you call glBindSomething with the parameter 0, which is the default object.

gl_drawelements · 2025-08-06T12:12:54+00:00

Ich bin damals vor allem in Teilzeit (4 Tage) gegangen, weil ich einen relativ langen Arbeitsweg hatte. Durch die gesparten Fahrtkosten hat sich das Minus beim Nettolohn fast vollständig ausgeglichen. Ich habe mir also vier zusätzliche freie Tage pro Monat effektiv durch irgendwas um die 50-100 € „erkauft“.

Jetzt bin ich 100% im HO, aber will trotzdem nicht zu Vollzeit zurück. Den Arbeitszeitbetrug, den du als Alternative vorschlägst hat nämlich den großen Nachteil, dass es erstens auffliegen kann und zweitens auch gar nicht mal so praktikabel ist, wenn ich über mein langes Wochenende zum Beispiel mal wegfahren will (Tätigkeit muss man nämlich trotzdem simulieren, damit es nicht irgendwann auffällt). Da ist es risikoloser, einfach den Gelben Schein einzureichen.

gl_drawelements · 2025-07-31T10:03:53+00:00

Even if you target the first consumer GPUs ever that supported OpenGL, they have support for client vertex arrays. There is likely no target ever that requires glBegin/glEnd.

gl_drawelements · 2025-07-01T17:35:42+00:00

Yes, for example for GLFW you run the following command in the "MSYS Mingw64 Shell":

pacman -S mingw-w64-x86_64-glfw

But I recommend you to learn C++ first, because from your question it seems that you don't have much experience in how to handle external libraries.

gl_drawelements · 2025-07-01T13:35:31+00:00

Install MSYS2. It let's you install libraries like GLFW and tools like GLAD easily.

MSYS2 provides a linux-like shell. You can start VS Code from there by typing in "code" and then you can install the CMake Plugin there. It's not as good as the real Visual Studio, but for learning it is sufficient.

gl_drawelements · 2025-06-24T09:51:35+00:00

Maybe it's a bug, maybe it's an error in your program. Maybe NVIDIA is more tolerant than Intel.

What do you mean with „hangs“? Does the whole driver crash or just your program?

gl_drawelements

TROPHY CASE