@zipit said in The asymmetric matrix inversion issue:

Hi,

sure, shears are somewhat the unloved stepchild of transforms in Cinema. But I think just like for the handedness/orientation of transforms, it is important to point out that this only does kick in once applied to an object, because otherwise people will assume that Cinema is handling that for them and wonder what the heck is going wrong in their code.

I guess it depends on the point you want to make. I added this chapter to show that Cinema is not working with "pure" linear algebra, which can lead to possible strange transformations. The purpose is more or less that script programmers are aware that these things might happen, and that they should avoid certain things (like matrix-based asymmetric scaling) to prevent issues down the line.

Asymmetric scaling in the coordinates tab is dangerous anyway. I consider it a best practice to have the scale coordinates at 1-1-1 all the time unless you have a very good reason to transform local space.

I'm not doing the deeper math in the course anyway. For basic scripting, it suffices to use the provided matrix factories. If you want more, you'd have to take a complete linear algebra course with all the bells and whistles. (And you couldn't even completely apply it to C4D functions because C4D has some extra gatekeepers built in, like the auto-orthogonalization in SetMl() and SetMg().)

It's a fairly esoteric theme; I wasn't even aware of these issues before the topic was raised here on the forum. I just never encountered the situation - and I've been doing scripting/plugin programming since R8.

One could probably argue that this is a common approach, as you usually want to enforce an common orientation for your coordinates and most often also want your geometry to be defined in a sane way in relation to an orthonormal basis, but with this line of thinking you IMHO sooner or later venture into territories, where you consider "and here comes the tricky part" to be a sufficient explanation for even the most cryptic things.

This has, in fact, been a point I thought long and hard about. Do I start with the theoretical details, present the full math and programming theory, and then teach perfect mastery of software engineering? Or do I follow a hands-on approach which leads to working scripts early on, but leaves the "tricky parts" for later (or never...)? I decided in favor of the second method, which of course requires some extra though when it comes to the cryptic things (or it drops the cryptic things altogether until a participant explicitly runs into the issue and asks).

I suppose if we get more philosophical, we could question the way Cinema 4D handles matrices altogether. The root cause for the described issue is that C4D ~~does not support~~ explicitly avoids the shear transformation in its matrices to keep the coordinate system orthogonal as far as possible. At the same time it permits asymmetric scaling, with the known results.

We can imagine a 3D program that doesn't use matrix scaling *or* shearing at all - in which case all matrices would be invertible, and the inversion would always lead to a pure trans/rot matrix again, circumventing the issue (correct me if I'm wrong...). But maybe that is a rather severe restriction that leads to "missing feature" syndrome.

Or we can just allow a common scaling factor for all axes instead of separate x/y/z values. That makes it possible to scale objects or animations while still not encountering the shearing issue. (Scaling down to 0 would lead to non-invertible matrices, of course.) On the other hand, this is a property that the user can adhere to themselves by a little discipline.

Or we can allow shearing, implement the full range of linear algebra transformations, and thereby "complete" the feature set. (While we're at it, we can also encode the handed-ness of the coordinate system - having left- *and* right-handed coordinates would help a lot in rigging and animation.) Then again, this might confuse the user; while it's mathematically perfect and gets rid of all necessary exceptions, it introduces yet another level of complexity. Also, a deep understanding of that solution would force the user to study the math in much greater detail.

All solutions have their ups and downs. It's hypothetical anyway, as C4D will certainly not deviate from its most basic foundations