4 hours ago, bmarci said:

Row vs column major! It always confuses me if I see a matrix and don't know which 3 numbers represent a certain direction.
For me it's much more clear if I see a vector component in a transformation and I instantly know that points up in local space 

Unless you're talking about 1-d indexing, I think you mean row vs column vector. The question of where certain transform elements (e.g. up vector, translation vector) are in a mathematically notated matrix is a question of row vs column vectors, not row- vs column-major. If you were looking at matrix data in a 1-d array, you'd need to know both the majorness and the vector notation convention to identify the different transform components, but it seems like you're talking about a 2-d representation here (although I could be wrong about that).

In any case, row vs column vectors refers to (as you seem to know) whether vectors are rows or columns (including in certain types of transform matrices, conceptually speaking), while row- vs column-major has to do with how matrix data is stored in memory. Maybe you already know all this, but I'm just mentioning it because what you've been discussing sounds more like vector notation convention than majorness. Maybe we're just miscommunicating though.

3 hours ago, bmarci said:

But most of the cases, even in AAA games, we had everything in 4x4 matrices because the sacred GPU likes that way, and the game code looked like a mess. Full with matrix decompose and inverses. But at least the engine/render guys could blame the game coders because the overall bad performance

In my experience, if code looks like a mess it is usually because there was no effort put into optimizations. The reason for that might be time restrictions. But often, especially if mathematics and physics are involved, people just don't know enough about the things they are dealing with. They just keep trying until it works and then they don't touch it anymore because they fear it might stop working. ?

Also, if you need to "undo" transformations a lot, I would also put some effort into optimizing my transformation orders. The only "inverse" transformation I see a lot is the inverse-transpose to adjust the normals. In my opinion, this is also unnecessary, since you can calculate the normal matrix during the calculation of the model-world matrix with minimal effort. But that's another story...

4 hours ago, bmarci said:

Somehow it works for me, and exactly that's what I'm doing with my rotate + translate combo, and before I pass it to the render I pack them into a 4x4 matrix. 

I think you got me wrong what I meant with stacking. If you have more than one transformation sequence which includes rotations and translation and don't need the intermediate space after the first sequence, then you can combine both sequences in one matrix by just multiplying 2 4x4 matrices only once on the CPU. So you have to multiply your vertices by only a single matrix to get to the final destination. You can't do that with 3x3 matrixes. You always need to do something like this:

Final = R2 * (R1 * vert + T1) + T2

So you have to store 2 rotation matrices and 2 translation vectors and apply them to every single vertex. Therefore, you have to manage more data (even if you pack stuff in 4x4 matrices) and more computational effort when compared to a single 4x4 multiplication. Also, the code gets more bloated.

4 hours ago, bmarci said:

Yes, but why would I keep a copy if I can have everything at hand? 

 

Usually, I don't store the copy but the actual inverse that I need. I just meant you don't need to keep everything separated just because you might want to do some inverse transformations.

4 hours ago, bmarci said:

With a pure 4x4 rotation matrix half of the operations will be multiplying numbers by zeros and adding them together.

You are right, that it is sometimes beneficial to use just 3x3 matrices if a 4x4 matrix doesn't give you any benefit. The best example is the normal-transformation matrix since normals need no translations. However, the performance gain is not as high as you might expect since vectorization gives you a lot of the necessary additional operations (really) for free. Usually, the small performance gain of 3x3 matrices is not relevant when compared to the savings of "stacking" multiple transformations in a single 4x4 matrix.

4 hours ago, bmarci said:

As I saw in the past, the performance doesn't always depend on the 2x faster low level function. I try to keep everything as simple as possible, that always helped me in the valley of darkness

As I said, if you don't need maximal performance for your game, it is totally fine to use whatever suits your needs. However, I have a different opinion on some things you mentioned. If you don't want to bother with the mathematical details of matrix operations, I can understand that. But I have to disagree that using 3x3 matrices produces less messy code or has any real advantage over 4x4 matrices. YMMV

Greetings.

With 3x3 matrices and translations you can provide a composition operator just fine;

R2 * (R1 * vert + T1) + T2 = (R1 * R2) * vert + (R2 * T1 + T2)

So just define

R = R1 * R2

T = R2 * T1 + T2

So "stacking" works perfectly well with 3x3 matrices.

You can also use quaternions and translations, if the only 3x3 transformations you will use are rotations.

11 hours ago, alvaro said:

With 3x3 matrices and translations you can provide a composition operator just fine;

R2 * (R1 * vert + T1) + T2 = (R1 * R2) * vert + (R2 * T1 + T2)

So just define

R = R1 * R2

T = R2 * T1 + T2

 

So "stacking" works perfectly well with 3x3 matrices.

You are right. Obviously, I am too stupid for simple math ?. So forget the things I said about the performance. If you use this approach you should be a tiny bit faster for each Vertex. However, calculating the composition is significantly cheaper. Probably just 70-80% of the 4x4 multiplication if I look at the involved SSE operations. Have to benchmark that...

However, learned something. Thanks for that @alvaro ?

11 hours ago, alvaro said:

You can also use quaternions and translations, if the only 3x3 transformations you will use are rotations.

I have not benchmarked it myself since I haven't fully implemented quaternions yet, but isn't quaternion-vector multiplication significantly slower than matrix-vector multiplication? Or do you mean, to use quaternions just for the composition and then transform it to a 3x3?

Greetings

I haven't timed any of this, so I don't know about speed. Quaternions are very compact in memory (which matters for animation data) and are very easy to normalize. But if you have a lot of vertices to transform, it's possible 3x3 matrices are a better choice.

On 8/2/2019 at 2:35 AM, bmarci said:

Row vs column major! It always confuses me if I see a matrix and don't know which 3 numbers represent a certain direction.

I thought of a way we might be able to resolve the confusion. Would you say this translation matrix:

1 0 0 tx
0 1 0 ty
0 0 1 tz
0 0 0 1

Is row major, or column major?

4 hours ago, Zakwayda said:

I thought of a way we might be able to resolve the confusion. Would you say this translation matrix:

1 0 0 tx
0 1 0 ty
0 0 1 tz
0 0 0 1

Is row major, or column major?

It depends on how it's stored in memory. 

37 minutes ago, alvaro said:

It depends on how it's stored in memory. 

Hi alvaro,

I think you may have missed the context in which I asked this question (perfectly understandable). I think if you were to read my previous exchanges with the OP, it would become clear.

The point of the question is to demonstrate exactly what you state - that majorness relates to layout in memory and not vector notation. In fact, I said exactly that earlier in the thread, as quoted below:

Quote

In any case, row vs column vectors refers to (as you seem to know) whether vectors are rows or columns (including in certain types of transform matrices, conceptually speaking), while row- vs column-major has to do with how matrix data is stored in memory.

My suspicion (and there's some ambiguity here, so I'm not certain either way) is that the OP is using the terms row/column major when he means to refer to row/column vector notation. The question you quoted was intended to resolve the confusion in that the OP's answer could indicate whether the terms are being used correctly or not.

Hope that clears things up.

Oops, in my last post, when I said OP I actually meant bmarci (who isn't the OP). Unfortunately I can't edit it now.

Yes, I did skip a lot of this thread and I thought you were asking a real question. Sorry about that.