Official New FBX Exporter in 2017.2

1.3.0.b1 error fbx animactionclip error:
https://drive.google.com/open?id=1RhCIfNac8Ehf8UQlclEN5bMXdPthOmZ-

 

Hi gdtiti,

I think the problem is related to the (Maya) Compatible Naming option. Try exporting with this option turned off.

The option Compatible Naming renames the objects on export but is not renaming the animation curve bindings, this is why the clips are broken on import. Also, this option should not be renaming game objects in the scene when you're exporting to FBX. It should only do this (with your permission) when you convert to a linked prefab. We need to fix that.

 

you will fix it?

 

Yes and we'll let you know when it's fixed . In the meantime have you tried exporting with the "Compatible Naming" option turned off?



Let me know if it didn't fix the issue for you.

Best,
Viktoria

 

Hi!
I having a problem exporting cameras from Cinemachine: all is working well, excepting when I change the value of "Field of View". With value 60, Maya recognices ok, but if I change it, the camera is not the same (I can change Focal Lenght in Maya, but it's not exact - less FOV = more FL). Someone can help me with it? Thank you very much!

 

Hey Guys,

not sure if this has been reported but i had to add this to one of the maxscripts to get it to work on my end.

 

Hi everyone,

Here's a video highlighting the workflow changes that have been made to the 3ds Max plugin in the 1.3.0b2 forum release.

 

Hi Hafazeh,

Interesting, could you please send me the error you were getting that this was the solution for?

Thank you for reporting this!

Best,
Viktoria

 

Hi cocosesamo,

To help me recreate and fix the issue, could you please send me the following:

- an fbx with the exported camera and an object that the camera is framing
- screenshots of the camera attributes in both Unity and Maya
- screenshots of how the camera should look vs how it actually looks

Thank you,
Viktoria

 

I am seeing a problem in Unity 2017.4.1f1 where by an FBX exported from Maya_LT2018 is showing the Unity transform handle in the wrong place. If you rotate the geometry in the Unity inspector it rotates correctly about the shoulder pivot set in Maya (where the red lines cross). If on the other hand you rotate the geometry using the transform handle in Unity it rotates wrongly around the handle. Basically the handle is in the wrong place ...

I am currently using the FBX Exporter 1.3.0b2, although the scene was originally created with the public Exporter from the Asset Store.

 

Hi fuzzygoat,

At the top left corner in Unity there's an option to set the tool handle position:



Do you have this option set to "Center"?

If so, the handle will show up in the center of the object, regardless of the pivot. Try clicking on it to toggle it to "Pivot". This will place the handle on the object pivot instead.

Let me know if this doesn't fix the issue.

Best,
Viktoria

 

Thanks Viktoria, yup that was it, much appreciated.

 

it happened when opening 3ds max, i'll try to reproduce it for you.
The error was inside 3ds max, just complaining about a string value, not being set.

 

Hi,
I'm trying to use the Unity.FbxSdk to read the skin deformers, but I'm stuck at casting the FbxDeformer to a FbxSkin.

Code (CSharp):

1.                 FbxDeformer currDef  = currMesh.GetDeformer(deformerIndex, FbxDeformer.EDeformerType.eSkin);
2.                 Debug.Log(currDef.GetDeformerType().ToString());
3.                 FbxSkin currSkin = (FbxSkin)currDef;

is returning: InvalidCastException: Cannot cast from source type to destination type.

It seems to be a global issue as I can't cast a FbxObject to a FbxNode either.

Any pointer on this?
Thanks

 

Hi everyone,

This is (really) the very last release before we update the Asset Store package.
We've made a couple of fixes to the FBX Exporter:

FIXES

• Fix Mesh Collider not pointing to exported mesh after converting to Linked Prefab
• Fix so "Compatible Naming" doesn't modify scene on export

As always, we are very interested in your feedback!

You can download the package here.

Note: The FBX Exporter is a “Restricted Asset” under the Asset Store End User License Agreement and is subject to the Unity Companion License 1.0. Further, use of the Autodesk FBX SDK is subject to your acceptance of and agreement to the FBX SDK License and Service Agreement terms.

 

ahmidou: at the moment, whatever the C++ docs say a function returns is as far down as you can go on the C# side. I can see about putting a fix for this limitation on the roadmap.

So far we've been able to side-step this issue by finding other ways to get the information we needed, but if I don't know off the top of my head how to get at the clusters (is that what you're looking for?)

 

Yes, I'd like to get the cluster. If I look at the public repo (not up to date?) it seems the exporter accessing the FbxSkin in C++, would that be why you didn't had any issues?

 

Hi ahmidou,

There's no public repo available right now.
We didn't have any issues because on export we are creating the FbxSkin and adding it to the mesh instead of getting it.

Best,
Viktoria

 

I see, thanks for the info. So is it a dead end until you guys will provide a method to directly get the skin or the cluster from the mesh?

 

Yes, unfortunately.

 

Can you say more about what you're trying to achieve? Over time we want to improve the API,. The more we know about how you need to use it, the more we'll be able to help you.

(I mean, clearly you want to get at the clusters... but what's the context for you to need that? Are you writing a custom importer?)

 

As Unity process the skin weights on import, I want to access the unmodified weights of an imported character. My goal is to improve the skinning quality by extending it to a maximum of 8 bones per vertex.
In the mean time, as I need to move forward I can go the native plugin way.
Anyway keep going with extending the SDK API, it's very nice to have it in C#!!!

Thanks

 

Hi everyone,

We've updated the FBX Exporter package on the Asset Store

It is mostly the same as the last beta package (1.3.0b3) released here, the only difference being that we've made some updates to the documentation and changed the version number.

So if you've downloaded the last beta release, then you already have all the same features/fixes as the Asset Store package.

 

Installation still fails on my end (Maya LT 2018.2). I am super busy with work but if anyone from Unity wants to Skype so I can demonstrate how the installation fails then please contact me.

 

I see Skinned Mesh is supported now, Ill have to give it a go

 

Is there a video that shows the exact workflow or how to properly go about it in steps between Maya and Unity? Maybe I missed that post (couldn't find anything).

 

On Version 1.3.0f1: Skinned mesh binding in a prefab is broken if a skinned joint is removed from the FBX

1. In Maya create 3 cubes, a joint for each, bind them.
2. Add an extra unbound cube for testing
3. Export as FBX into Unity project
4. Create prefab from model
5. In project view add FBX Prefab component, assign model to model field (I guess this is one way to create a 'linked prefab'?
6. In maya delete the extra cube
7. Reexport FBX over top of one in Unity project
8. Switch to Unity, see that the extra cube is correctly removed from 'linked' prefab in scene
9. In Maya, delete one joint, test that the binding still works (It does)
10. Reexport FBX over top of one in Unity project
11. The linked prefab is updated without the joint, but moving the other joints no longer move the cubes, the skinned mesh renderers have broken binding information
12. Test the model in the scene, its joints still correctly move the cubes
13. Make a new prefab from the model, its joints still move the cube
14. Extra credit: See in the broken prefab skinned mesh renderers, their RootBone points to the source model in the project view, not the RootBone in the prefab

 

Just expressing interest in the ability to export at runtime. I know it's already been raised, but it would be an amazing feature!

 

Hi, Viktoria!

Thanks for your reply. I noticed why I had a problem with Focal Length: in recorder Settings, I just only activate "Transform", but no "Camera".

With both activated, Focal length attributes appears in Maya, but now I have new problems:

1- Importing the camera in Maya, all attributes of transform (translate and rotate) are in the correct frames, but Focal Length starts in an incorrect frame:

2- When I animate the focal Lenght, the curve is correct in Unity, but not in Maya:

3- Finally... exporting the camera from Unity in 60fps (Timeline>Frame Rate), Maya understands the keyframes correctly, but if I try to put 25fps in Unity, the keyframes curve starts to do strange movements when a camera is changing to the next one:

I also included a .rar file including the Camera and two objects exported in FBX.

Sorry if I making too much questions, they are important for me.

Thank you very much!

Pablo

 

Yes there are workflow videos available on the Asset Store page

These two in particular use Maya to show the workflow:

 

Hi jschroyen,

Thank you for the detailed repro steps.

Unfortunately the linked prefab not properly updating bone or joint changes to skinned meshes is still a known issue in the latest release.

I will let you know when we have a fix.

Best,
Viktoria

 

Hi Pablo,

Thank you for the screenshots and files, I can definitely see the issues.

What do the curves in the Recorded animation clips look like before export?
Could you please send me an image of these as well?

I want to make sure the issue is not with the recorded clip as when I tried to recreate the problem I was getting the same kind of steps instead of smooth curves before exporting.

Thanks,
Viktoria

 

Hi, Viktoria!

Here is a screenshot of Unity showing the animation curves of the recorder Clip before export it... The first green curve is from Field of View, and the another curves (blue, green and red) are from Position curves. In the timeline, the curve of the Field of View animation is correct. Effectively, the problem is there, only in FOV, in the Recorder Clip.

I included at he right down corner a capture of the curve of focal length in Maya. I suppose that is not important, but the parameter of Field of View in Unity is inversely proportional to Focal Length in Maya.

I know now that the problem isn't with FBX exporter, but... do you know some proccess that could solve this problem?

Thanks again!

Pablo

 

Thank you! We've notified the Recorder team about this, I'll let you know when I hear back.

Best,
Viktoria

 

Hi @cocosesamo ,

Just wanted to update you that they are aware of the problem and we are investigating the best way to get you the fix.

Best,
Viktoria

 

I just ran into an issue that seems to be a fundamental problem with Unity's FBX importer. After exporting an FBX from Maya that includes multiple objects that share the same name, Unity appends numbers to the resulting GameObject names to make them globally unique. Maya requires only siblings to have unique names, and it can re-import its own FBX without modifying these names. Unity doesn't appear to have any GameObject naming requirements, so it's unclear why globally unique names are being enforced by the importer.

Is there a way to suppress this behavior?

 

I've also run into a material color space incompatibility. I've set up a linear pipeline in both Maya and Unity and have created a number of Stingray PBS materials with an albedo color and no textures. These colors appear too dark in Unity, but texture maps render identically in both apps. I can manually correct this by selecting "Extract Materials" and then raising each material's albedo to the power of 0.4545.



Unfortunately this breaks round-tripping. Here's what it looks like when I toss my Unity prefab back over to Maya:

 

Hi, VIktoria!

Sincerely... thank you very much!

Pablo

 

Hi Pablo,

I heard back and the issue with the Recorder is that Unity is detecting the field of view as an integer curve instead of a float curve, which is why we were seeing the step shape instead of a smooth curve.

A fix is available in the Unity 2018.2.0b2 beta package.

If you download and update your project to Unity 2018.2.0b2, then the Recorder will now record the camera field of view as a float curve instead of an int curve.
You shouldn't need to reimport the recorder into your project to see the results.

I recommend saving a backup of your project before updating.

Let me know if you have any more issues.

Best,
Viktoria

 

Hi mstevenson,

It's not currently possible to suppress the behavior. The reason for this is that the names of the objects are hashed to get the file IDs, so they have to be unique in Unity.
They also have to be unique to guarantee that on re-import the objects re-link correctly.

Best,
Viktoria

 

Thanks for the clarification, it had initially seemed that the full path was being used, but I see now that the hierarchy can be rearranged without breaking links (very nice!)

It'd help our team to prevent mistakes if the Maya exporter could warn about name collisions. We have a number of Unity scripts that reference GameObjects by name, but these are often written by Maya artists who are more familiar with the Maya representation of their object hierarchy.

Additionally, if there was a Unity API to identify the names that have been modified by the importer then we could add some sanity checking to our code.

 

Hi, Viktoria!

In first place, thank you very much for your answers and solutions.

I tried the last version of Unity, and it fixed two problems: the strange curve of Focal Length, and the moment (frame) when this parameter changes in regard to the another animations (translation, rotation).

Then, my last issue is exporting all animation with different fps parameters. The exported FBX has a little curve: with 25 fps, there are frames just in it, and then, the camera makes strange movements. If I export in 60 fps, there's no problem with the curve. It's explained better in the next image:



And another question... do you know when will be released the 2018 version of Unity?

Thank you very much!!

Best,

Pablo

 

Thank you for the suggestions . I will take note of these. I agree it would be useful to have some way to know which/if any names will change.

Best,
Viktoria

 

Hi Pablo,

That's great! I'm glad it resolved some of your problems

For the frame per second, unfortunately I don't really have a good solution for you. In both cases the curves are the same, it seems that it just so happens that when recording at 25 fps it will also key inside the little curve, whereas it doesn't when recording in 60 fps.

This is an issue with lack of data when deducing what the shape of the curve should be while keying. There is missing data on what the tangent should be between each key.

Currently, the solutions I can see are to either continue recording with 60 fps or to modify the curves after recording to fix the small bumps.

The beta is available now for 2018.1 and 2018.2 here. I don't have a date for when the official releases will be.

Best,
Viktoria

 

@cocosesamo Just to be certain that this is the issue, could you please also send me images of these curves (25fps and 60fps) in Unity before they were exported?

 

Hi MStevenson,

Yes, we also think the shading is darker in Unity than in Maya. I've been talking with graphic specialists inside Unity and they agree but think it's more accurate. We're also seeking more input from someone from Unity lighting but we think some of the difference is in the color management between Maya and Unity (Linear in Unity and Maya Color Space View Transform defaults to sRGB gamma can be configured for the rendered output).

Here's my results. I light the scene with a pure white light and removed all other light sources from Maya (Camera Environment Color 0,0,0) and Unity (Lighting Environment Source Ambient Color 0,0,0). Stingray material in Maya and Standard (Roughness 0.5) in Unity; no texture. I used the same camera setting and position for both. If you overlap the images and take the difference you'll see where the shading differs.




From the Unity documentation (basically - expect slight differences): The Stingray PBS has slightly different properties than the Unity Standard shader, so we have created a shader variant called “Standard (Roughness setup)“. This shader has a separate roughness map, and thus consumes more graphics resources than the Unity Standard shader. For this reason, this shader requires shader model 3.5 in forward rendering. We recommend using the Standard shader where possible.
The Stingray PBS and Unity Standard shaders have similar looks and responses to light, but do not use the same code. There will be differences between what you see in Maya or 3DSMax and what you see in Unity.
Any changes made to the underlying ShaderFX graph in Maya or Max are not exported in the FBX file and thus will not be reflected in Unity. We do not recommend modifying the ShaderFX graph.

Simon

 

Simon, thanks for looking into this. However I strongly believe that this is a material import issue and not a lighting problem, as illustrated below.

In my tests the difference in lighting between Stingray and Standard Shader appears to be negligible, and highlights and falloff look the same to my eye. Unity's lights are slightly brighter than Maya at the same numerical value, but after reducing a directional light from 1.0 intensity in Maya to 0.8 in Unity the image output is effectively identical when lighting a white sphere.

Material colors are being interpreted very differently between Maya and Unity, and the shift in any particular color is always consistent with the difference between an sRGB and linear interpretation of the value (surely this isn't a coincidence). Applying the standard gamma encoding formula of color^(1/2.2) to each Unity-imported material always matches Maya's color output. The best I can surmise is that Maya stores color values in linear space, but Unity stores them in sRGB (regardless of the project's color space) and is unaware that it needs to perform gamma encoding during import.

In your example your materials are not exhibiting a color shift because you've selected pure primary colors. Each color channel is either 0 or 1, so a gamma shift will not alter these values (raising 1 to any power always equals 1, and 0 to any power is 0).

Here's a clearer example that I've created based on the conditions of your test scene. I've additionally removed each Stingray material's Global Diffuse and Global Specular nodes since they contribute to ambient lighting.



As you can see in this animated gif the primary colored materials do not change, but the darkened and desaturated copies of those materials exhibit quite a substantial gamma shift that is equal to color^2.2.

Here is a more illustrative example. I've separated each sphere into two halves; the left half is shaded using an albedo texture and a white albedo color, and the right half is shaded using a color picker-selected albedo color with no texture. Both Maya and Unity render the textured halves identically, but they interpret base colors very differently. Presumably both programs are aware of a texture's color space and can encode/decode its gamma accordingly. But they ignore base color values and make no attempt to conform them to the same color space.

 

I've added a third frame to my previous example that shows the result of extracting and manually gamma correcting these materials by raising each base color channel to the power of 1/2.2. I've also attached my Maya and Unity projects if you'd like to perform additional experiments.



My recommendation would be to add a field to the model asset inspector that specifies whether the FBX represents color values in sRGB or linear space. If linear is selected then Unity should gamma encode the material before embedding it into the resulting model asset.