
Scratchapixel: Computer Graphics Programming from Scratch - MrHamdulay
http://scratchapixel.com/
======
clarry
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, and that to
rotate, you just use good old trig functions to generate rotated basis vectors
along which to plot your vertices (really easy to show with images and
animations too). And that magic perspective, to make things get smaller as
they get further from the camera, is just one divide by the depth away... yes,
all very basic arithmetic. And no need for magic such as homogeneous
coordinates. They're just a convenience for when you do things a certain way.

You don't need to go to college or even high school for 3D rasterization. But
most if not all texts pretty much want to assume such a background?

Actually, I'm quite tempted to try write such a tutorial for the 12-year-old
me. Too bad I can't travel back in time to see if I'd actually understand it
(but I have a strong feeling I could come up with something good enough).
Yeah, the lack of approachable material was very frustrating for me back then.
In the end I wrote a very primitive renderer (with plenty of trigonometry per
vertex) which was way too slow and complicated to be useful. Because I didn't
realize how simple the problem actually is.

~~~
lastofus
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 of print, and the APIs used are a bit
out of date at this point (Win32 and old DirectX used to set up a window w/ a
frame buffer ptr).

All the same, I would still highly recommend it to anyone who wants to
understand the foundations of 3D math and fixed function rendering pipelines.

~~~
arthurcolle
[http://portal.aauj.edu/portal_resources/downloads/programmin...](http://portal.aauj.edu/portal_resources/downloads/programming/windows_game_programming_guru.pdf)

~~~
justinclift
Seems to be the same author, but an earlier book?

~~~
lastofus
This is a PDF of the 1st edition of another book by the same author. There is
a 2nd edition, which is an excellent but outdated text covering 2D game
programming.

------
dahart
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...](http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-
weekend.html). 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 developed in
the book. Written Peter Shirley, by a graphics prof. friend of mine, well
known in graphics / ray tracing / global illumination circles.

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

------
TACIXAT
These are the other graphics related tutorials I have found.

Ray Tracing in a Weekend Series. Most the way through the first book and I
plan on continuing it. [1][2][3]

Tiny Renderer - How OpenGL Works. A software renderer in 500 lines of code.
Wiki has a full tutorial. [4]

The Book of Shaders. A step by step introduction into fragment shaders. [5]

[1]
[https://www.amazon.com/_/dp/B01B5AODD8](https://www.amazon.com/_/dp/B01B5AODD8)

[2]
[https://www.amazon.com/_/dp/B01CO7PQ8C](https://www.amazon.com/_/dp/B01CO7PQ8C)

[3]
[https://www.amazon.com/_/dp/B01DN58P8C](https://www.amazon.com/_/dp/B01DN58P8C)

[4]
[https://github.com/ssloy/tinyrenderer/wiki](https://github.com/ssloy/tinyrenderer/wiki)

[5] [https://thebookofshaders.com/](https://thebookofshaders.com/)

------
dreamcompiler
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.

~~~
pandaman
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.

~~~
userbinator
Actually, what's really replaced Bresenham is fixed-point. Dead-simple and
non-branchy code with less than a dozen instructions in the main loop.
Floating-point is still not exactly as fast as integer arithmetic:

[https://hbfs.wordpress.com/2009/07/28/faster-than-
bresenhams...](https://hbfs.wordpress.com/2009/07/28/faster-than-bresenhams-
algorithm/)

~~~
pandaman
Fixed point is a good approach for line drawing but doing a sqrt for circles
with integer arithmetics does not work really that well even if you don't know
how to convert floats to ints fast (like author of the article you linked :)).

~~~
clarry
This one shows the branchy and branchless variations of bresenham being nearly
equal in speed, within 5% on the older 32 bit CPU, with the branchy old school
way being 1% faster on a more recent 64 bit CPU.

 _Both are significantly faster than the naive floating point version._

That is in line with my experience that floating point can still be quite slow
on the CPU; the advantage from using fixed point isn't necessarily in avoiding
branches (though it usually helps), but in avoiding floating point computation
and conversion between floats & ints. Which is something something you have to
deal with as soon as you're addressing memory or trying to pack data e.g. in
video coding.

~~~
pandaman
Did you forget to add a link to your post or something? I repeat this for the
final time: floating point can be quite slow _but_ flow control is _much_
slower. Also, fixed point square root is _very slow_ compared to the FP one.

If you have a "brancheless bresenham" then go for it, I've never heard of such
a thing so I'd be curious to see that link. But from the description it sounds
like a contradiction to the Bresenham's idea.

~~~
clarry
See userbinator's link for a little performance comparison of the naive
floating point code vs. bresenham vs. fixed point.

~~~
pandaman
There are many problems with that link. First of all - there is no "branchless
bresenham" in it. Second - the author, while noticing that float to int
conversion in his compiler is slow, decided not to do anything about it
instead of doing a simple google search to find how to do it fast enough.
Third - he is using 8087 FP instructions, which had been deprecated since late
90s. Fourth - he is essentially measuring function call (look what's happening
in his inner loop). And fifth - he is not measuring other Bresenham's
algorithms. I'd love to see how he does ellipses with fixed point.

------
amelius
I was surprised this starts at 3D graphics, and completely skips important 2D
techniques, such as drawing/shading lines and polygons (which are also useful
for doing 3D stuff).

------
kowdermeister
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...](https://www.kirupa.com/html5/animating_with_easing_functions_in_javascript.htm)

------
ivan_ah
Wow this is an awesome online book. Goes into a lot of details, and uses words
to convey the important things + supports it with code.

Another good tutorial, more specific to OpenGL, is this one:
[http://www.songho.ca/opengl/index.html](http://www.songho.ca/opengl/index.html)
I liked this one because each lesson has a binary you can download and run on
your computer (only tested on Mac).

~~~
Narishma
I wouldn't recommend that one. It teaches the old deprecated fixed function
OpenGL.

------
dahart
Anyone know who's behind the site? I looked around, but all I found was a FAQ
on the older version of the site that asks the question and doesn't answer,
aside from "VFX professionals".

