Good enough for starting out.

One thing to note is that usually a vertex and a vector have one element more than their dimensionality; a 2d item has 3 elements, a 3d item has 4 elements. This works out much better with the math, and it also simplifies the code.

Because of the way the matrix math works out a vector should have the extra element set to 0 and a point or vertex should have the extra element set to 1. When it goes through a transformation matrix, that value corresponds with the translation. Vectors do not have a location so by having a zero multiplied by the translation they don't move (which would change their magnitude) but they will still rotate, scale, and shear properly. A point does have a location, so having a one multiplied by the translation means it moves.

So for a 3D point: {x, y, z, 1}
and a 3D vector: {x, y, z, 0}

The end result is that you don't need to track points and vectors with different operations and different classes, you can use the same classes and the same math to work with both of them.

There is still a lot to learn and a bit of nuance missing from your post, but what you have there is basically correct.

Thank you.

I know certain bits are a bit rough along the edges, partly due to trying to cut down on some sections (even though it still resulted in a fairly massive post!), partly due to a current lack of knowledge.

What I do know is that writing this did give me a clearer understanding of how stuff works, and it cleared up some misconceptions I had, which should help me as I continue.

I also got some feedback via the chat, which I appreciate :)

To be more precise about "points": a vector can mean a direction or position, depending on how you interpret it(point vector / direction vector). A vertex is a point/edge of a model/primitive, and it can have a number of attributes like position, color, texture coordinates. Hence the GL function names with "vertexAttribute".

Objects which have had this transform applied to them are said to have normalized device coordinates.

After multiplied by the projection matrix they become "clip coordinates". After the perspective division, which happens automatically, they become NDCs.

Models that have the modelview transform applied to them are said to be in camera space or eye space.
Here, we can apply various shaders (on either the vertex level, pixel/fragment level or geometry level). Notably, this is where textures are actually applied to the object

This is a bit confusing.

I have a question. Have you ever modeled in a 3d program? Have you ever used a game engine (Particularly Unity3D).

Have you done any UV unwrapping or model texturing in a 3D modeling package?

Even though I don't know OpenGL nor DirectX, All of your above explanations I can figure out.

It would really help you if you learned about 3d modeling (which OpenGL renders anyhow) and this will help your understanding of OpenGL more.

As Aliii noted, your definitions do sound confusing, especially for someone who may not have done any 3d modeling or know anything about the way 3d models are rendered.

I do know that OpenGL is a graphics library that renders graphics, which you could actually program yourself. But it takes a lot to write a program that renders 3d graphics the way they are rendered today, so people would rather use such large libraries as OpenGL and DirectX to do it for them.

You should write your notes on what you are learning as if you were completely new to everything and needed baby steps to understand. That way if you ever quit all of this for a while, you will be able to simply read your notes and get back into it right away.

For instance, what normal person knows what "rasterize" means? And there are a lot of people who don't know what rendering a pixel to a screen looks like.

Things like that.

I am not sure but Shouldn't those be multiplies in your cheat sheet there rather then additions. I mean the transformation of a vertex from one coordinate space to another is done with a multiply between a matrix of one space by the matrix of another.

Such that for example:

(viewMat * modelMat * ObjectCoordinates) yields modelVeiwMat

and

(modelViewMat * ObjectCoordinates) yields EyeCoordinates

I think that your cheat sheet could be confusing. Also in your cheat sheet you might want to add the order that those multiplies should be done in because unlike regular multiplication, order here maters. (viewMat * modelMat * ObjectCoordinates) is not the same as (ObjectCoordinates * modelMat * viewMat). In opengl the order is from right to left because it is Column-Major.

Column-Major operator-on-the-left == Row-Major operator-on-the-right

so with (viewMat * modelMat * ObjectCoordinates):

first

(modelMat * ObjectCoordinates)

then

(viewMat * (modelMat * ObjectCoordinates))

If you could find a way to tidy that understanding up in your cheat sheet, that would be I think pretty awesome.

I think OP used + to mean "combined with" which is unfortunate since the operation of combining matrices is multiplication and not addition.

Multiplication order does matter, since A * B != B * A, which you correctly point out, this is because row major vs. column major means the matrices get transposed if you change row major to column major and vice versa. Note that transpose(A * B) = transpose(B) * transpose(A)

Your last part is wrong (EDIT: I probably mean "misleading" rather than wrong) though, A * B * C can be done in any order i.e. (A * B) * C = A * (B * C) since matrix multiplication is associative. Brackets are unnecessary for chained multiplications. (You still need brackets for distributivity though, A * (B + C) != (A * B) + C [in fact A * (B + C) = (A * B) + (A * C), just like distributivity of * over + for integers])

What you can't do is swap left/right multiplication operands, i.e. A * B * C != A * C * B. That is because B * C != C * B in general.

I think OP used + to mean "combined with" which is unfortunate since the operation of combining matrices is multiplication and not addition.

Correct. To be honest, I wasn't even intending to include the last part, and I was also mainly writing this for myself to serve as a sanity check more than a guide.

I'll reply more properly once I get back from work.

I have a question. Have you ever modeled in a 3d program? Have you ever used a game engine (Particularly Unity3D).

Have you done any UV unwrapping or model texturing in a 3D modeling package?

Even though I don't know OpenGL nor DirectX, All of your above explanations I can figure out.

It would really help you if you learned about 3d modeling (which OpenGL renders anyhow) and this will help your understanding of OpenGL more.

As Aliii noted, your definitions do sound confusing, especially for someone who may not have done any 3d modeling or know anything about the way 3d models are rendered.

I do know that OpenGL is a graphics library that renders graphics, which you could actually program yourself. But it takes a lot to write a program that renders 3d graphics the way they are rendered today, so people would rather use such large libraries as OpenGL and DirectX to do it for them.

You should write your notes on what you are learning as if you were completely new to everything and needed baby steps to understand. That way if you ever quit all of this for a while, you will be able to simply read your notes and get back into it right away.

For instance, what normal person knows what "rasterize" means? And there are a lot of people who don't know what rendering a pixel to a screen looks like.

Things like that.

I have done some very very basic modelling in 3D Studio Max some years ago. I would consider myself a novice at modelling, but I do have a decent-ish understanding of a lot of the concepts and processes involved.

I have dabbled in using Unity3D on my spare time, but I'm far from an expert on using it.

I work with game development, but we do not use a commercial engine. Nor do I do this kind of stuff -- I'm doing this as a home project, with a specific goal I'm working towards.

Based on your post and your name, I think you might have read this a tutorial for people who are brand new to the material. This wasn't the intent, although I can see benefits to such a tutorial or article being written.

I've seen some of your other posts advocating learning 3D. I don't necessarily disagree with it being helpful, but it's not where my current focus is, nor do I think it's what I'd gain the most from right now. I might be gloriously wrong, but for now learning 3D is not something I'll spend time on.

I should possibly also made it clearer what the intent of the thread was, and have more specific questions to make feedback easier. I'll definitely keep that in mind for future threads.

I'm reading up on this stuff on my own, while jotting down notes as I go along. At a certain point, I had some problems, which typing up the post helped solve/make clearer.

I posted this mainly as a sanity check, not expecting anything more detailed than frob's answer. That said, I should probably have done another pass on it to clean up some things, and to have a more consistent detail level throughout.

I think that your cheat sheet could be confusing. Also in your cheat sheet you might want to add the order that those multiplies should be done in because unlike regular multiplication, order here maters. (viewMat * modelMat * ObjectCoordinates) is not the same as (ObjectCoordinates * modelMat * viewMat). In opengl the order is from right to left because it is Column-Major.

...

If you could find a way to tidy that understanding up in your cheat sheet, that would be I think pretty awesome.

I wasn't originally planning on including the cheat sheet part. This is one of the things I should have done another pass over before posting.

Judging by some comments I've received various places, I think I'll do a pass over this tomorrow/this weekend, and try to clear up any confusing parts. I probably won't do any drastic changes, just update/correct the worst parts. Hopefully, that might make the post more relevant for other people struggling with the same issues I was.

I'll update the post now to clarify that I don't mean "mathematical addition" but "combined with" in the cheat sheet, though.

I appreciate the comments and feedback, both here in the thread, on the chat and other places.