31–37 of 37 posts
I would love a section on anti-aliasing. It seems to be the big thing missing.
FXAA and similar antialiasing algorithms fake it as a post process effect.
I remember once I needed to macro up a software that needed an X server with OpenGL to run. (Like really dirtily hack it up, with xmacro and stuff like that). I wish I could set up a headless X server with a dummy OpenGL renderer (witch doesn't actually render anything), so it doesn't bottleneck on rendering that isn't used anyway. I guess it's even easier to write such and OpenGL implementation. edit: Now I see it d…
The title is a bit misleading, this is boilerplate code for a graphics programming course and it hasn't got much to do with OpenGL. The articles describing the operation are much more interesting than the code itself. It's just an inefficient triangle rasterizer. All it does is loop over the pixels in a rectangle covering a triangle, and for each pixel inside it calls a "shader" function. All the beef is in these 40…
Creating a dead-simple software rasterizer goes a long way toward improving one's understanding of how apis like OpenGL and DirectX work and how to use them.
I would love a section on anti-aliasing. It seems to be the big thing missing.
That's probably because OpenGL doesn't do antialiasing by default. When it does it, it does it by rendering everything at a larger scale and downscaling it (well, actually MSAA allows the GL to avoid having to do this to everything , and only do it for some buffers) FXAA and similar antialiasing algorithms fake it as a post process effect.
MSAA is faster than supersampling because the GPU generates subsample coverage but doesn't individually shade each subsample. And, this is absolutely critical, there is a compression scheme for depth and color transmission between the DRAM and texture cache which is a massive bandwidth optimization in the common case where a sample tile (usually 8x8, which for 4x MSAA corresponds to only 4x4 pixels) is covered by only one or two triangles.
The title is a bit misleading, this is boilerplate code for a graphics programming course and it hasn't got much to do with OpenGL. The articles describing the operation are much more interesting than the code itself. It's just an inefficient triangle rasterizer. All it does is loop over the pixels in a rectangle covering a triangle, and for each pixel inside it calls a "shader" function. All the beef is in these 40…
99% of programmers without graphics training would not come up with the barycentric coordinates solution when asked how to draw triangles (including me, before I learned about it). Even if the code were nothing but that, it'd be extremely educational.
The point of this course is obviously not to teach graphics gurus how mipmapping or anisotropy or whatever works. That would be an interesting series of lessons (albeit one with a much narrower audience), but it's not what this tutorial is about.
Nobody complains that showing absolute beginners their first "hello world" program isn't valuable because they aren't teaching them about Unix file descriptors or the concept of a syscall.
In particular, I'm very curious how tile-based deferred rendering wound interact (positively!) with a Vulkan software rendering implementation by keeping all tile buffers for a render pass in the on-chip cache of a modern Intel CPU. It seems like Vulkan provides a better API for a software rendering than OpenGL for that reason, and I'd like to see that confirmed one way or the other.