[HN Gopher] Computer Graphics from Scratch
___________________________________________________________________
Computer Graphics from Scratch
Author : AlexeyBrin
Score : 316 points
Date : 2021-02-03 18:21 UTC (4 hours ago)
(HTM) web link (gabrielgambetta.com)
(TXT) w3m dump (gabrielgambetta.com)
| Geminidog wrote:
| 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.
| psyc wrote:
| 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.
| ratww wrote:
| 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.
| moonchild wrote:
| 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.
| bob1029 wrote:
| 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.
| whatshisface wrote:
| OpenGL is really not that much of a wall. I recommend giving
| it a try.
| Lichtso wrote:
| 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 ...
| jtanderson wrote:
| 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.
| huskyr wrote:
| 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...
| kayoone wrote:
| 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.
| arduinomancer wrote:
| 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.
| genpfault wrote:
| Half-space rasterization[1] is a neat alternative to the classic
| scan-line renderer.
|
| [1]:
| https://web.archive.org/web/20120212184251/http://devmaster....
| news_to_me wrote:
| 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...
| bstahlhood wrote:
| 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? ;)
| ggambetta wrote:
| I can't confirm nor deny what you're implying.
| seism wrote:
| 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.
| Animats wrote:
| 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."
| dang wrote:
| 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
| ggambetta wrote:
| 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!
| ggambetta wrote:
| 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
| kayoone wrote:
| > due to an improbable sequence of events
|
| is that why you ended up working for improbable? ;)
| ggambetta wrote:
| 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....
| trilinearnz wrote:
| Congratulations! It's a wonderful resource, and great to see it
| make it's way into library-form.
| mstade wrote:
| 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)
| ggambetta wrote:
| 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?
| mstade wrote:
| 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)
| sriram_sun wrote:
| Awesome! Thanks for sharing!
| gauku wrote:
| 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.
| ggambetta wrote:
| Thanks! For better or worse, I'm interested in a lot of
| different things
| adamnemecek wrote:
| How has your approach changed?
| breck wrote:
| 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!
| ggambetta wrote:
| You're welcome! I have to say they're also amazing to work
| with :) Special thanks to Alex and Kassie <3
| enriquto wrote:
| 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.
| ggambetta wrote:
| 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.
| aperrien wrote:
| 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?
| foobarian wrote:
| I was dismayed to learn that pixels are not square at all. It
| got worse with the switch to LCD.
| corysama wrote:
| 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.
| kevin_thibedeau wrote:
| Pong uses discrete logic gates and no microprocessor for its
| game logic and graphics. It isn't comparable to much else.
| ggambetta wrote:
| 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...
| gamacodre wrote:
| 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.
| aperrien wrote:
| 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 :)
| gamacodre wrote:
| 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.
| TimBurr wrote:
| 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.
| wilsonfiifi wrote:
| 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?
| fouric wrote:
| 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.
| OnlyMortal wrote:
| Crikey. I had to do a breesnam line drawing and hidden surface
| removal at _Polytechnic_ back in the late 80s.
| reaperducer wrote:
| 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.
___________________________________________________________________
(page generated 2021-02-03 23:00 UTC)