Win10 2020.25380 - Instances Rotate To Order Bug/Confusion

Hello,

I’m a little confused by the rotate to order instancing option and not sure if it’s working as it should.
See https://drive.google.com/file/d/1Ku4X8qbiexHa2v3y_f7RaG_xKnyBjmjz/view?usp=sharing and
https://drive.google.com/file/d/1DEULnBrffRCvnHP0bDveKLhA4t3R89bs/view?usp=sharing

It seems “Post-Rot” only affects the scaling, making it happen before “the rotate to vector”, but then the rotate itself doesn’t have any effect, and “Pre-Rot” seems to be doing the opposite of the name, the rotate happens before the “rotate to Vector”.

And default is scaling happening after rotate to (not super usable in general I think though I saw there were consistency/historic reasons)

Here’s the toe file with some custom phongs which show what I’d love to see :

Post-Rot : lookAtMat(iLookAt, uUp)*rotMat(iRot);
Pre-Rot : rotMat(iRot)*lookAtMat(iLookAt, uUp);

With the scale happening before the rotation in all case.
If everything is working as intended, would love to see a more detailed explanation on the wiki!
" Rotate to Vector Order instancerottoorder - ⊞ - Controls where in the transform equation the Rotate To Vector operation is applied."
With equation much like @Malcolm did here : Rotation to Vector happens before scaling. (instancing)
Also found my old post, I guess I’m consistent :smiley:
DEFFERED - 23400 - geo instances - transform bug

Thank you!

instancesRotateToPrePost.toe (7.3 KB)

1 Like

Thanks for the sample. So I think the parameters are currently doing what is documented, but, the parameters are poorly named. Using Pre and Post is confusing since you’d assume it’s following the similar rules of
Scale, Rotate Translate = T * R * S * v.
Where S is ‘pre’ R.

However it’s actually following the naming convention of the Pre Xform page, which is
preXForm * xForm * v

I’ll rename these parameters to follow the newer convention we are using in the Transform CHOPs to be more explicit. Does this clear things up?

1 Like

Also the equation isn’t quite what you have, as the Rot To and Rot Up vectors are multiplied by the inverse of everything to the left (done after it’s the RotTo operation) before they are used to generate the RotTo matrix.

So for the S * T * RotToVector * R case, the RotToVector will have been generated using Vector and Up that are transformed by inverse(S *T).

The goal is to really rotate to that vector, so it tries to counteract other transforms that are applied afterwards that would stop that.

1 Like

Thanks for the explanations Malcolm, understood about pre/post naming conventions.
I’m not sure “counteracting other transforms that are applied afterwards” is super useful to me, but maybe other people’s use cases are different!