This is indeed not a bug, it's simply a property that's written to Alembic and that's not read by Blender. Alembic is quite bad in this respect, in that there is no well-documented open standard in which such properties are defined. I'd be very happy if you can prove me wrong on this one.
Thu, Sep 12
Thank you, Philip
There is a good chance this has already been fixed, see
Tue, Sep 3
Mon, Sep 2
Time to archive this imho...
Here are the Alembic file and the texture for the swapping face parts.
Moreover, in the beginning, the rigger used moving UV's as a way to stay with the same plane and still swap between the faces texture grid, but it also didn't work in Blende...
We have the same problem:
As you can see, the rigger used "Write visibility" option to swap between face parts. In Blender - all planes are visible.
Fri, Aug 30
Just tryed it, look like it work in 2.81, thanks for the Fix!
Tue, Aug 27
I'm exporting from maya (2018) . I was sure the test file had normal export enabled. Here i tried here with another test alembic with normals and it also is importing as flat shaded, smooth shading has only effect on first frame, after disabling face on modifier.
Since rBe9c149d911c2, reading loop normals should be supported.
In your file, normals dont seem to be exported:
In a way this is similar to the lack of importing e.g. Focal Length (T54050: Camera focal length animation not importing), or Custom Properties (T50725: Alembic export doesn't take 'Custom Properties', as alembic non-standard data.).
Fri, Aug 23
Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.
We're thinking of ways of including collections into the exported hierarchies, both for USD and Alembic, but it's not an active task at the moment. It's unfortunately not a quick thing to do, because:
Thu, Aug 22
I suspect that solving this properly requires T69046.
I have removed the camera focal length from the task description, as that is already covered by T54050.
Now this task has only a single topic: importing data required for computing motion blur (probably vertex velocities is enough).
@Chris Rydalch (goldleaf) Can you check whether this is still an issue with a daily build of Blender? I don't have Houdini here, so I can't check for myself. I tried exporting a NURBS surface and opening in Gaffer, and that doesn't show anything. However, I don't even know whether Gaffer even supports loading NURBS surfaces...
This would indeed be a new feature and is not a bug. Updating the task properties to reflect this.
This doesn't seem to be an issue in current Blender any more: