The algorithm behind "transform" component

Hi all,

I pass a transformation matrix to the "transform" component in order to visualize the transformed result. However, the matrix I used is simply an estimated transformation matrix, which its rotation matrix does not obey the property of a real one. It inverse does not equal to its transpose, and its determinant is not equal to 1.

Does anyone know what is the algorithm or mechanism behind the "transform" component so that it could auto-correct the matrix and output a valid matrix from the estimated one?

Thanks in advance.

estimated transformation matrix:

auto-corrected transformation matrix:

Best,

Jacky

Replies to This Discussion

Permalink Reply by David Rutten on November 1, 2016 at 9:55am

I think almost all matrices are valid. Certainly there is no requirement that rotation must be correct. If rotation factors are incorrect you end up with a shear transform rather than a rotate transform.

Can you upload the file which shows how a matrix gets 'fixed'?

Permalink Reply by Jacky Tsang on November 2, 2016 at 1:18am

Hi David,

Please allow me to describe the situation clearer. I have a transformation matrix deduced from linear least squares, which is the one so-called "estimated transformation matrix". That is the reason why the matrix does not obey any property of a real transformation matrix. It is meant to be a rigid transformation(rotation + translation).

I passed that matrix to the "transform" component, hoping to get a visualization and it does.

Then, I use the transformed geometry to get the "fixed" transformation matrix using "orient" component. screenshot and grasshopper file are attached below.

I wonder how the "transform" component could, somehow, correct the matrix from "estimated" to "fixed".

Best,

Jacky

Attachments:

correct_matrix.gh, 12 KB

Permalink Reply by David Rutten on November 2, 2016 at 1:54am

I'm on an iPad now and can't check the file, but if you're transforming planes, then I expect only the translation and rotation to survive. Plane axes are always perpendicular and unitized, so any shearing or scaling will be removed. I can look at the code later today to figure out how planes are transformed. I suspect the x-axis is transformed correctly but the y-axis is adjusted after the fact to ensure perpendicularity with x.

Permalink Reply by Jacky Tsang on November 2, 2016 at 10:02am

Hi Tom,

I haven't read everything you listed in detail, but, at a first glance, I don't think it is what I am looking for. quaternion is just another representation when we describe a transformation in 3d space. How does it relate to the "correction" process? How could it convert the estimated matrix to one that represents a rigid transformation?

What do you mean by "math primer"? (I am not a native English speaker)

I will definitely read the OpenGL tutorial eight times. ^_^ and the faq is really something.

Best,

Jacky

Permalink Reply by ng5 Alex on November 2, 2016 at 9:50am