To answer the interviewee's question, 3D modelling software uses quad meshes, because they are way more human-readable than tri meshes. When modelling, you need to understand mesh topology and how it behaves to be able to keep the meshes neat and tidy. On top of that, meshes "relax" (change shape by smoothing), when they are further subdivided with for instance Catmull-Clark subdivision, which further adds complexity. The modeller needs to be able to predict this, since they usually start with a low poly model and advance to a higher poly one to add more details. All of this is already hard enough with quads and takes lots of practise, but would be a nightmare with triangles. On the other hand, mesh triangulation algorithms are fast, often multi-threaded and easy to implement, I mean each quad only needs to be split with a diagonal.

Look who's here! Thank you Etay for your tutorials and for keeping the content updated all these years.

at 1:16:32 the reason we usually divide by w is that in homogenous coordinates, (in mathematical there is a topic called projective geometry, and in projective space, there is a notion of scaling a point, (x,y,z) by a factor of w, so it becomes (wx, wy, wz) and so the division by w is actually a common mathematical operation in the projective geometry.

Around 1:10:00 is a great explanation of why we multiply each vertex by the inverse of the camera transform (aka the view matrix), because we want to move the world with respect to the camera, undo the translation of the camera, undo the rotation, and anything else, hence inversing the operations that happens if we were to multiply by a camera transform.
Thanks so much for this interview.

I had no idea that vertex shaders were offloaded to the CPU. That's fascinating, albeit not super surprising (considering having both on the same SOC lets you do interesting stuff like that).

I wish I knew more, but from what little I've seen of Silicon Graphics hardware, their 3d cards may have been composed of something as simple as modified MIPS cores, much like their CPU, and not too many of them! And part of why they cost so much is down to RAM being so much more expensive, relatively, than it is now. Like a z-buffer being an optional add-on you might try to do without because it adds 5-10k to the cost of the machine. It's amazing how far silicon has come since the early 90s.

@01:14:10 The pixel is the actual element that will be lit up, a fragment is a pixel candidate, a value that maybe will be sent to a pixel to be actually lit on screen, but not all fragments will be sent to a pixel, when they are depth culled for example. The more you know 🎉🧙‍♂️

Learning so much from these talks!

Amazing informative video but it sorely lacks some kind of visualization on some topics for example the matrix transforms

Fantastic episode! learned a lot.

30:50 Silicon Graphics workstations where high-performance back then because they were symmetric multiprocessor systems not unlike today's HPC clusters built out of multiple CPUs. On top of that they also used 64-bit wide data busses & operated multiple memory channels in parallel. They did all that years before anyone else were trying to do that, except maybe Cray & some purely academic projects like the Transputer (which is otherwise not really comparable to the other ones because it had a completely different arhcitecture).

Wow.... THE OGLDev! Many have learned from you Etay... Thanks for all your contributions!

3:30 the first integrated GPU from Intel I remember was the i810 & came out in 1999.

Rendition Vérité 1000 was a Way ahead of it's time. It was universal, a first GPU and ran Vquake. But performance was limited by the technology. Fixed architecture gave higher performance and temporarily won.

1:48:18 but even having so much calls in opengl, it is still usually faster than vulkan...

I'm going to be a bit radical here and I understand many won't agree with me but here it goes; Vulkan was a mistake. It is an over-engineered mess. Most of the operations that it requires you to explicitly control could have been API calls what you make when you need it otherwise has good default values anyways. It has some nice advantages such as multithreading, but those could have been implemented in OpenGL in an evolutionary step instead of a whole new API.

You could say that if you don't like it, OpenGL still works. True and not true. It is abandoned and does not natively support any modern features. You need Nvidia extensions to use features such as Mesh Shaders.

I hope next-generation API's draw from simplicity of OpenGL & DX11 and keep the speed of Vulkan & DX12. Metal achieved this and stands as proof that it is very achievable

An hour long commute still sucks. Just because people have just gotten so used to long commutes doesn't make them suck any less.

Etay sounds like a politician: he's asked something, he answers something completely different

25:48 You do the same thing and get different results? Doesn't Einstein disagree here? 😂

What makes OpenGL hard is the fact that it has a multitude of really bad design choices, and it's documentation is poorly written, disjointed, incomplete, and sometimes just plain wrong.  

Working with it is like walking through a mine field where you hit bullshit like your shader won't compile and won't give you an error log and you think you are doing everything right until after hours of checking everything for the 20th time and scouring the documentation you stumble across some obscure piece of information in some ancient post that leads you to learn that the error is caused by you trying to pass a single variable from the vertex shader to the geometry shader and despite it not being an array in the vertex shader where it originated, it must be one when received by the geometry shader, or the shader will not compile.  So it must be a scalar variable going out of the vert shader, but a single element array going into the geometry shader, or the shader will not compile.  Brilliant.

Then you wonder who the fuck is responsible for such a design choice and want to kill them.

And this kind of shit happens just about every time you think you might finally have a smooth workflow and are thinking "hey maybe OpenGL isn't so bad after all...."