Will close this report since I see no information provided that is inconsistent with how exporter should work.

This task is 6.5 years old. Maybe fixing the fbx exporter isn't possible with the licensing issues as they are. What about a hack export to Unreal option that very specifically modifies the animation data for Unreal exports so that the armature isn't shrunk?

It's directly related to Unreal. I don't know if it shows up in other programs, but I can link you to about half a dozen different forum posts on Unreal sites that are trying to figure out this problem. The issue is very specifically that the blender fbx exports import into Unreal with the skin at one scale and the skeleton at another, and this causes particular problems with physics and socketing attachments in Unreal. This bug report has a very specific scope, unlike the other generic fbx card (that hasn't been fixed for several years).

In T99075#1378543, @Colin Knueppel (ColleyKnu) wrote:

Epic's Unreal is quickly growing again in the games industry and increasingly used in television, short film and movies. I worry that this should be treated as it's own bug, because this is a very specific workflow that at least tens of thousands of professionals are regularly having to navigate around. A specific solution to this particular workflow may be quicker than addressing the larger issues of the FBX import and export. Considering all that, and that Epic is a corporate level sponsor for Blender, is it that big of an ask that this get treated as a task with its own priority (That other task is almost 3 years old, btw)?

And apply transform did not work.

@Bastien Montagne (mont29) Hi, can you comment on this? I don't see any reason to relate this issue with Unreal engine since issue is related to FBX import/export

Epic's Unreal is quickly growing again in the games industry and increasingly used in television, short film and movies. I worry that this should be treated as it's own bug, because this is a very specific workflow that at least tens of thousands of professionals are regularly having to navigate around. A specific solution to this particular workflow may be quicker than addressing the larger issues of the FBX import and export. Considering all that, and that Epic is a corporate level sponsor for Blender, is it that big of an ask that this get treated as a task with its own priority (That other task is almost 3 years old, btw)?

Hi, thanks for the report. Did you try exporting with Apply Transform option enabled? (it's an experimental option though)
Maybe problem you've reported here is a known issue: T70161: FBX I/O Imports and exports objects with wrong scale transform
Could you confirm if this is the case for you?

Thanks for checking, will close then.

Thanks for checking, will close then.

I've just re-tested in 3.2 and master (debug mode) and couldn't reproduce anymore. I think this issue can be closed now.

In T91876#1377327, @Richard Antalik (ISS) wrote:

Is this still an issue? I was checking again, but I am not able to reproduce the issue anymore. Since issue is reported for alpha, I don't have exact build to check.

Is this still an issue? I was checking again, but I am not able to reproduce the issue anymore. Since issue is reported for alpha, I don't have exact build to check.

Can confirm the issue, but 2.90.1 seems to behave like this either.

I don't usually export in OBJ, so I don't know if the default options are asl correct for exporting vertex color. But I have not been able to get max or windows viewer to find a vertex color channel in any of its forms (vertex, facecorner) or types (color or byte).

In T98721#1371425, @Alberto Velázquez (dcvertice) wrote:

I'm checking that same problems happens with all importers that I have tried (OBJ/GLTF) so I suppose that all exporter are affected.

I made a video demonstrating the issue and then outlining things I've tried, including recommendations from this thread: https://www.youtube.com/watch?v=uzDhFRfB-d8

I am having this problem as well and it is driving me crazy for several days. I have narrowed down some of the issues but not the solution. The re-scaling solution does not seem to work for me.

im having the same problem in like 2 days btw i download another version from lender i was using like version 8.somthing like that so should i get the version back or can i resolve the problem from uninstall it and redownload it again ?? please help because this problem effect on me because of the platform that i us it works only by the FBX system

I'm able to replicate.

D14718 should resolve this report.

We should probably also mention this task there in patch If D14718 also fixes this

OK.... think this is a manifestation of the need for a serious refresh of how we handle armatures in our importer... Was checking FBX official API doc, they now give a bit more info about how an skeletton is supposed to be built in FBX, we need to update our code for that...

Thing is, there seems to be many issues with this file... We do not have the time to investigate a 20MB binary FBX file, but will add a check/workaround for this error in the importer code for now.

Problem is, mode 7 and 8 are NTSC 'drop frames' modes... Don't think we have any ways to represent/handle this in Blender.

The reproduction steps for me were:

1. Enable the plugin and open or save a file in a directory covered by a SVN repo.
2. Enter my username and password for that SVN repo.

I'm having a similar problem with both the camera and the lights:

I think this should go the manual and tool tips in the exporter for now at least.

In principle, I can think of two ways.

How do you suggest the exporters can warn the user?

@Omar Emara (OmarSquircleArt) I have same opinion that you, but it will create a lot of insecurity in users. Cannot be the user warned in some way? It will be hard for user to know this limitation without trial and error.

I see, you are right. Currently, Blender have a limited definition of what vertex colors are, and those are the face corner byte colors. Exporters just use the vertex colors that Blender provides through its API.

I created a blend test file

I can't seem to replicate that. Importing back into Blender yields the same vertex colors. You perhaps attach a simple file that reproduces the issue, along with its exported FBX.

I'm checking that same problems happens with all importers that I have tried (OBJ/GLTF) so I suppose that all exporter are affected.

FBX is a rather hard format to get right, so if you can use an alternative format, that would be best. Maybe GLTF.
Since we can't confirm that this is an issue in Blender itself, I will archive this for now. If you have new information, feel free to add them here and we can reopen and investigate then.

I did, and I saw the same thing you saw. So the change must be coming from Three.js, but they are not helping me. I tried looking all over but couldn't specifically find any alterations to rotation or centre. I am at a loss right now.

Did you get the time to investigate the issue in FBX Explorer?