Giving a Presentation about Computer Graphics: What OpenGL and so on really do

OpenGL OpenGL: Basic Coding
1

So I am giving a talk to young indie video game developers about 3D computer graphics; what OpenGL and DirectX and so on actually are doing below the hood. Now you may think that indie game developers may already know a lot about this but you would be surprised, a lot of indie developers only dabble with premade game engines such as Unity and don’t really understand everything the engine does let alone the graphic library that the game engines use, especially these young developers. They simply write scripts that make their game run. Not to mention that a lot of these young adults are not programmers; they are artist and businessmen. So I am going to inform them what makes their games possible!

I am going to try to present the concepts in a purely theoretical / mathematical way (aka as little as computer science as possible) so that the artist and businessmen can follow along a well.

However here is where I may need help; I am looking to get more “woah!” facts; facts that will make even the knowledgeable programmers interested in the presentation. What very interesting and/or mind twisting facts are in computer graphics that are not widely known? I put what I think are my current “woah!” facts in the line that start with bold text.

Here is my outline:

  • Introduction about how “all you have to do” in a video game or any other computer graphic software is determine what pixels should be what color in order to deliver something understandable to the player/user
  • Introducing the algorithm that determines if a ray intersects with a triangle in 3D space
  • Point out how this family of algorithm is probably the most used/calculated-per-second algorithm there is, with about 200,000,000 computers at an given time computing this over 100,000,000 times per second.
  • Talk about how we store the triangles in memory: a set a points
  • Talk about how we use matrix multiplication to move the triangles/graphical objects around the camera
  • Point out that technically the camera never moves, instead we are moving the entire world around the camera!
  • Talk about the graphics pipeline:
  • Specify the vertex
  • Vertex shader: Moves the vertices
  • <Probably skip Tessellation / Geometry shaders or bring it up later>
  • Vertex Post Processing: Get rid of traingles that are not in the camera’s view
  • Rasterization
  • Fragment Shader
  • End of the pipeline
  • Talk about the Graphics Card: The difference between code that runs on the CPU and GPU (GPU is SIMD: Single instruction, multiple data)
  • (This part is just for programmers) As so, how code that runs a graphics card is different (if statements pretty much don’t exist in shaders!)
  • Finally, a brief mention of extreme forms of optimization, including: Fast inverse square root - Wikipedia
2

Much of what you list is out of date information.

Two specific examples: it used to be true that “if” statements don’t exist and that typically both branches would be executed (i.e “if” might be typically emulated by a lerp, mix or step) but that’s no longer the case. And fast inverse square root is no longer an optimization.

What OpenGL really does: the first line of the first paragraph of most OpenGL specifications describes it well enough: “OpenGL is a software interface to graphics hardware”. It’s most emphatically not just a graphics library (even though that’s what the “GL” stands for, although that’s more a historical quirk than anything else these days). Think about it this way. There are multiple 3D card vendors, and each vendor has multiple hardware generations, each of which requires programs to interface with them differently. There are many different programs, so straight away we have an exponential complexity scenario. What OpenGL does is sit in the middle; it functions as a translator between programs and graphics hardware. So long as your program talks standard OpenGL, and so long as the graphics hardware understands standard OpenGL, the graphics hardware can understand what your program is saying to it.

That’s what OpenGL (and Direct 3D) does: it’s a layer that takes commands from your program, potentially does some validation, batching-up, etc, then passes those commands on to the graphics hardware, which is what actually does the real work.

3

To be even more precise: OpenGL is NOT software. Its a specification. Its the “what will happen” but not the “how it will happen”. The actual software is written by the graphics card vendors, operating system developers, etc. OpenGL defines how the software interface for the hardware is supposed to look like.

4

So I am going to inform them what makes their games possible!

… why?

Non-programming indie game developers should stay away from OpenGL and D3D.

They’re game developers. Their job is to make games, not to deal with a low-level rendering API. They should be using higher-level engines to build their games. They shouldn’t be getting into those details, especially if they aren’t actually programmers.

I don’t see this presentation being particularly helpful to them at getting done the things they need to get done. And even if it’s for just personal interest, I don’t know what they’re going to get out of an overview of the OpenGL rendering pipeline.

I am looking to get more “woah!” facts; facts that will make even the knowledgeable programmers interested in the presentation.

Ugh. Maybe you should focus on providing useful facts. Rather than trying to impress people with esoteric knowledge (like how many ray/triangle intersections are being executed every second), you should gather facts that these people can actually use to accomplish something.

  • Introducing the algorithm that determines if a ray intersects with a triangle in 3D space

Ray/triangle intersections aren’t commonly used by graphics programmers working to make videogames. Graphics hardware are rasterizers, not raytracers.

Oh, ray-tests are commonly used within games, but not for doing graphics. And even then, ray/triangle tests are avoided; it’s usually things like ray/sphere or ray/capsule tests.

So this isn’t a particularly useful fact for understanding graphics.

  • Point out that technically the camera never moves, instead we are moving the entire world around the camera!

That’s irrelevant sophistry even for graphics programmers most of the time. It’s useful to know, but only when you’re dealing with post-projection transforms or NDC space directly. 99% of the time, talking about a moving camera is perfectly fine.

  • (This part is just for programmers) As so, how code that runs a graphics card is different (if statements pretty much don’t exist in shaders!)

That’s not even remotely true, and it hasn’t been since the GeForce FX. Yes, the one over 10 years ago.

Shader hardware can indeed perform conditional branching. And it can do lots of it. However, shader compilers will avoid branching for cases where the value is unlikely to be dynamically uniform when possible. And when not possible, and the value isn’t dynamically uniform, then you get a performance hit.

If all of the branches in a group take the same branch, then they’re cheap. It only becomes expensive when they take different branches.

That’s hardly “extreme”.