Forums Technical Discussion VEX - maketransform() vs. invert().

VEX - maketransform() vs. invert().

   1539   11   0
User Avatar
viklc
Member
143 posts
Joined: 5月 2017
Offline
 
Hello everyone,

this question relates to the performance usage of the Inverse Matrix function in VEX, compared to others.

As an example, I have an object that is mapped in the @P attribute. I want to join the object, I call it "Child", with a matrix "Parent" by a multiplication, so that Child is transformed together with the parent matrix:

#include "math.h"
 
// Parent xform components.
vector t = chv("t");
vector r = chv("r");
vector s = chv("s");
 
// Create a matrix from the parent components.
matrix M = maketransform(XFORM_SRT, XFORM_XYZ, t, r, s);
 
// Pair child (P) with parent (M).
@P *= M;

Now, if I want to make specific changes to the child, I have to detach it from its parent, manipulate it and reattach it again. VEX offers several ways to do so. I'm just asking which one is more efficient.

One of them is to make an inverse matrix by using the function maketransform:
// Inverted parent matrix M.
matrix M_inv = maketransform(XFORM_TRS, XFORM_ZYX, -t, -r, s);
 
// Get child out of parent.
@P *= M_inv;

Or even more comfortable directly via the invert function. The advantage here is that no additional information about the order of the transformation must be given. But as far as I know an algorithm is used here, which takes possibly more performance to the above variant.
@P *= invert(M);

Such things are not clear and rarely available in the documentation.
 Report
User Avatar
tamte
Member
8525 posts
Joined: 7月 2007
Offline
 
I don't think there will be any substantial performance hit between them

I always use invert() as its not common to pass trs around once you are dealing with matrices

vik_lc
But as far as I know an algorithm is used here, which takes possibly more performance to the above variant.
maketransform() still uses "algorithm" to compute the matrix, it can't just stash trs values so there is some math happening for both of them

if you are concerned about the speed, make node for both versions and run it on insane amount of points with unique transform each, take average of at least 10 measurements and you may start getting an idea which one may be marginally faster, but for every day production it will be negligible, especially if your usecase is small amount of "objects" as opposed to 100mil points
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
User Avatar
BabaJ
Member
2036 posts
Joined: 9月 2015
Offline
 
vik_lc
But as far as I know an algorithm is used here, which takes possibly more performance to the above variant.

Just applying the opposite values like you have with making M_inv.

But with M_inv you're having to do the extra step of creating the new variable and assigning it the defined value.

Now, the question is how much more compile time is that really taking vs. what you think might be actual more computation time from the internal 'alogrithm' of the invert() function.

I suspect the differences whatever they may be is so small that one might as well consider it irrelevent, since what you call the algorithm of the invert() function is doing the same as what you did 'manually'.

What would make a difference is if you have both M and M_inv attributes carrying forward downstream as you now have more memory being utilized to keep both attributes.

Aside from that, if you really want to know if there is a difference you're going to have to set up a test file in which you have many many single threaded operations in series doing it one way or the other to see how much of a difference it ends up being.

I don't think such information that compares how one decides to use the existing code belongs in documentation - the variations of what to compare is enormous.
Edited by BabaJ - 2023年4月12日 12:47:58
 Report
User Avatar
viklc
Member
143 posts
Joined: 5月 2017
Offline
 
Hi Tomas and BabaJ,

tamte
maketransform() still uses "algorithm" to compute the matrix, it can't just stash trs values so there is some math happening for both of them
I thought that due to the parameters passed to maketransform(), the computational effort is lower compared to invert(). After all, invert() itself comes up with the order, if it is relevant at all for the algorithm used.

But yes, I think it's common to use the invert() function, since the other one is actually for initialization.

I will do some performance monitoring. But I don't have much experience with it. I think this is a good opportunity now. As soon as I have results, I'll show them here.


BabaJ
I don't think such information that compares how one decides to use the existing code belongs in documentation - the variations of what to compare is enormous.
You're definitely right about that, and it was not intended as a complaint about Side FX, I think if it were really relevant it would be mentioned. But then again, you never know, even less how the function is actually defined.

I'll stick with invert() for now.


Thanks.
 Report
User Avatar
animatrix_
Member
4495 posts
Joined: 2月 2012
Offline
 
One thing to note about maketransform is that you need to know the transform and rotate order to be able to construct the matrix properly. For example if you obtained an arbitrary transform matrix, you wouldn't necessarily know the transform and rotate order. For instance the transform matrix created by the Bound SOP.

If you don't have this info, then you can't effectively use maketransform or cracktransform. The results might be wrong if you just assume default order.

The same issue exist for Extract Transform SOP. It compiles with the transformation order expected by the Copy SOP.

So for inverting a transform matrix, maketransform is far less useful. Speed would be the least of your concerns compared to all that you have to account and keep track of.
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]

youtube.com/@pragmaticvfx | patreon.com/animatrix | animatrix2k7.gumroad.com
 Report
User Avatar
viklc
Member
143 posts
Joined: 5月 2017
Offline
 
Hi animatrix,

animatrix_
For example if you obtained an arbitrary transform matrix, you wouldn't necessarily know the transform and rotate order. For instance the transform matrix created by the Bound SOP.

This is a good point. Since it can occur that there are many different objects with different transformation order, it would be impossible to solve it manually. This makes the invert() function even more useful and special in that way.

Thanks.
 Report
User Avatar
tamte
Member
8525 posts
Joined: 7月 2007
Offline
 
For this purpose transform order doesn't matter once you have the matrix

So even if the matrix was created using different transform and rotation order per object, you can cracktransform+maketransfrorm to get to the inverse matrix
But there is really no point doing it especially since I doubt that even maketransfrorm alone would be faster than simple invert()
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
User Avatar
animatrix_
Member
4495 posts
Joined: 2月 2012
Offline
 
tamte
For this purpose transform order doesn't matter once you have the matrix

So even if the matrix was created using different transform and rotation order per object, you can cracktransform+maketransfrorm to get to the inverse matrix
But there is really no point doing it especially since I doubt that even maketransfrorm alone would be faster than simple invert()

If you have an arbitrary matrix, the order matters. For example if you crack transform the matrix created by the Bound SOP, you will get different results.

You can test it yourself. Just inverting the same matrix:

matrix m = detail ( 0, "xform" );
@P *= invert ( m );

If you construct the same matrix by cracking it:

matrix m = detail ( 0, "xform" );

vector t = cracktransform ( 0, 0, 0, 0, m );
vector r = cracktransform ( 0, 0, 1, 0, m );

matrix m2 = maketransform ( 0, 0, t, r, 1, 0 );
@P *= invert ( m2 );

This will work because the order is likely XYZ for rotation.

If you change the rotate order like this, you will get a different result for the matrix:

vector r = cracktransform ( 0, 3, 1, 0, m );

EDIT: Forgot to change the maketransform line.
Edited by animatrix_ - 2023年4月13日 12:51:32
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]

youtube.com/@pragmaticvfx | patreon.com/animatrix | animatrix2k7.gumroad.com
 Report
User Avatar
tamte
Member
8525 posts
Joined: 7月 2007
Offline
 
animatrix_
If you change the rotate order like this, you will get a different result:

vector r = cracktransform ( 0, 3, 1, 0, m );

Just doing -t, -r also won't work like invert in either case.
but you are changing the order of cracktransform only

all I said is
tamte
For this purpose transform order doesn't matter once you have the matrix

because you are not using the intermediate t r s values so it doesnt matter in which order you crack the transform as long as you consider that order when using the complementary maketransform for "inversion"

in other words since t r s are just intermediate variales in your control, it doesnt matter which order was used to create the incoming matrix, since it's already composed transform matrix
Edited by tamte - 2023年4月13日 10:31:08
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
User Avatar
animatrix_
Member
4495 posts
Joined: 2月 2012
Offline
 
tamte
animatrix_
If you change the rotate order like this, you will get a different result:

vector r = cracktransform ( 0, 3, 1, 0, m );

Just doing -t, -r also won't work like invert in either case.
but you are changing the order of cracktransform only

all I said is
tamte
For this purpose transform order doesn't matter once you have the matrix

because you are not using the intermediate t r s values so it doesnt matter in which order you crack the transform as long as you consider that order when using the complementary maketransform for "inversion"

in other words since t r s are just intermediate variales in your control, it doesnt matter which order was used to create the incoming matrix, since it's already composed transform matrix

Yes that's why I said for arbitrary matrices not the ones where you have control over the order like in OP with transform parameters.
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]

youtube.com/@pragmaticvfx | patreon.com/animatrix | animatrix2k7.gumroad.com
 Report
User Avatar
tamte
Member
8525 posts
Joined: 7月 2007
Offline
 
it can be an arbitrary matrix from bound sop, doesn't matter, a matrix is a matrix, it doesn't know about the order used to make it
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
User Avatar
animatrix_
Member
4495 posts
Joined: 2月 2012
Offline
 
tamte
it can be an arbitrary matrix from bound sop, doesn't matter, a matrix is a matrix, it doesn't know about the order used to make it

Yes of course. Sorry I missed the above change without the maketransform line. But all I am saying is to my understanding the order is important if you want the exact values used to construct the matrix. Whether passing the same values to both cracktransform and maketransform alleviates the issue of not knowing the exact order, I am not sure.
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]

youtube.com/@pragmaticvfx | patreon.com/animatrix | animatrix2k7.gumroad.com
 Report
  • Quick Links