Out-of-order Alembic normals/UVs in sdk player example...

[ReneGimpel]

Hi-

I'm a developer for Marmoset Toolbag3, and we would like to use FBX as a wrapper for Alembic format, any information or guidance is appreciated 🙂

The Issue:

For some Alembic files, the default loading code (as demonstrated in the SDK player example) does not always return correctly mapped texture coordinates and normals. There may be extra steps involved (or mapping info not immediately available), at this point I just want to verify whether it is supported in the current SDK.

Here is the screenshot of a test model in the fbx example player:

https://www.dropbox.com/s/zjsvgafbdntn4ta/DogFBX2018.jpg?dl=0

The normals (and texture coordinates) appear to be indexed for one type of Alembic, and the file itself contains a different variant. We have an Alembic loader that loads the normals as expected (as well as texture coordinates) - so we can verify the contents of the file - we just can't access it correctly using the SDK loading code, as-is.

One of our Alembic test models can be downloaded here:

https://www.dropbox.com/s/rs0u127u47rh2dp/dogblend.abc?dl=0

NOTE: If this type of Alembic indexing simply isn't currently supported that's fine too; virtually any clarification will be helpful to us..

Thanks
-René Gimpel @Marmoset

[regalir · Accepted solution]

Hi,

First of all, please take note that the Alembic support inside the FBX SDK is limited and has been implemented mainly to support vertex caches and because it is not obvious to find a large pool of .abc files to test, it is also difficult to validate that the provided implementation covers all the possible cases. This being said, the current Alembic reader, is configured to read Ogawa stream format.

I have also looked at the code and there is no special processing performed on the normals. We simply ask the Alembic object for the array of normals and set it, as is, to the FBX structure. We then detect if the normals are defined by polygon vertex by comparing the size of the array with the number of polygon vertices of the mesh. In this case, I confirm that these two values are equal (31936).

It may be possible that the the actual normal arrays are defining normals by polygon vertices but producing faceted polygons instead of smooth ones.

[ReneGimpel]

Thanks, I believe this clarifies the underlying issue (and resolves ambiguity with our test case), we have also noticed a significant difference between alembic formats and your response makes sense...we'll keep an eye out for future updates, understanding it may not be feasible to support this for a while (if at all)...

Thanks again for your help-

-René Gimpel @Marmoset