Live data from Hacker News

Scratchapixel: Computer Graphics Programming from Scratch

scratchapixel.com

31–40 of 73 posts

Re: Scratchapixel: Computer Graphics Programming from Scratch

#31
post #16

Earlier quoted context omitted.

Speaking of short tutorials on linear algebra, you should check out this one I wrote last year. It's more of a "prepare for an exam" document, but it gets to the core idea of matrix-vector product serving as a way to "implement" linear transformations: https://minireference.com/static/tutorials/linear_algebra_in... I'm personally fine with using the computer as a "magic box" to do all the calculations, but it's impor…

I skimmed through the book preview, and it looks very nice. Though I already have a few books on LA, I wouldn't mind having yours on my bookshelf too... any ETA on when it's available for purchase? Actually I'm planning to quit my job and go study mathematics starting next semester (if I can afford it...) so it might come in handy.

The editor is doing a final pass through it this summer, so the first print version will be ready for August. But, when I say August, it probably means September ;)

The eBook version has been ready for a while now, and it gets constantly updated. I can also print you a one-off copy of the current version if you need it sooner.

Re: Scratchapixel: Computer Graphics Programming from Scratch

#32

Maybe I missed it, but I didn't see any discussion of the Bresenham family of algorithms. I realize this is always done for you nowadays, but if you're really teaching pixels from scratch, it seems like drawing lines and circles from raw pixels needs to be covered.

Bresenham algorithms replaced expensive (at the time) floating point computation with fast (at the time) flow control. Nowadays it's exactly opposite: float is cheap and control is expensive so they only have historical value.

We're still doing plenty of graphics on the CPU. For many applications, I'd prefer that it stay that way. And it doesn't seem like CPUs are becoming massively parallel anytime soon.

Re: Scratchapixel: Computer Graphics Programming from Scratch

#33
post #32

Earlier quoted context omitted.

Bresenham algorithms replaced expensive (at the time) floating point computation with fast (at the time) flow control. Nowadays it's exactly opposite: float is cheap and control is expensive so they only have historical value.

We're still doing plenty of graphics on the CPU. For many applications, I'd prefer that it stay that way. And it doesn't seem like CPUs are becoming massively parallel anytime soon.

The CPUs still had been doing floating point math much faster than flow control for the past 20 years or so.

Re: Scratchapixel: Computer Graphics Programming from Scratch

#34
post #32

Earlier quoted context omitted.

We're still doing plenty of graphics on the CPU. For many applications, I'd prefer that it stay that way. And it doesn't seem like CPUs are becoming massively parallel anytime soon.

The CPUs still had been doing floating point math much faster than flow control for the past 20 years or so.

Can you point me to relevant examples of line drawing or related things (e.g. triangle or polygon filling) that is faster to do in floating point (which may eventually need to convert to integer for addressing) than the old school way? Besides, it's not like the line drawing needs much in the control flow aside from a bit of setup and then a loop. Which you'll need with floating point too.

And if you're e.g. filling a triangle? Going the barycentric way, you have a relatively speaking big amount of floating point operations per pixel, in addition to the loop, plus some initial setup. And you might have to compare signs...

I don't believe it's faster. But I'm open to being shown wrong.

Re: Scratchapixel: Computer Graphics Programming from Scratch

#35
post #34

Earlier quoted context omitted.

The CPUs still had been doing floating point math much faster than flow control for the past 20 years or so.

Can you point me to relevant examples of line drawing or related things (e.g. triangle or polygon filling) that is faster to do in floating point (which may eventually need to convert to integer for addressing) than the old school way? Besides, it's not like the line drawing needs much in the control flow aside from a bit of setup and then a loop. Which you'll need with floating point too. And if you're e.g. filling…

Sure, go find a Bresenham line drawing first, verify that it does flow control for every step (a pixel) then compare it to the naive implementation (y = kx + a). Loops are not as expensive as what Bresenham does since even the simple branch prediction works fine for them and there are even better ways the CPU can deal with a loop on newer CPUs. Bresenham's switch is inherently unpredictable since it's comparing accumulated errors.

Re: Scratchapixel: Computer Graphics Programming from Scratch

#36
I give them a big kudos for adding lots of illustrations, it's vital to have good visual representation for math concepts.

> Evaluating the curve's equation for values of tt going from 0 to 1, is sort of the same as walking along the curve. It is important to understand that tt is a scalar but that the result of the equation for any tt contained in the range [0:1] is a position in 3D space (for 3D curves, and obviously a 2D point for 2D curves). In other words, if we need to visualise a parametric curve, all we have to do is to evaluate the curve's equation for increasing values of tt at some regular positions (it doesn't have to be though), and connecting the resulting positions in space to create a polygonal path (as illustrated in figure 5).

Unfortunately this is the language that you should avoid if you want to explain these concepts for beginners. Too technical, too rigid, too dry. I sort of understand what it says, but it could be done in much simpler way. I'd put it this way:

"We have a function that describes the bezier curve. If you call that function with the P1-4 parameters you will receive X,Y (or Z if you do 3D) coordinates that you can easily plot and connect with straight lines. You also need to specify how many segments you want to receive, this will be resolution of the curve."

Or something like this. Better explained ( betterexplained.com/calculus/ ) does a good job at this and I recently recently rediscovered Kirupa, I love his tutorials: https://www.kirupa.com/html5/animating_with_easing_functions...

Re: Scratchapixel: Computer Graphics Programming from Scratch

#37
post #6

What I don't get is why nearly all resources on 3D graphics assume the reader is familiar with matrices and linear algebra. For those who don't speak that language, what you're doing is plotting numbers into a magic box, doing a magic multiply, and hey presto, we got 3D! Magic. Meanwhile a teenager could easily get an intuitive grasp of 3D graphics if you just explained how translation is nothing besides addition, an…

What you are wanting is this book: "Tricks of the 3D Game Programming Gurus" by Andre LaMothe. The book teaches you how to write a 3D software rasterizer from first principles. The first part of the book is nothing but a well written linear algebra primer. The book then assumes you have nothing but a C++ compiler and a pointer to the frame buffer like you might get using SDL. Unfortunately the book appears to be out…

Another tutorial from first principles. https://github.com/ssloy/tinyrenderer/wiki

Re: Scratchapixel: Computer Graphics Programming from Scratch

#38
post #5

Earlier quoted context omitted.

Fair enough.

99% of the computer graphics you see on your screen everyday are made of simple lines, circles, curves, and text in 2D. 3D is useful mostly for games, movies, and CAD software. I don't understand this over focus on 3D. I think the latest edition of "Computer Graphics: principles and practice" does not even teach bresenham anymore. This seems wrong to me.

I'm only arguing for fun, and because I love 3d graphics, don't take this personally. I'm upvoting your comment to offset my argumentative reply. :)

You say 'games and movies' like those are niche markets. You can't watch any TV without seeing 3d graphics. And chances are you see a lot more 3d on your computer than you think while you work. Windows, Mac OSX, & Linux all have 3d hardware accelerated windowing features for task switching, virtual desktops, and lots of other fun tidbits. Plus, you might not be playing enough games, if you play games less than 1% of your time.

I'm not sure who's over focused on 3d, but it'd be pretty weird to put together a site like scratchapixel.com without 3d.

Finally, Bresenham's algorithm has historical significance, but is no longer generally useful, even for line drawing. Maybe if it's gone from CGP&P, that's a clue? Aliased, single pixel wide lines are almost never used. If you want soft edges or thick lines or curves or texture, you're a lot better off focusing on polygons from the start.

Re: Scratchapixel: Computer Graphics Programming from Scratch

#39
post #6

What I don't get is why nearly all resources on 3D graphics assume the reader is familiar with matrices and linear algebra. For those who don't speak that language, what you're doing is plotting numbers into a magic box, doing a magic multiply, and hey presto, we got 3D! Magic. Meanwhile a teenager could easily get an intuitive grasp of 3D graphics if you just explained how translation is nothing besides addition, an…

The reason that 4x4 matrices are used so much in graphics is their versatility: you can use them to implement modeling (placing an object into the world), viewing (changing a world point into camera coords), projection and clipping (putting a camera-coord point into clipping coords), color transformations (after all, both x,y,z,w and r,g,b,a are coordinates of a 4D point). That's why there's matrix multipliers built into all graphics hardware.

I understand where you're coming from: translating a point is just 3 additions, so why do a full matrix x point multiply? Scaling is just 3 multiplies, and so on. But if you've got a hardware matrix-point multiplier, all those transformations cost the same, so you're not saving time by devoting special code to each kind of transformation.

Moreover, you don't have to learn full linear algebra: to do graphics, you don't have to know how to invert a matrix, nor solve a system of linear equations, nor diagonalize a matrix. Graphics just needs a tiny subset of linear algebra.

When I teach graphics, I describe points, vectors, lines, circles, matrix-point multiplication, and matrix-matrix multiplication. It takes maybe two lectures, and it provides tools for lots of other parts of the graphics pipeline.

Once you have those tools, you can talk about the viewing transformation (just a special matrix), composite transformations (matrix-matrix multiplication), hierarchical objects (more matrix-matrix multiplication), projection (another special matrix), color transformations (another special matrix).

I also find that when describing ray tracing, you need to talk about going from (row col) pixel coordinates to a 3D point in space, where the ray starts. That's partly the INVERSE view transformation, and (yay) it's just a matrix.

When I was a wee lad in 1981 I did indeed try what you suggest: I worked out the algebra of projection, knowing just where the image plane was (using some points and vectors), and where the world point was. This give me an image point. I was very proud to be able to squeeze this into 50 opcodes on a TI-57 calculator. But when I became a man, and put away childish things, I saw that matrices describe the same process much more cleanly and simply. I wish I had known about them much earlier.

Hell, I wish high school math taught some points and vectors, and some simple matrix operations as I described above (not full-blown linear algebra). Then, they could use those tools to make pictures starting from just numerical descriptions of shapes! It would give many kids more enthusiasm for mathematics, and would start them on the way towards operators, groups, linear spaces, and all those things they might see later. All we would have to do is get education departments to teach the math teachers all this stuff. It would be exhilarating for everyone involved.

Re: Scratchapixel: Computer Graphics Programming from Scratch

#40
post #9

This is a great resource! For those interested in a very quick and direct intro to writing code for ray tracing, something I think supplements Scratchapixel nicely, you might want to also check out "Ray Tracing in One Weekend". http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-we... . It's a $3 ebook on Amazon, but the blog post has lots of free resources including the complete code for the small ray tracer d…

I didn't know Peter Shirley wrote more books! "Realistic Ray Tracing" was definitely a good introductory book back in the day.
Post reply on HN