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?

I can't replicate the issue still, but I am confirming this because the code can be written in a more robust was as describe by Robert.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

File seems fine to me as well, don't have slicer by hand to check though. Will close since this site is only for bugs and errors in Blender. We can't provide support here.

Since the original reporter and other users have reported the issue as resolved, I'm closing the ticket.

@planaria megatron (planaria) What I meant is that you should inherit full scale for all bones and correct their keyframes afterwards to compensate for the missing scale, which is manual work, but is the only workaround I can think of right now.
So in general, don't use "inherit none scale" if you will be exporting to FBX for now.

Omar , in your comment on the previous task you stated i should try to have the lower bones inherit full scale, i did this and it resulted in exactly the same animation output ? am wondering if there is any other kind of workaround for that animation setup?

It seems the feet in your model don't inherit the scale of their parents, but the FBX exporter doesn't support the Inherit Scale option. This is a known TODO. But as a temporary workaround, you can set Inherit Scale to Full for your feet bones for now.

The first file seems to have a totally different lighting setup and rendering settings, could it just be that those are different between the files?

Looks like TimeMode is 8 in this file, yet the FBX_FRAMERATES dictionary doesn't contain a mapping for it.

I can still replicate even with simplify set to zero. It seems it was set to zero in the report as well. Are you testing on the simplified file or the original file?

Yo @Jon Denning (gfxcoder) I hope you didn't give up on this patch, I can see that the last update was about 2 months ago, please keep us inform. Hope you read this post with good health.

cannot confirm:

As a Pipeline developer for both Unity and Unreal this issue is a bit non-trivial for the reasons stated above and I'd love to see a way for us to manually set Animation names by ourselves for each Action.
In games we usually reuse animations across many rigs/characters so having an Animation's name ALWAYS linked to its Rig can cause confusion and pipeline problems.

I discovered something about the scaling issue. Even though Blender can display a rig at 1.0 scale, (with the scale having been applied) it can be a false 1.0 scale, because the FBX Exporter will be reading something different and export the same rig but at a scale that the Exporter is reading (where ever that info is. From I don't know where). That's why the scale issue was happening with me.
I experimented and found a solution (which I posted here: https://blender.stackexchange.com/questions/265519/fbx-export-scaling-issue-into-unity-solution ).
Essentially, I proved that applying a scale through normal means is not enough for the FBX Exporter, and to solve this I needed to make this rig (which had the false 1.0 scale) a Child Of an empty (using the Child Of constraint) knowing that the empty will have by default a true 1.0 scale.
I could then export the rig at the correct scale (adopting the Empty's true 1.0 scale).
I then applied the Child Of constraint, transferring the true 1.0 scale from the empty to the rig, and could then safely delete the empty.
This is a work-around, but it's also proof that the FBX Exporter is reading different info to what Blender is displaying.
I hope that helps.

small detail , if you switch the ik solver to itasc , set itasc solver to animation , not simulation and take precision to 0 and iterations to 1000 it does help the situation but still not perfect

just testing here
i pick the file export stl (scale 1000) and it works fine in prusa slicer no issues.

ok a child was in deform state, I dont understand since I selected every bone with 'A' before running my script

exported bones are now significantly reduced, yet some remains, I'll try to investigate why
https://i.postimg.cc/W4WRpNyK/image.png

oh I missed some CTL, I'll check that out
I was sure I had checked them all
thanks

In T98502#1367249, @p (phil123456) wrote:

(...)
CTL- et TGT- are blender only and should not be in the export
(...)

FYI : I have the same issue installing MY addon while the problem comes form the official Anim Extras addon
(workaround : disabled animextras - install my script - enable animextras)

just installed blender 3.1 , same issue

arf, it's not the case
even after removing these v groups,...

DEF- bones are the one supposed to go to unreal
CTL- et TGT- are blender only and should not be in the export

There are 118 bones in this file, it could be simplified more.
What is the non-deforming bone to analyze?
The ones I identified have deforming children.

@Muhammad Kashan (MrCash812) Have you followed the instructions that I've linked for Windows Defender?

here is the file I used

I checked the system for malware and nothing happened. The system didn't detect any malware and the issue still doesn't seem to be fixed.

I cannot reproduce the problem.
This is the file I used to test: