Computer Graphics from Scratch | Hacker News Reader

Computer Graphics from Scratch

gabrielgambetta.com

805 pointsAlexeyBrin116 comments

A long time ago, due to an improbable sequence of events, I found myself teaching Computer Graphics at my alma mater, a year after I took the class myself. Over the following five years or so, my approach to the subject evolved, and I really got the hang of it. After I stopped teaching, I took my notes, handouts and slides, and made them into a series of articles that I put on my website, where they remained in relative obscurity. Hacker News managed to find it every once in a while, and it was generally well received, but nothing came out of this. Until April 2019. It made the HN front page again [0], except this time it caught the attention of an editor in No Starch Press [1].

Long story short, today I’m incredibly grateful and excited to tell you that CGFS is coming out as a real book, with pages and all [2]. The folks at NSP graciously agreed to let me publish the updated contents, the product of almost two years of hard editing and proofreading work, for free on my website [3]. But if you’d like to preorder the printed or ebook version, you can use the coupon code MAKE3DMAGIC to get a 35% discount at https://nostarch.com/computer-graphics-scratch.

I’m still somewhat in disbelief that my work is getting published as a book, and this genuinely wouldn’t have happened without your support. So once again, THANK YOU :)

[0] https://news.ycombinator.com/item?id=19584921

[1] http://nostarch.com

[2] https://nostarch.com/computer-graphics-scratch

[3] http://gabrielgambetta.com/computer-graphics-from-scratch

Awesome! Thanks for sharing!

This looks great. I have been developing interest in CG recently and this looks like a great way to start. Thank you.

And finding your Imdb profile was a nice addition on top ;)

All the best.

Thanks! For better or worse, I'm interested in a lot of different things

I'm always in the market for great graphics books, and NSP is my favorite publisher, so excited to get this. Thanks for the coupon!

You're welcome! I have to say they're also amazing to work with :) Special thanks to Alex and Kassie <3

That's great to hear!

This is awesome, but as a kid back in the Pong era, I always wondered how the basic squares of pixels worked. In your travels writing this book, did you ever come across one that explained that in a way friendly to 12 year olds?

Pong uses discrete logic gates and no microprocessor for its game logic and graphics. It isn't comparable to much else.

I was dismayed to learn that pixels are not square at all. It got worse with the switch to LCD.

Interesting, didn't know that. What shape are they, then? Round? Or other?

Can you be specific of the context you are interested in?

On modern machines, a pixel is just a set of three numbers indicating how much red, blue and green light should be shown at a particular point. Ex: {0.75 red, 0.0 blue, 0.5 green} for a kinda-dark, orange pixel. The GPU keeps a big 2D grid of these number-triples in memory and on a regular schedule sends out a copy over the DVI cable to your monitor. The monitor has a bit of memory to hold it's copy. And, it has hardware to scan over the grid of numbers to produce a sequence of voltage levels that are used to change the color of the points on the LCD.

There's a bit of math involved in how to do a good job representing colors with numbers and how to convert those numbers to voltages. But, at the most basic level, an image is just a big 2D grid of numbers. If you want to change the image, poke the grid. People want to change images a whole lot. So, we've developed pretty sophisticated hardware and software around poking 2D grid... But, that's a whole other topic.

I was a 12 year old when I learned about them :)

The idea of a pixel is that it's the smallest area of the screen that can be independently controlled, thus the designation "pixel" for "picture element".

In most modern phone screens or monitors, each pixel is formed by a group of three smaller elements with fixed colors (usually red, green, and blue) but _variable brightness_. By controlling the brightness of these sub-elements, we can control what the overall color of the pixel appears to be - once you get more than an inch or two away from the screen, the light from the element group blends into what we see as a single color - so 100% green + 100% red + 0% blue looks like bright yellow. 50% each for red, green, and blue looks like a middling grey. You can usually see the structure of the pixel with a magnifying glass, though this is easier with an old TV or monitor than a modern phone.

These pixels are laid out on a regular rectangular grid, and your display controller will offer some way to set the color of each pixel and to then update them all at some (usually) regular interval, for example 60 times per second. In computers, it's common to keep a "frame buffer" around that stores separate values for the red, green, and blue components of every pixel on the screen. If these are 8-bit values, that implies that each R/G/B component can have 256 different levels of brightness, and in combination they allow each pixel to take on one of about 16,000,000 possible colors. So, a program can change pixel colors by writing different values into this buffer and waiting for the updated buffer to be processed by the display controller to change what the display is showing.

Of course, the electronics, physics, chemistry, timing, and logic of display generation have changed quite a bit since Pong. And not all displays even have pixels - vector displays used to be a thing, and are still used in some very specialized applications.

I appreciate the explanation, but it's not for me. I'm trying to find a good book to recommend to my grandkids. I've had fun teaching them how to use old retro computers (c64, Apple II, and such). It's been a fun experience, but I'd like to give them some references that aren't me! I've personally come a long way in my computing skills since I was staring at shiny new Pong screens :)

Thinking of when I was 12 (2005?), microscopes and magnifying glasses helped me understand. Depends on device DPI (cell phones have an insane number of pixels per inch; desktop screens are usually less dense).

If you can zoom in enough to see subpixel elements, and pull up a color wheel, it's very intuitive to see that the screen is made of pixels, and the pixels are made of three elements.

https://en.wikipedia.org/wiki/RGB_color_model#/media/File:Ad...

The Pico-8 might be a approachable way to explore retrocomputing. It's an in-browser console modelled after GameBoy-era consoles.

https://news.ycombinator.com/item?id=18240375

I don't know about books, though. I remember reading the binary/computers chapter of How Things Work and being thoroughly confused at that age. There was some extended allegory about white mammoths and black mammoths.

Did you have The Way Things Work or The New Way Things Work? I had the latter around the same time. I thought the extended computer section (Bill's Gates!) was very helpful. I still really like the visual in which the image of a mammoth is turned into a series of pumpkin/no pumpkin signals being launched through the air, then becomes a picture of a mammoth on the other side of the field. I think it got a bit too technical for me when it started showing how transistors are constructed-- I guess I should've stuck with the pumpkins.

Now I have both editions and have looked through them side-by-side. It's a bit unfortunate that some pages were dropped to make room for the expanded digital section in the newer edition, but well worth the trade-off for more/better explanations in the digital realm.

I'm not sure. Possibly both?

Just took a look over my bookshelf, but they haven't made it with me through moves.

I do still have Incredible Cross-Sections. That was another of my favorites to flip through. It looks like there are reprints and new versions. Would definitely recommend for kids.

https://www.amazon.com/Stephen-Biestys-Incredible-Cross-Sect...

That's trickier - somewhere along the way I stopped buying books and just do tactical forays onto the net when I need a new bit of domain knowledge.

Details like how and why pixels work are much easier to understand and retain if they're in some kind of context. Gamers learn about pixels to better understand the games or their gear. Devs learn about them in order to control them. Artists learn about them to better understand why computers mangle their art. So maybe choose an area the grandkids are engaged with and look for something there that also touches on display tech.

If they're interested in retro computers, you can always try finding some books from the 1980's. Many titles were written for children. The Apple II was also a fun playground for computer graphics since it was supported in BASIC.

https://www.youtube.com/watch?v=Tfh0ytz8S0k - C64

https://www.youtube.com/watch?v=niKblgZupOc - PC CGA

https://www.youtube.com/watch?v=_rsycfDliZU - Apple and Atari

https://www.youtube.com/watch?v=mpNWEbZdXNw - GBA

Graphics was somewhat more complicated back in the day. In the days before we had enough memory to hold a full screen framebuffer, there was a lot of magic going on with cathode ray tubes, video signals, dedicated hardware sprite engines, memory access clock cycles, using interrupt handling to "race the beam" and so on.

It's not like modern display panels and HDMI signals and digital protocols are simple, but you don't have to go into the details to understand how pixels and framebuffers work.

If you're trying to explain how pixels work, going back to 1980s era technology is a detour into arcane technical details that aren't really relevant any more. They're pretty cool to read about if you're into retro computer technology but they don't have much educational value or relevance to the modern day.

I once bought a schematic for a DIY pong. IIRC it used monostables and integrators to control timings -- scan frequencies yes but no strict pixels needed.

To some extent, I guess that's what I've tried to do here. The linear algebra might be too advanced for a 12 year old (I didn't pick it up until much later!), but on the other hand you don't need to follow all the derivations - a 12 year old can learn a lot just by following the results and the resulting algorithms.

There's also a linear algebra appendix [0] that presents the operations, explains how to use them, and how they can be interpreted, without going in any theoretical depth about why these things are the way they are.

[0] https://gabrielgambetta.com/computer-graphics-from-scratch/A...

Graphics programming in C by Roger T Stevens chapters 9-12.

> due to an improbable sequence of events

is that why you ended up working for improbable? ;)

That was a semi-intentional pun, good catch ;)

You're not far off the mark, though! It was my other series of articles about client-side prediction [0] that brought me to Improbable's attention :)

[0] https://gabrielgambetta.com/client-server-game-architecture....

excellent articles, i quoted them in my bachelor thesis some time ago :)

How has your approach changed?

At first I mostly followed the lecture structure of the previous professor, but over the years I streamlined it a lot, emphasized a "motivated" approach to each topic (e.g. "last chapter we did this, now we try to do this thing, it doesn't quite work, how can we fix it?"), and generally refined and simplified the explanations of everything. Teaching the same material year after year was a fantastic opportunity to identify the recurring sticking points and finding ways around them.

Hey Gabe – great work and huge congrats!

I'm sure you don't remember me, but we used to work together at Improbable – you sent me such a wonderful email when I left to go back to Sweden, thank you!

Anyway, just wanted to say congrats and hope you're doing great buddy. All the best! :o)

Of course I remember you! Could never forget such an impeccably dressed coworker :) I think we were super close to meeting in Miami that one time I had a long layover?

Aww – thank you! <3

That's right, I was in Florida visiting family. Would love to reconnect, don't hesitate to ping me an email at marcus@madebystade.com if the feeling is mutual! :o)

If I were you, I'd edit that email, there are spambots crawling everywhere :)

It's ok, my spam filter seems to do its job (knock on wood!) Either way I'm past the edit time limit now anyway..

What matters is I got the opportunity to reconnect with an old pal, I'll gladly pay the spam tax if it comes to that. Worst case scenario I guess I'm getting a new email address eventually. :o)

Good tip though, thanks!

I love this resource, thank you!

My favorite chapters are those about drawing raster lines and triangles. One of my first programs was writing (in 386 16-bit asm) the routine to draw a triangle, and I love these algorithms dearly.

An important and beautiful thing that is missing in the book is the drawing of anti-aliased lines (easy) and triangles (not trivial!). I find that rendering carefully shaded smooth objects with a pixelized boundary loses a big part of the magic.

Yep, good point. The reason is that the objective of the book is to cover as much material as possible, in the shortest time possible, and in the simplest way possible; so I had to build the shortest path between putPixel() and filtered textures, and that leaves things like antialiasing behind.

I explain a bit of this in the introduction, most of the time I present not the best/fastest algorithm, but the one that it's the simplest to understand. For example, I don't even mention Bresenham's algorithm; instead I present a super simple but inefficient one, which achieves two critical things: (1) you're drawing lines in no time, (2) it motivates the linear interpolation method that is then used for shading, z-buffering and texturing.

Congratulations! It's a wonderful resource, and great to see it make it's way into library-form.

This is awesome. You should be proud!

Thank you! Right now it's 1:13am here and I'm proud, overwhelmed by the reaction, still in disbelief,... good luck sleeping tonight XD

I've wanted to learn this for a while, and never got around to it.

I think this is the final kick I needed, so thanks!

Great news! Please make sure the links to demos work for a while or you have some archival/preservation in mind. I've read through older technical books whose examples went offline and depending on the subject matter it can be quite a loss.

Congrats on this book! I did a computer graphics class for my undergraduate and we used this fat OpenGL book bible to try and implement some functions.

Things got very hard with ray tracing and later u,v texture mapping, etc. Making a note here so I can try your book out sometime!

What's the difference between the ebook and the one free one in the website?

one costs money

The contents are the same; the formatting, presentation, accessibility, etc, are much better in the ebook (an ebook isn't just a printed website).

I wanted to learn about rendering and graphics for a while.

Almost every modern source however uses engines or big frameworks and skips the parts I actually want to look into. Compiling a reading list or figuring things out myself of course would have been an option, but I guess others can relate to the problem of having too little time for hobby projects :)

Big bonus points also for trying to remain programming language agnostic! I immediately preordered your book and find it hard to express my excitement, can't wait.

Way back in the day I read either the 1st or 2nd edition of this book: https://www.amazon.com/Computer-Graphics-Principles-Practice...

It's a classic in the computer graphics field, like Knuth is for algorithms. I'd recommend it alongside the OP's new book.

EDIT: But for anyone who is reading this wanting to learn about practical computer graphics, CG:P&P is NOT the resource to use! Learning the low-level rasterization algorithms used in computer graphics is an important thing to learn at some point, just like learning assembly language provides valuable insights even if you never touch a line of assembler again. But if you actually want to write graphics code on modern hardware with GPUs, I'd highly recommend Real Time Rendering instead: https://www.amazon.com/Real-Time-Rendering-Fourth-Tomas-Aken...

Thanks a lot for the recommendation!

What would you say are the prerequisites for this one?

Also from the description it sounds as if it also goes a bit more into 2D graphics too, is that correct?

Again, I read an ancient edition which predated the existence of consumer GPUs. But the edition I read was more than half on the topic of 2D graphics and what you might consider to be mundane things like font rasterization.

You might think this has nothing to do with 3D graphics, but in fact there is a big overlap. The graphics driver + GPU takes a description of a 3D scene and projects it into 2D primitives whichs are rasterized onto a bitmap (the display) just as one might render a font glyph.

So IIRC the book begins with the basic theory and techniques of 2D graphics, and then shows how projective geometry can be used to render 3D scenes onto 2D displays, and progressively adds various corrections which we take for granted, such as perspective-correct interpolation of texture values, which these days is done automatically by the hardware.

I don't think there's any pre-requisites other than a basic understanding of beginner computer science, coding, and algorithms. If you can read Knuth, you can read CG:P&P.

Also, see my edit to the grandparent comment.

Congrats on getting your book published! I will definitely be ordering a copy :)

Congratulations on getting published, I have been looking for a book like this.

Hi Gabriel, is there a European site from which we can order? The delivery costs from the US are quite punchy, and it makes no sense to send the paper copy when a printer could do as good a job locally. Too many paper-miles? Looking forward to getting hold of it, great work! Mike

Hi Mike! I have nothing to do with distribution, but the book is also available from Amazon [0], B&N [1], Bookshop [2], and Penguin [3], maybe one of these has better shipping to Europe?

[0] https://www.amazon.com/Computer-Graphics-Scratch-Gabriel-Gam...

[1] https://www.barnesandnoble.com/w/computer-graphics-from-scra...

[2] https://bookshop.org/books/computer-graphics-from-scratch/97...

[3] https://www.penguinrandomhouse.com/books/645952/computer-gra...

Hey, thanks for this. I did go on to find it on Amazon.co.uk, but of course the e-book + paper-book bundle is different. I'll check out the other sites as well. Thanks again.

Thanks for keeping the material free online!

This is one of the few tutorials that covers raster rendering. Lots of introductory material on ray-tracing, not a lot on raster graphics.

Where can students look for more stuff on rasterization after they finish this book?

Coincidentally, just last night I was reading an issue of Byte magazine from 1976. It was telling people how to do just this: Computer graphics from scratch.

Except, back then "from scratch" meant soldering together wires and transistors and such.

The big prize was displaying a vector Starship Enterprise on an oscilloscope.

Wow, that sounds pretty hardcore! I suppose what's considered "from scratch" evolves over time. I'm old enough to have written bytes to 0xA000 (and the pain of doing page-switching in VESA modes), so even this "putPixel() on a canvas" is not exactly "from scratch" from that perspective!

This had a sizeable thread two months ago: https://news.ycombinator.com/item?id=25266812

Also 2019: https://news.ycombinator.com/item?id=19584921

and a bit here: https://news.ycombinator.com/item?id=19096322

The 2019 thread is what led No Starch Press to contact me in the first place, so I'm very grateful to the HN community :) Keep up the incredible work, dang!

It's super gratifying when feedback loops that end up producing real-world benefits pass through HN threads. I love hearing about those. Congratulations on the book. To judge by HN's consistent interest in this material, it must be awesome.

Nice.

There are several ways to approach this subject. This is a bottom-up approach - how do we get pixels on screen?

Other approaches start from "how do we represent a scene", in the sense of a scene graph or at least lists of vertices, triangle indices, and textures. That cuts the problem into "represent scene" and "render scene". That's a practical division, because that's the interface between what you put into a renderer and what the renderer does with it. Today, you're either using someone else's rendering system, or you're building the rendering system. Probably not both, except as an exercise.

This division is actually a bit above the OpenGL/Vulkan level. Vulkan is complicated because it's mostly about setting up the GPU to run a rendering pipeline, talk to displays, and other housekeeping. And memory management. If you have a library to manage that part, it's not so bad.

It's like old computer books, where you started out learning what the arithmetic/logic unit (the ALU) did, how it interacted with memory, what the instruction decoder did, and so on. This prepared you for assembly language programming. Few courses start out there today.

Incidentally, the caption for figure 12-1 is missing some symbols. It reads "Using instead of doesn’t produce the results we expect."

Thanks for bringing up the issue with the caption. This is a bug in my own pipeline to convert the book to website format; it looks just fine in the book itself. It should read "Using DrawFilledTriangle instead of DrawWireframeTriangle doesn't produce the results we expect." Will fix.

I have to say this looks really cool.

Maybe this is a really dumb question, but as someone who really knows nothing about computer graphics, how can you actually run these examples?

I realize that I could Google and research and find a list of "canvas drawing tools" in a variety of languages that I could then evaluate (despite, again, knowing nothing about graphics), but it'd be SUPER-SUPER-awesome to have a quick note "there are lots of ways to go about making these things happen in the real world, but here's one I recommend if you have no other priors." :-)

Really cool book idea, keen to have a go at it!

HTML5 Canvas is probably the easiest to get going with some Javascript.

Python has PyGame, or you could just plot to PNGs.

Java awt has a canvas.

C/C++ has SDL/SFML or also plotting to PNGs (or if you want to go wild, embedded GPUs are an option).

You could also do all of this in BASIC if you write the canvas commands. All of this is doable on a Commodore in software albeit slowly.

The demos run live in the browser. You can download and edit them. The code is pretty straightforward and well commented.

Wow thank you! I totally missed the "Source code and live demo" button during my first cursory glance through the chapters, but indeed, there it is. :-)

Here's one of the demos, running right inside your browser: https://gabrielgambetta.com/computer-graphics-from-scratch/d... If you right-click-view-source, you can see the whole JavaScript implementation right there.

This might be the easiest way - make a trivial HTML page with a <canvas> tag and start setting pixel colors in it :)

CG fundamentals was my favourite course in college. Going from drawing lines with the Bresenham algorithm to drawing polygons, filling polygons with Scanline, implementing ZBuffer, texture mapping and so on. Was a lot of fun even though I never ended up working with CG except for some hobby projects.

Agreed, its one of those areas of software that just feels like magic when you code it from scratch and end up with a 3D object on your screen.

Especially raytracing! What I used to do when teaching was taking a few weeks to develop the rasterizer, and then say "OK, 4 weeks to go, time to present your final project - you're making this <image of a raytraced scene with reflections and shadows>, which I'm going to explain within the next 2 hours". Some groups genuinely thought I was joking. But then every one of them managed to write a raytracer, their minds were blown, and they used their renders as desktop backgrounds. I loved that :)

This looks really great!

I'd also highly recommend Ray Tracing in One Weekend[1], which starts you out with literally just a c++ program to dump bytes into a file which can be opened with most standard image/document viewers. Then you don't have to think about or set up any shaders before you can start to experiment with the rendering algorithms.

[1] https://raytracing.github.io/books/RayTracingInOneWeekend.ht...

Edit: formatting.

I've only had a quick glance but this book looks fantastic, saved for later reading and will definitely consider buying the ebook.

I've been teaching myself 3D/CG programming in my spare time using free web resources, I've been trying to learn it "the hard way" by doing everything relatively from scratch, instead of using a high-level engine I'm using low-level libraries writing my own shaders and implementing my own scene graph etc. This book really seems right up my alley and looks like it'll teach me a lot.

For anyone else similarly interested in learning to do CG from scratch (particularly on the web), some other great resources I've found are: https://thebookofshaders.com/ https://webglfundamentals.org/

Excellent resource! I really like the fact that everything is centred around the idea of just a single 'PutPixel' function. Makes things much more approachable.

I've took the liberty of rewriting the 'Perspective projection' demo (1) in more up-to-date Javascript, using ES6 classes and all the other niceties that modern browsers have. I also used the regular canvas line drawing methods to focus on just the vertex-to-line conversion, and updated the code so that it will work on any resolution. https://codepen.io/hay/pen/gOLazpm

1: https://gabrielgambetta.com/computer-graphics-from-scratch/d...

> "The choice of axes is arbitrary, so we’ll pick something useful for our purposes. We’ll say that Y is up and X and Z are horizontal, and all three axes are perpendicular to each other. Think of the plane XZ as the “floor,” while XY and YZ are vertical “walls” in a square room."

As someone who works with CAD/CNC machines on a daily basis, this is torment. XY is the floor and XZ, YZ are "walls". Same would go for a 3d printer. They're not that arbitrary.

Y up is very common in computer graphic. As for CAD, I know at least Solidworks have the option to use Y up.

I think the choice of 3D up axis is related to the expected look direction. 3D printer control software evolved from CNC control software, which is looked at from top down, so up is on the build plate plane. Video game commonly looked at from the side, so up is up. Up is then often associated with Y.

And then there the argument about right hand vs left hand coord system...

Computer graphics basically follows what math describes (x,y,z) or what is on the screen or blackboard. On the screen, x-axis is left and right; y-axis is up and down. When z-axis was introduced, it just came in and out of the screen. The convention is negative z values goes into the screen and positive z values out of the screen.

I break the negative-Z convention in the book. The math and the diagrams feel a lot more natural to me if Z goes into the screen. I suppose negative-Z comes from measuring Z as "distance from the screen to me", but then you have a bunch of weird negative values in the equations.

Left-handed vs right-handed coordinate systems. I prefer right-handed, but for some reason most of computer graphics seem to have adopted left-handed.

That was the opposite of fun when I was noodling with writing an OpenGL-based rendering engine for a "fly a spaceship around a 3D maze" game, decade and a half ago.

As to why I prefer right-handed? The lin-alg textbook I had at uni uses a right-handed coordinate system for what it calls "the perceivable room" (yes, it is "the book with the cow on", for those in the know).

Sorry about that :) In CG and gamedev I've seen "Y is up" a lot more, to the extent that the "depth buffer" is usually called the "Z buffer".

I don't know how this came to be. You make a very good point that XY as the floor makes a lot of sense, especially if you're coming from the context of "I'm drawing a floorplan on a horizontal table" - the floorplan matches the orientation of the actual floor so XY is the most natural choice.

I suppose for a similar reason CG adopted the "XY is a wall" convention, since you start with XY on the screen (a vertical plane in front of you) and only later add depth?

I can see how using Z as the depth axis for the 2d coordinate system of the screen is a natural way to go for a programmer. Maybe I can lay my monitor flat on a glass desk and lay on the floor ;-)

I've been reading the book and enjoying it so far. Thank you.

> I don't know how this came to be.

The numbers on touch-tone phones (as opposed to rotary-dial kids) and the numbers on computer keyboard number pads are reversed:

    1 2 3
    4 5 6
    7 8 9

    7 8 9
    4 5 6
    1 2 3

Why? No one knows...

When you get to game networking Gaffer On Games is a must read. Efficient game networking layers are all about that UDP [2] and reliable UDP [3]. When web games were huge it would have been pure gold to have WebRTC with built in UDP, NAT/punchthrough etc.

[1] https://gafferongames.com/

[2] https://gafferongames.com/post/reliability_ordering_and_cong...

[3] https://gafferongames.com/post/reliable_ordered_messages/

I also wrote about client-side prediction and server reconciliation [0], I suppose you're referencing that; but just to be clear, this book is just about graphics, and has nothing to do with that (other than the fact that multiplayer games generally have graphics)

[0] https://gabrielgambetta.com/client-server-game-architecture....

I was just saying to people interested in games, it is good to get a base level to advanced guide to every part including rendering, networking, gameplay etc that is a good source built from experience and explains things clearly. Yours looks like a great source for networking as well, thanks for adding it.

I see you reference Gaffer on Games and the Valve Latency Compensation article, both are great for understanding game networking and helped me greatly in shipped titles especially prior to Unity/Unreal using stuff like enet [2]/RakNet [3]/custom. Lots of networking libs inherited the best from those like reliable UDP, channels and dealing with NAT. Both are excellent libraries to help understand the full picture and get started. Lots of game engines networking libs are based on those.

[1] https://developer.valvesoftware.com/wiki/Latency_Compensatin...

[2] http://enet.bespin.org/

[3] http://www.jenkinssoftware.com/ + https://github.com/facebookarchive/RakNet

Another great resource for learning about multiplayer game networking is this guide from Mikola Lysenko: https://0fps.net/2014/02/10/replication-in-networked-games-o...

And of course there's also this monumental work: https://www.amazon.com/Development-Deployment-Multiplayer-On...

Instant buy. This is so awesome. I was just looking into this subject, so this comes at a perfect time for me. Thank you for the coupon :)

I got a good chuckle out of your technical reviewer: "Alejandro currently works in the GPU Software group at a leading consumer electronics com- pany based in Cupertino, California." I wonder where he works? ;)

I can't confirm nor deny what you're implying.

One of the things that I really like about this course is that it teaches both raytracing and rasterization. Usually, computer graphics tutorials are either the practical, higher-level, rasterization-focused kind (oftentimes around half "how do opengl"), or how the business card raytracer works.

Having a single course written by a single person that presents both major rendering techniques is amazing.

Crikey. I had to do a breesnam line drawing and hidden surface removal at Polytechnic back in the late 80s.

Thanks for the kind words! But I have to say the business card raytracer is amazing <3

Half-space rasterization[1] is a neat alternative to the classic scan-line renderer.

[1]: https://web.archive.org/web/20120212184251/http://devmaster....

Yeah I find this method way easier to understand than scan conversion. Fabian Giesen has a great series of articles from 2011 that explains it well[0].

Also the original 1988 paper by Pineda is a surprisingly easy read, and it's only 4 pages![1]

[0]: https://fgiesen.wordpress.com/2011/07/06/a-trip-through-the-...

[1]: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.15...

Rendering (forward or backward) of algebraic curves (like bezier and nurbs) never gets mentioned in any such collections, despite being essential to any 2D or GUI framework. And if they are, then only as a short: Just subdivide / tessellate it and then put it through the polygon pipeline! However there are far better ways to handle them, which even people in CG seem to be oblivious of.

And of course not to forget all the other approaches to modeling geometry like implicit surfaces, meta-balls, signed distance fields, constructive solid geometry, point clouds, splats, voxels, etc ...

Curves I had to leave out, as many other things. I explained my motivations in this other comment: https://news.ycombinator.com/item?id=26020311

Constructive solid geometry I do mention as an extension to the raytracer [0], but it doesn't have a dedicated chapter. Perhaps for the 2nd Edition? :P

[0] https://gabrielgambetta.com/computer-graphics-from-scratch/0...

> there are far better ways to handle them

I did some research a year ago. Found a few alternatives, yet none of them was good enough. Here's the issues I remember.

1. It's complicated. Cubic segments can self-intersect or contain singularities.

2. Stroked curves are used a lot. To build stroke edges from the curve, need to offset the curve by half width of the stroke. When you offset a polyline you gonna get another polyline. Yet the offset of Bezier splines is not generally representable as another Bezier spline.

3. In some use cases, hardware-implemented MSAA is the best way of AA. Polygon pipeline gives you that for free. Producing SV_Coverage in pixel shaders to achieve same effect for mid.points of triangle is hard and inefficient.

4. Games have been pushing GPUs for high polygon count for couple decades now, GPUs became really good at that. Also GPUs have early Z rejection that drops pixels or even larger blocks before pixel shader stage. You can't have that if you sending large primitives and computing curves in pixel shaders. Polygon pipeline is not necessarily slower.

I remember as a kid in the 80s trying to do simple things like draw diagonal lines.... painful.... then wanting to draw a circle. That was even more painful. My dad was a physicist and taught me the math needed.... I can remember watching with awe as my circles render slowly. Fun times. I was super impressed when I saw programs draw circles quickly. Now, it's all trivial! But I'm sure many would be lost if the only thing they could do is set a single pixel!

> Now, it's all trivial

It stops being trivial if you want these circles to look nice and render fast.

Take a look: https://github.com/Const-me/Vrmac#vector-graphics-engine

Drawing diagonal lines as a kid in the 80s is exactly how I started :) My very first program (or at least the first one I have evidence of) was about drawing a bunch of lines on a ZX Spectrum [0]. I should make one of these "how it started / how it's going" things.

https://gabrielgambetta.com/computer-graphics-from-scratch/d...

I studied "Computer Graphics" as an elective subject for my Electrical Engineering degree. It was taught by one of the the maths lecturers I think. (Peter Castle at University of Wollongong, maybe 1984). I do remember him playing I guess a VHS of some scenes of what was state of the art, Star Trek Wrath of Khan, I think). Any way it certainly got me interested in ray tracing and DKBtrace and PoVray later.

You had me at "rendering a Swiss landscape" 8-) Seriously, this looks like very good material for my own learning or to bootstrap a graphathon.

I have a reasonably clear view of the Uetliberg from my kitchen window, so of course I'm biased :)

Hey thanks for the book as well as the discount code. Quick question, do you think this will be beneficial to me if say I want to write a server side charting library?

Hmmm, probably not. The book doesn't really go much into drawing 2D shapes - just the minimum necessary to be able to draw filled triangles, at which point it jumps into 3D stuff.

If you like the idea, I highly recommend taking a look at "3d math primer for graphics and game development" which is a pretty easy read as well.

Are there exercises / recommended programming assignments for the book? I didn’t see any when I was just skimming. Thanks.

There's no exercises per se, but the whole book is one big programming assignment (or rather, two) - you build a raytracer and a rasterizer by the end of it.

this approach seems quite similar to the one taken by jamis-buck in “the raytracer challenge” (from pragmatic).

if you have not checked it out yet, try it. it is quite enjoyable.

Will take a look, thanks!

Thank you for sharing.

Weirdly, programming this stuff not from scratch can be harder if you use the apis that will utilize the GPU like vulkan or modern opengl.

I understand that Vulcan adds a lot of complexity, but OpenGL and Direct3D are surprisingly finite. Once you learn the graphics pipeline, it’s not too hard to begin drawing things. Init window and device, fill vertex and index buffers, load textures, load vertex and pixel shaders, set each of these things as the active thing, draw. Of course you can also explore the extents of all these entities until the sun engulfs earth. Even though I’ve been at it for 30 years, I realized long ago I would never keep up with, learn, and implement every notable technique even if I did nothing else for the rest of my life. But drawing nice looking, animated 3D things is very tractable.

This is true, but DirectX 11, Metal and modern OpenGL (without cutting edge extensions) are still very accessible to novices, not to mention that you can transfer knowledge between the three of them, so there's little cost in learning a second/third API.

Vulkan and DX12 however are the work of the devil.

Vulkan is soulless, like uefi: all functions have more-or-less the same interface. But I wouldn't say it's the work of the devil. Its greatest sin is boilerplate.

I had the same perspective on this. I spent some time building up a 2d graphics library from zero, primarily for drawing very simple UIs on resource-constrained devices.

I initially tried using D3D/Win32 APIs to perform the high-level drawing operations for me, but found that for the scope of functionality that I required, these interfaces were far too heavy-handed. These also have lots of platform-specific requirements and mountains of arcane frustrations to fight off.

I didn't need to interface with some complex geometry or shader pipeline in hardware. Raytracing is hilariously out of scope. I really just needed a dead simple way to draw basic primitives to a 2d array of RGB bytes and then get that to the display device as quickly as possible. What I ended up with is something that isnt capable of very much, but can run on any platform and without a dedicated GPU. I also feel like this was a much better learning experience than if I had slammed my head into the D3D/opengl/et. al. wall.

OpenGL is really not that much of a wall. I recommend giving it a try.

Reply on news.ycombinator.com