Rotation interpolation in maya AbcImport

[Diego Garces]

Hi everybody,

I have just found a surprising behavior in the rotation interpolation of the alembic node in the maya implementation of AbcImport. If I ask for the rotation value in the middle of two frames, it is just linearly interpolating between the two values. However, this doesn't work if the angles cross a "boundary", that is angle0 is 179 and angle1 is -170 for example. With a simple lerp it goes in the wrong direction: 179, 170, 100, 60, 0, -100, -170 instead of 179, 180, -179, -175, -170

The safest way probably would be to compute the quaternion from all the rotation angles, interpolate and then calculate the euler angles again, to avoid flipping and other undesirable behaviors This would be more complex to handle, because then they wouldn't be independent channels and a connection should be always made to rotateX, Y and Z even in the cases when only rotationY is animated.

I applied an easy fix to just take the boundary into account, while still interpolating Euler angles. However, I am surprised that nobody has faced this problem before. Am I missing something here? Are we doing something wrong?

Thanks a lot,

Diego

[Francois Chardavoine]

The reason it's implemented the way it is is twofold.

First, to ensure that what you see in maya accurately reflects how a renderer (such as Renderman or Arnold) would interpret it: we do indeed run into cases of flipping, but in those instances we want to be able to see and catch them in maya as well to either run them through an euler filter or have the animator re-key it properly.

Second, there is no way for the Alembic library to know that a sudden change in rotation direction wasn't exactly what was intended: did the animator mean to go from 179 to -170 (as it was keyframed in your case), or did he mean to go from 179 to 190? The motion-blurred results will look very different, but there's no programatic way to determine which one was intended that I can think of.

Francois.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Suter]

We interpolate our rotation values as quaternians for just that reason. There's a 'slerpShortestArc' method in ImathQuat.h that does what you're looking for. You can then convert it back to Euler angles.

                       -- Alex

[Diego Garces]

Well, there is no way to know which way the interpolation should go for sure, but I think it's more intuitive to think that the interpolation should go through the shortest path independently from what Maya decided to set: 179 or -181.

Alex, are you always connecting all the rotateX, rotateY, rotateZ values to the transOp attribute of the alembicNode and calculate all of them at the same time inside the compute? Or are you treating the rotation as a special case with a different implementation? I was not worried about the quaternion interpolation, but the structural changes on how the alembic channels are read and the alembic node is created and connected.

Thanks!
Diego

[Alex Suter]

Hey Diego,

The code I was thinking of isn't Maya based, but I believe its the equivalent of what you describe. We have a layer between Alembic and our translation values in the package. We get the global matrix from the cache if we're right on a sample, if not we interpolate between the closest samples.

We linearly interpolate the scale, shear, and translation, then convert the rotation to quats, use slerpShortestArc, then convert it back to euler to recompose the matrix. We then use that matrix to drive the object directly.

Anyway, that doesn't help you with the channels in Maya much, but I would probably do as you describe it. Perhaps someone more Maya-savvy can help with the structural side.

                       -- Alex

[Francois Chardavoine]

Hey Alex -
Just to be clear, you're doing this at write time, not automatically on read, correct?
A bit like running an Euler filter pre-publish (which we do as well with the -ef flag to AbcExport).
Do you also perform the same interpolation again at read time (which seems risky), or just trust at that point that it was written out as you'd want it?

Francois.

[Alex Suter]

No, we're doing this at read. Write just samples the data as-is.

We did use the Euler filter coming out of Maya for a few shots though.