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.
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.
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.
Thanks for the recommendation, I'll see if I can find a copy somewhere.
But I think the 12-yo-me wouldn't have bought a book and certainly wouldn't have appreciated one that starts with a linear algebra primer (no matter how well written).
Really, what I would've needed back then would've been a relatively short tutorial somewhere online, preferrably one that doesn't require me to start with linear algebra. Just the basic arithmetic I was familiar with back then. Maybe I will indeed have to try write one now some day.
Short enough that it would be easy for people to contribute translations. Indeed, a math heavy book in English would've been totally inappropriate.
I just had the Asphyxia Demotutorials (look them up on one of those oldskool textfiles websites, maybe it's exactly what you are referring to? except of course the bits were they also learn you Turbo Pascal and ASM :p) But the arithmetic, goniometry (trigonometry?) and geometry were the hard parts, which I learned in school, but were still tricky (because I liked learning, not memorizing formulas).
Linear algebra was the new and easy part. You don't need matrix inversions, eigenvectors or triangular decompositions or any of the complex Linear Algebra stuff. It's just vector math. And you probably already know arrays. It's merely a notational convenience when you recognize that you're doing the exact same operations on three x,y,z-variables all the time.
When I saw it first as a teenager I was like "hey that's clever, lots less to write!" (when working out formulas on pen and paper, not having to write everything thrice, yay!).
That sounds like a perfect way to satisfy my curiosity! I've been considering writing a software rasterizer for the fun of it. Thanks for the recommendation; I'll keep a look out for it too.
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 important to have a geomtrical intuition about the operations. This is another short tutorial that does a good job at conveying the geometrical aspects of linear algebra: http://www.cns.nyu.edu/~eero/NOTES/geomLinAlg.pdf
For those interested in learning LA in full detail, you can check out my upcoming book which covers all the essential material and discusses lots of applications, including the homogenous coordinates used in computer graphics: https://minireference.com/static/excerpts/noBSguide2LA_previ...
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.
The ePub and mobi versions are in the works (using softcover + polytexnic), but I'll need to tweak the build script some more. ETA July, but can be sooner if you there is popular demand...
You should do it! I agree and think that making 3D approachable is possible, and that most tutorials fail to make it easier than already available materials. I'm not sure it's easy to do, but if you succeed then people will benefit and if it turns out to be hard, you'll have developed a stronger appreciation for the problem and/or the motivation to solve it.
I remember doing something similar (ignoring matrix transforms and hand-calculating everything with trig because I wasn't comfortable with it). It works fine, and it's great for a theoretical understanding of how rasterization works. I like starting from the basics that way too, then building on it.
I think that most tutorials and such have a more practical focus though, with the goal of getting you to practical use of a 3D programming API (or at least skipping to the more-efficient combined transformations that matrices allow). I know that I found enough resources that covered the low-level view of things when I was teaching myself about this stuff, but I had to sift through a lot, and I ended up mostly dropping it.
Recently, I've been looking for info on doing UV mapping in software. That's pretty hard to find practical information on too.
Ignoring matrix transformations is easy, as long as the eye point is at the origin. Then yes, the algebra is almost trivial: projection is just divide-by-z. But the moment you move the camera, or stretch and turn objects, or worry about clipping, you need the full machinery that matrices provide. They're not that mysterious. I wish they were taught in high school, because they would motivate kids to learn graphics and programming.
Nope, you totally don't need matrices to rotate, scale, and translate stuff. It's all very simple addition, multiplication and a wee tiny bit of trigonometry. As trivial as the perspective divide. In a 3D renderer, this is among the simplest and most straightforward of things. You can take it step by step and each step should be pretty straightforward to explain and illustrate. That is what is needed to build intuition and dispel the magic. After that, matrices are just a convenient abstraction, and perhaps more importantly, a reasonable way to express your intent to the underlying graphics library or hardware. Which you don't necessarily want to use.
Agreed: moving, turning and stretching don't need matrices, to be understood. But moving the camera away from (0 0 0) is going to require a change of coordinates. I'm not sure how to explain that process in a simple way that avoids matrices.
> I wish they were taught in high school, because they would motivate kids to learn graphics and programming.
Learned Linear Algebra (matrix calculations and some analytical geometry) + Calculus in eleventh grade, around 1995. I think it was the standard curriculum in all Eastern Europe and the countries from the ex Soviet Union.
I learned some degree of linear algebra sometime during high school (in optional math classes that a lot of my schoolmates never reached), but mostly as a set of rote-learned operations without a connection to anything useful. As a consequence, I ended up re-learning a lot of it in university, and then catching up on it again on my own while learning about 3D graphics. (American, in high school during early 00's)
The math courses from my first university year where 90% a redo of the math from my last two years of high school. The difference was that in university they emphasized the theory over exercises, basically forced us to learn 1 - 2 hours demonstrations of some theorem.
I recently gave an internal tech talk at our company about just that, and my main goal was exactly that: no matrices whatsoever. Basic trig and points and lines on a canvas tag. Eventually, I switch over to OpenGL.
Video and audio quality aren't great, but you might enjoy it.
For those interested I found this book quite good:
"Linux 3-D Graphics Programming" [1]
That explains how to build a 3d engine almost from scratch and it does explain 2D math (cross product, etc) and also 3D stuff of course (matrix operations, perspective projection, etc).
It's a bit dense in that it pretty much builds everything from zero, but it's a very nice way to go through everything needed to work with 3D graphics.
You can check the content table in Amazon I think.
The second book "Advanced Linux 3D Graphics" is a bit less interesting for me since it talks a lot about Blender and other software which it doesn't really go with the theme of the first one, but there's still a lot of good info in there.
www.scratchapixel.com was exactly designed/created for that: teaching cg programming from the ground up with simple words assuming readers have 0 mathematical bg (well you still need to know what a + and - are and a few more things).
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.
> 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.
Oh, I'm not arguing against the utility of matrices. I just find that they were too abstract a concept for the young me to learn at the same time while trying to understand 3d graphics. They're an useful abstraction for when you know them, but if you don't, focusing on them is a good way to frustrate a young mind who just wants to understand 3d transformation and perspective projection.
Even if you read about matrices and vectors, it takes quite a bit longer to get comfortable with them and build intuition. Instead, with weak knowledge and lack of intuition (can you expect more from a young teen who had to try learn about these things himself on the net in a foreign language?), dressing the simple core of 3d computations in that language only serves as a barrier to understanding, and you have to work hard backwards to really understand what's happening "under the hood", below these abstractions. It's a bit much to comprehend, and I don't think it helps. It didn't help me for sure. And that ended up being incredibly frustrating, crushing even. It could just be that I am dumber than the lot of you?
If anything, it would've been better if someone could've shown how simple and intuitive the underlying arithmetic is, and then from there on go on to show how one can wrap things up with useful abstractions to combine later. This would give the motivation to learn the more abstract material, and straight away show how it is useful, applying it to things you know already. To me, that would make as much sense as learning to do arithmetic before learning about functions and solving equations.
And really, I wasn't that interested in using graphics hardware or some library. For me the point was in doing it all from scratch.
I think that matrices seem difficult because they are taught by teachers who don't know how they play a role in geometry. Even points and vectors can be hard if the teacher doesn't show how to connect their algebra and their geometry.
Example: a parametric line segment: P(t) = t * A + (1 - t) * B: If t is 0, you get A. If it's 1 you get B. If it's 0.5, you get halfway between A and B. If negative, you're 'before' A. If t > 1, you're 'beyond' B. Then it's easy to see that restricting t > 0 gives you a ray. The geometry matches the algebra nicely.
Example: in ray tracing, you have to test whether a ray intersects a sphere. This gives you a quadratic equation. If the equation has two real roots, the ray hits the sphere twice. If just one real root, it touches it once (one hit point: ray is tangent to sphere). If no real roots, the ray misses (no hit points). I love how the algebra and the geometry correspond so nicely.
Once you tell a student that applying a matrix will change an object's shape, it's easy to get them to see how applying two matrices means applying two shape changes. Then if you apply the changes in opposite order, you get a different matrix product, and a different final shape. Again, the algebra corresponds to the geometry. And you've just taught them about non-commutative multiplication!
And then I show them a translation matrix, and the inverse of the translation matrix (I don't teach them how to invert matrices; why bother them?). And I show them that the inverse makes sense: the translation amounts are the negatives of the original. And I show them that the product of those two matrices is the identity, which again matches the geometric fact: move, then un-move, is the same as doing nothing.
I talk about rotations using my body: I turn around the X axis, then the Y axis. The I repeat it in opposite order, and show that rotations usually don't commute.
What I'm trying to say is that matrices are confusing because teachers SUCK at explaining them. For the small subset of linear algebra that graphics needs, there are a lot of geometric intuitions that make it simple to explain the material.
You're right about that. Much of what I was taught when I studied CS involved learning by implication. We would be shown how to do something, and were supposed to figure everything out after seeing how that was done, while getting on with the next five things we were seeing demonstrated.
It was more like teaching a child to tie a shoelace and then assuming that he can work out how to tie all the different types of knots needed on a sailing ship than it was actually teaching.
We learned basic vector arithmetic back in highschool doing our own gamedev stuff, and it's pretty straightforward. The use of matrices as "mapping" one space to another likewise so.
Any approach that ignores the relevant parts of linear algebra, though, is probably going to collapse under its own weight as things get more complicated--experiencing that collapse may be interesting from a learning perspective, but I suspect it is not needed.
The real problem is that the useful parts of linear algebra--for graphics anyways--may never be seen before college, and even then they may be presented in the abstract form which prevents their utility from being realized.
Really, any 3D primer should just assume no familiarity with the subject, and then teach exactly those bits which are relevant to computer graphics.
This. You went to the right high school. Matrices and vectors are just a subset of linear algebra, and can definitely be taught to teenagers.
When I teach graphics to 3rd-year college undergraduates, I tell them "this is what all that point-and-vector stuff you learnt in high school was really meant for". They've usually forgotten it all, but it comes back to them quickly, and the matrix stuff on top of that isn't very hard, so I can get them up to speed pretty quickly.
Most CS degrees require linear algebra, which talks about vector spaces, gaussian elimination, diagonalization, rank, which is all useless for graphics! Too bad that course is usually relegated to the math department, which doesn't know how fun and useful a small subset of linear algebra is!
A minor clarification: the vector/matrix stuff we picked up outside of class by hanging out at Barnes & Nobles and reading books. :)
I was fortunate in college to have a professor teaching graphics (Ron Goldman) whose training was in differential geometry. So, graphics to him was a beautiful if trivial application of mathematics and linear algebra and he taught it as such.
I will always value his teaching of mass-point stuff as an approach, because it just is so nice in how it ends up.
What would be the "gain" of leaving out linear algebra and other mathematical concepts? Agreed, computers can do graphics using basic arithmetic, so can we humans. We get the stuff done without advanced concepts. I still disagree with the "[linear algebra and stuff being] useless for graphics" part. You may not require that knowledge to implement graphics-related stuff, but if you are seeking to develop methods in that field or reason about them in a way other people will understand, you naturally end up using the language of linear algebra. You could do without it, but it would be hard for others to follow you. It might be some other kind of language, but I'd say LA is pretty darn succinct.
Yes. I was able to make a Quake-like clone when I was 17 with no knowledge of how matrices worked or linear algebra. This was before Unity et al, so I had to build it from scratch. You can get surprisingly far by stringing magical utility functions together.
The reason I know those things now is because I wasn't forced to learn them then. Detail comes after engagement.
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 developed in the book. Written Peter Shirley, by a graphics prof. friend of mine, well known in graphics / ray tracing / global illumination circles.
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.
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:
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 :)).
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.
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.
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.
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.
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.
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.
Back in the mid 80s I rediscovered a form of Bresenham on PDP-11 assembler that used integer overflow to avoid branches. I've forgotten the details, but I remember that it was integer only, and used an accumulator word which, on overflow, became a small number (somehow triggering a change in the dependent coordinate). Damn I wish I could remember the details. One of these days I'll dig up the assembler specs and re-derive it.
Or maybe I'll discover I was using a branch after all!
The whole point of Bresenham is choosing between two integer values to minimize the accumulated error. You can totally implement any conditional computation without explicit conditional branch instructions e.g. using jump tables, conditional moves or predication etc. But the nature of your algorithm will remain conditional and a modern CPU still won't be able to process it as fast as a naive implementation.
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.
Our current CPU-based 2D vector graphics rendering pipelines are completely unmatched to modern hardware. They’re lumbering decades-old dinosaurs with poor render quality (full of nasty visual artifacts) and ridiculously slow speed compared to the possibilities on a GPU (or even compared to better-cache-optimized CPU algorithms, frankly).
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.
Sadly if you're actually implementing Bresenham's algorithm today you're doing something very wrong (or don't care about performance). Drawing lines and shapes is all a matter of pumping the desired geometry and shaders into your GPU today and letting it take care of the rasterization--running Bresenham's algorithm on your CPU will be many orders of magnitude slower.
No argument. That's why I said I realized this was always done for you today. But somebody had to build and program that GPU, and for those of us who care about such details, it would be nice to learn how rasterization works in a GPU. I had assumed that GPUs were still using Bresenham-like DDAs, but I learned from the above discussion that fixed-point non-branching algorithms may have become more common.
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).
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."
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 I liked this one because each lesson has a binary you can download and run on your computer (only tested on Mac).
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".
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.