On 8/2/2019 at 2:30 PM, DerTroll said: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. ?
Haha, yes, true story 
Changing "undocumented" code that was made by a guy who left the company 10 years ago, and nobody has a clue what he had in mind when he made it, and it works perfectly but the game designers want some new feature 
As a side note: I think a most of the time a well optimized code is not too pleasant to look at 
On 8/2/2019 at 2:30 PM, DerTroll said: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...
I do it a lot, eg: most of my collision code works better in the object's local space. Also in my vehicle simulation, some of the physics is calculated in the vehicle's local space, some forces act in the wheel's space, then again a whole bunch of things come from world space, so I transform them back and forth all the time
I suppose I could have been unified them into one space, but as well known equations and formulas are defined in a specific frame, and I wanted to understand the code 5-10 years later, I decided not to bother my tire formulas
On 8/3/2019 at 12:47 AM, alvaro said:So just define
R = R1 * R2
T = R2 * T1 + T2
Exactly this is how I do it.
On 8/3/2019 at 2:32 PM, alvaro said: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.
Transforming vertices with quaternions is not that optimal. https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation
They're compact in memory, then again when you have to calculate with them they can hit back
As @alvaro mentioned, it's good for animation data, and transforming a quaternion with an other is faster than matrix-matrix multiply.
On 8/3/2019 at 8:09 PM, 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 1Is row major, or column major?
I think we misunderstood each other, probably I expressed my idea in the wrong way 
The translation part is not that mysterious, I was thinking of, something let's say:
You debug some code, and look at the rotation matrix as 9 numbers, you'd see something similar in the debugger:
m[0] = [1, 0, 0]
m[1] = [0, 0, 1]
m[2] = [0, -1, 0]
or even worse:
m = [1, 0, 0, 0 , 0, 1, 0, -1, 0]
Is Y pointing down or forward?
Again, with my matrix represented as 3 vectors you'd see something:
m.x = [1, 0, 0]
m.y = [0, 0, 1]
m.z = [0, -1, 0]
No question here
No big deal, just a little convenience.
