Before I describe the problem, let me give a little background.
Usually, my workflow is that I create (i.e. dress) the characters in iClone/CC and export them as FBX (at 30 fps) for use in C4D. So far so good. The problem is that I cannot export any cloth or hair simulations from iClone that way (the clothing or hair would be static in C4D); to do that, I need to export this as an Alembic. Since I need the skeleton/joint hierarchy from the FBX version for all kinds of things, I thought I would combine, for example, an FBX character with Alembic hair simulated in iClone using the exact same animation as for the FBX export. At first this seem to work, but then I noticed that the FBX and Alembic would diverge/drift apart. To show this issue, I animated the standard Camila character in short and a crop top with the Catwalk_F animation from CC4 and exported this both as an FBX and Alembic to C4D.
The video should show the problem (the Camila with the “regular” textures/colors is the FBX, the blue one the Alembic). In the beginning they are pretty congruent; at the far end, when she turn back towards the view, the divergence is pretty pronounces. Any such hair on the FBX would shift almost 1/2 width of the head out of place which looks very weird. I don’t really care about Alembic clothes simulated in iClone because I rather simulate those in C4D, but I would like to use the ton of iClone hair products that I own.
Now my questions:
What if anything am I missing?
Can anyone else using C4D reproduce this? How about people using Blender or other 3D applications besides iClone? (This is why I used a standard character and standard animation for this test that every owner of iClone 8 and CC4 has at their disposal.)
Is this a bug or a feature, i.e. something that RL would need to fix?
(Note: The imported textures were not modified/adapted for use in C4D which means that some of them look strange (e.g. the missing transparency of the corneas); usually, I would fix this of course, but for this quick test I did not bother to.)
The frame offset can also be easily adjusted in C4D (even for fractions of a frame which means using interpolation) but it does not work. For example, at frame 250 (30 fps) there is no offset I can choose to get both figures congruent. Actually, an offset of 0 (i.e. no offset) gives the best result (same pose, but Alembic is shifted to the right). Since I don’t know how to screen-record, I’m enclosing screen shots.
Note: I export Alembic from iClone separated by materials so I can use the materials/textures with the FBX for the Alembic parts of the character in C4D.
So I guess, it would be possible to keyframe a position adjustment for the length of the animation in C4D, but surely that can’t be the most desirable solution.
This is pretty much C4D specific issue then, which has to be handled locally (5 cm offset in your case).
BTW, you are not going to see any difference on frame 0 while changing frames offset by 1. You’d start seeing a difference mostly on frames with fast movements. But again, frames offset by 1 might be Blender specific.
One thing for sure, is that iClone exports both FBX and Alembic pretty much synchronized. All issues have to be figured within the target app.
Here’s just another test with fast running motion in Blender (camera is attached to the root bone). It’s synced perfectly.
I don’t think that the problem is a frame offset (at least not in C4D); instead the divergence is apparently related to how far the character is removed from the original position (0, 0, 0) and not based on the speed of the motion (as in the case of a frame offset). Also the divergence is not constant: for example, on frame 250 (@30 fps) it is about 5 cm on X; at the beginning and end of the motion, there is no divergence. In other words, the divergence would have to be compensated for by keyframing the position (translation) for this particular animation between 0 and -5 cm on X for the entire length of the animation.
It is possible an issue for the C4D developers to look into. The problem is that, as far as I understand, I can’t send this file and the included assets to Maxon for troubleshooting because they contain Reallusion IP.
I tried a very simply animation with a moving box. That worked without noticeable divergence between FBX and Alembic export.
Then I also tried the Camila animation without baked softcloth physics (hair). Same divergence as the simulated version.
C4D only read Alembic from iClone when exported as Ogawa (HDF5 used to give me an error message in C4D (Unknown Format) but now it will simply not load (without error message)).
I also use Ogawa.
But again one frame offset can cause a great discrepancy depending on animation speed but not the distance from 0,0,0.
Here is the same animation where I blended a slow walk at the end in iClone and left a default 0 offset in Blender.
There is huge discrepancy throughout most of the clip because she is running, but very little at the end where she walks slowly (being about 15 meters from initial 0,0,0).
You really have to send a project to Maxon for troubleshooting (I see no reason why it would be a problem)
Perhaps the frame offset thing is particular to Blender? Meaning, Alembic files import 1 frame out of sync into Blender as your video clearly shows. I don’t see this here in C4D with my animations even fast ones, and even if I did, I could just put in a frame offset as I did in the screen shots above.
Anyway, I may have found a “fix” to compensate for the divergence in C4D without having to keyframe position offsets for the entire animation. But I need to render a full animation to be sure (“final” render, not a quick and dirty one, so it will take a few hours).
It has taken a bit longer than anticipated, but here is the result. I think the “fix” worked pretty well: the character is FBX, the dress (100k+ polys) simulated in C4D, and the hair is an Alembic from iClone.
And, oh yeah, the fix in C4D apparently is given a heading value of 1 degree (i.e. +1 degree for rotation around the vertical axis) for the Alembic null (group). So it appears that the Alembic is off by one degree which means the further it is from the point of origin, the higher the divergence which is why I originally thought it was dependent on the distance from the point of origin (which it kind of is).
That looks great.
Oh wow, 1 degree off, that would certainly progress discrepancy with distance. Seems to be a bug in C4D.
Meantime in Blender, for whatever reason they import FBX with 1 frame animation offset, which can be set to 0 on import to eliminate the need for any further adjustments in a project.
