Autodesk
Unexpected exported blend shape normals
Describe the bug The blend shape exported normals by Maya from a FBX to USD don't match the original ones from the FBX.
Steps to reproduce Steps to reproduce the behavior:
- Download the test mesh
- Convert from FBX to USD, including animations and blend shapes
- Inspect the converted USD using the official Pixar USDView
- Comparing the normal values that result from the USD blend shapes are different from the ones from the FBX
Expected behavior The blend shape normal values should be the delta from the FBX blend shape normal value and the mesh normal value.
Attachments The FBX test mesh, and some screenshots to show you some relevant values
Specs (if applicable):
- OS & version: Windows 10
- Maya version: Maya 2025.3
Additional context (I am a software developer, so I can answer more technical questions) This might not seem an issue at first, since the exported USD, if re-imported in Maya, appears correct, but for other applications, it might be broken. Any values that I will reference from now are going to be from the test mesh, which is a flag that has baked a wind animation into blend shape frames that are played back.
Each blend shape frame has blend shape normals. All values will reference blend shape frame_0001, vertex 1 as an example vertex to showcase the issue. The normal value of inside the blend shape is (0.04602525755763053894, -0.99569070339202880859, -0.080509059131145477295), as reported through the FBX SDK, and also the Python command MItMeshVertex will return that value inside Maya when the FBX is loaded. The original mesh vertex normal is (0, -1, 0), so the expected delta that it should be present in the USD export should be (-0.0460253, 0.0043093, -0.0805091), but instead, the delta is (-0.016952, 0.003106, 0.0769106). You can check the images to better see what I am talking about. One important note: for the image where it says "Maya exported blend shape normal", it shows the index 0, but that is actually vertex 1, since vertex 0 has no position delta, and Maya ignores it. The application that is used to view the blend shape normal delta value is USDView, from Pixar.
It is clear that Maya performs some sort of processing, or remapping, since the value does not match the original FBX blend shape value. This is not a problem for Maya, since it can de-construct that mapping/processing and it can recover the original values, but a 3rd party application cannot do that. This is the case for my application, which can load USD meshes including blend shapes with normals. The image where it says "Expected blend shape normal" is a screenshot in USD view of my application's FBX -> USD conversion. The question is why doesn't Maya export as blend shape values as the delta between the blend shape delta that the FBX SDK reports and the original mesh normal? This results in applications like mine in having incorrect imports.
I know there is the discrepancy between mapping the normals from the FBX files which are specified per index (or wedge) and the USD specification, where they are specified per vertex, but for the example vertex, that shouldn't come into play as vertex 1 is referenced by a single index/wedge.
I have a question before I have the team look into this. As I understand it, you are importing a FBX into Maya and then re-exporting that FBX into USD; you then have a utility that will compare specific normal values for the normals per vertex in USD and those values don't match? We would need to validate, but I'm guessing that the conversions of FBX mesh format > Maya mesh format > USD mesh format means that you cannot be certain than any face or vertex or normal index will remain consistent across the multiple conversions and this may be a reason for the discrepancies (if you assume normal #N represents the same normal across all formats). Is it possible that you are not comparing the same resulting normal index across the different formats and that you will find the more aligned values if mapping the indices correctly?
This is a little bit convoluted, but I am fairly certain it is the same vertex. I dumped the vertex positions for the flag with blend shapes from the FBX SDK to a txt file and the same for Maya's USD export, the values being read using Pixar's USD SDK. I formatted the floats to the same number of digits and put them in a diff viewer, and there are no differences - first image. So the vertex order in the initial mesh is the same.
Then I have validated using the FBX SDK that there is a single wedge/index that corresponds to vertex 1 - the second image shows that wedge 8655 corresponds to vertex 1, while the third image shows that the wedge count is 1. I did that with a command in Maya as well - fourth image (face 2163, in face index 3 corresponds to overall index of 2163 * 4 + 3 = 8655, since there are only quads).
The only way through the FBX SDK that I could obtain your delta is by this code here - last image. The blend shape normals are specified per index in the FBX file, and for vertex 1, which is referenced by wedge 8655, the blend shape normal is also at index 8655, since that's the wedge's index. Your value can be obtained if you index into the normals directly, i.e. using the vertex' index. I think you might be performing the reduction from per index blend shape normals -> per vertex blend shape normals incorrectly. It is kinda annoying from USD's side to mandate that the blend shape normals are per vertex all the time.
Thanks for this detailed information. We will line it up for investigation.