Blender 2.78 incorrectly imports FBX from 3dsmax 2012, especially if significant hierarchy present #50449

New Issue

Syr · 2017-01-16T19:23:56+01:00

Syr commented

2017-01-16 19:23:56 +01:00

I have roughly 1000 files impacted by this, with a small % of them manually adjusted so they would import correctly into blender before the copy of max I had access to expired. I nolonger have access to this workaround however, so the remainder of the files require a fixed importer.

How I determined that the files themselves are correct, and that it is failing somewhere in the blender importer:
The files can be seen correctly and the models appear exactly as they should by the free autodesk FBX Converter 64bit (loads things without a hitch, though it uses simplified material rendering so some material features dont show up, such as transparency), and Clockstone FBX viewer also loads the models correctly, placing all objects in the correct locations (though it fails to light the scene properly, and frequently more complex materials tend to get totally messed up and it doesnt handle two-sided transparent materials correctly, but at least all the geometry is in the correct place)

What happens:
The models I'm trying to import were set up for a top-down render to generate sprites for a game. There is a 3dsmax dummy object located near to the origin called Dummy01 with either a 40 or 120 frame animation, where it rotates 360 degrees during that period, with a hierarchy of objects connected to it that make up the space ship model. There are also a pair of lights, a camera, and a camera target, but those all seem to be positioned correctly, as is Dummy01.
Issue 1: Some objects don't have their materials show up in Cycles, which I'm using. I can't figure out what is causing it though.
Issue 2: Its the hierarchy of objects that are children of Dummy01 where the significant problem starts: Immediate children of Dummy01 always seem to import to the correct location, rotation and scale - thats how I fixed the small handful of files, by setting Dummy01 as the parent of all the model objects. However, if any of those objects whose parent is Dummy01, then its a complete tossup if they will have the correct location, rotation, or scale. From the models I've inspected, it seems that the location being wrong is the most common. Furthermore, if the scale is wrong, the location is ALSO wrong. I have not yet observed any models where the rotation was also wrong, but I have only gone through around 10 so far.

Here is a model for which I have the original and 'corrected' versions: (I had selected it because the model itself is a really really old model I had slapped textures on as a joke, but it happened to be convenient in its relative simplicity for debugging this issue. there is a fair amount of trash off on the side of the scene off-camera however, but this was the best example I have where I also have a corrected version of the file)
DPRDCorvette.fbx <-- Original, with bug present
DPRD Corvette.FBX <-- Corrected version, flattened hierarchy so no bug present.

I was looking at the outputs of this function in the blender importer (2.78/Scripts/addons/io_scene_fbx/import_fbx.py):

def blen_read_object_transform_preprocess(fbx_props, fbx_obj, rot_alt_mat, use_prepost_rot):

I unfortunately did not get a chance to look into the materials not importing correctly issue, and the issue persists in the 'corrected' files, so I dont have a comparison for that either.

Here are its outputs for a child of Dummy01 in both files
(Note that in both files, this object is correctly imported! Its the children that are not imported correctly!)
Incorrect version:

Sphere002
FBXTransformData(loc=[0.7178058624267578, -1.4610989093780518, 3.5498430728912354], geom_loc=[-51.616641998291016, 1.651481738917937e-06, 37.781497955322266], rot=[-1.5216147904743146e-13, 7.148960164862063e-05, 1.0017911900108202e-05], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0),
        (0.0, 1.0, 0.0, 0.0),
        (0.0, 0.0, 1.0, 0.0),
        (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[0.16721996665014188, 0.1672199666500117, 0.16721996665013933], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0])

Correct version:

Sphere002
FBXTransformData(loc=[0.7178058624267578, -1.4610989093780518, 3.5498430728912354], geom_loc=[-51.616641998291016, 1.651481738917937e-06, 37.781497955322266], rot=[-1.5216147904743146e-13, 7.148960164862063e-05, 1.0017911900108202e-05], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0),
        (0.0, 1.0, 0.0, 0.0),
        (0.0, 0.0, 1.0, 0.0),
        (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[0.16721996665014188, 0.1672199666500117, 0.16721996665013933], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0])

Here are its outputs for a child of Sphere002 in both files (It happens to be named similarly, Sphere02)
Incorrect version:

Sphere02
FBXTransformData(loc=[51.158695220947266, 1.9073486328125e-06, 37.78150177001953], geom_loc=[0.0, 0.0, 0.0], rot=[2.0355547534796148e-13, 4.378947620032434e-13, 0.0], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0),
        (0.0, 1.0, 0.0, 0.0),
        (0.0, 0.0, 1.0, 0.0),
        (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[1.0000001192092896, 1.0000001192092896, 1.0000001192092896], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0])

Correct version:

phere02
FBXTransformData(loc=[9.272567749023438, -1.461097002029419, 9.867652893066406], geom_loc=[0.0, 0.0, 0.0], rot=[-1.5216147904743146e-13, 7.148960164862063e-05, 1.0017911900108202e-05], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0),
        (0.0, 1.0, 0.0, 0.0),
        (0.0, 0.0, 1.0, 0.0),
        (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[0.16721996665014188, 0.1672199666500117, 0.16721996665013933], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0])

Here are some other models exhibiting other instances of the bug, to see what they should look like, you'll need to use one of the FBX viewers, or view the renders (Which it seems I'll have to attach later because windows explorer is misbehaving when I try to access image files..):
siconiuum siege hypercube.fbx

Kaidan ORE advanced cruiser.fbx

Platform information: (though I don't think it will be terribly useful if even relevant for this bug, never know)
AMD FX 9590
16GB Ram
AMD R9 295x2 (for primary 4k monitor and 1080p cintiq) + AMD R7 260 (for 3x 1080p secondary monitors)
Win 10

I have roughly 1000 files impacted by this, with a small % of them manually adjusted so they would import correctly into blender before the copy of max I had access to expired. I nolonger have access to this workaround however, so the remainder of the files require a fixed importer. How I determined that the files themselves are correct, and that it is failing somewhere in the blender importer: The files can be seen correctly and the models appear exactly as they should by the free autodesk FBX Converter 64bit (loads things without a hitch, though it uses simplified material rendering so some material features dont show up, such as transparency), and Clockstone FBX viewer also loads the models correctly, placing all objects in the correct locations (though it fails to light the scene properly, and frequently more complex materials tend to get totally messed up and it doesnt handle two-sided transparent materials correctly, but at least all the geometry is in the correct place) What happens: The models I'm trying to import were set up for a top-down render to generate sprites for a game. There is a 3dsmax dummy object located near to the origin called Dummy01 with either a 40 or 120 frame animation, where it rotates 360 degrees during that period, with a hierarchy of objects connected to it that make up the space ship model. There are also a pair of lights, a camera, and a camera target, but those all seem to be positioned correctly, as is Dummy01. Issue 1: Some objects don't have their materials show up in Cycles, which I'm using. I can't figure out what is causing it though. Issue 2: Its the hierarchy of objects that are children of Dummy01 where the significant problem starts: Immediate children of Dummy01 always seem to import to the correct location, rotation and scale - thats how I fixed the small handful of files, by setting Dummy01 as the parent of all the model objects. However, if any of those objects whose parent is Dummy01, then its a complete tossup if they will have the correct location, rotation, or scale. From the models I've inspected, it seems that the location being wrong is the most common. Furthermore, if the scale is wrong, the location is ALSO wrong. I have not yet observed any models where the rotation was also wrong, but I have only gone through around 10 so far. Here is a model for which I have the original and 'corrected' versions: (I had selected it because the model itself is a really really old model I had slapped textures on as a joke, but it happened to be convenient in its relative simplicity for debugging this issue. there is a fair amount of trash off on the side of the scene off-camera however, but this was the best example I have where I also have a corrected version of the file) [DPRDCorvette.fbx](https://archive.blender.org/developer/F434502/DPRDCorvette.fbx) <-- Original, with bug present [DPRD Corvette.FBX](https://archive.blender.org/developer/F434504/DPRD_Corvette.FBX) <-- Corrected version, flattened hierarchy so no bug present. I was looking at the outputs of this function in the blender importer (2.78/Scripts/addons/io_scene_fbx/import_fbx.py): def blen_read_object_transform_preprocess(fbx_props, fbx_obj, rot_alt_mat, use_prepost_rot): I unfortunately did not get a chance to look into the materials not importing correctly issue, and the issue persists in the 'corrected' files, so I dont have a comparison for that either. Here are its outputs for a child of Dummy01 in both files (Note that in both files, this object is correctly imported! Its the children that are not imported correctly!) Incorrect version: ``` Sphere002 FBXTransformData(loc=[0.7178058624267578, -1.4610989093780518, 3.5498430728912354], geom_loc=[-51.616641998291016, 1.651481738917937e-06, 37.781497955322266], rot=[-1.5216147904743146e-13, 7.148960164862063e-05, 1.0017911900108202e-05], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0, 0.0), (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[0.16721996665014188, 0.1672199666500117, 0.16721996665013933], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0]) ``` Correct version: ``` Sphere002 FBXTransformData(loc=[0.7178058624267578, -1.4610989093780518, 3.5498430728912354], geom_loc=[-51.616641998291016, 1.651481738917937e-06, 37.781497955322266], rot=[-1.5216147904743146e-13, 7.148960164862063e-05, 1.0017911900108202e-05], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0, 0.0), (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[0.16721996665014188, 0.1672199666500117, 0.16721996665013933], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0]) ``` Here are its outputs for a child of Sphere002 in both files (It happens to be named similarly, Sphere02) Incorrect version: ``` Sphere02 FBXTransformData(loc=[51.158695220947266, 1.9073486328125e-06, 37.78150177001953], geom_loc=[0.0, 0.0, 0.0], rot=[2.0355547534796148e-13, 4.378947620032434e-13, 0.0], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0, 0.0), (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[1.0000001192092896, 1.0000001192092896, 1.0000001192092896], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0]) ``` Correct version: ``` phere02 FBXTransformData(loc=[9.272567749023438, -1.461097002029419, 9.867652893066406], geom_loc=[0.0, 0.0, 0.0], rot=[-1.5216147904743146e-13, 7.148960164862063e-05, 1.0017911900108202e-05], rot_ofs=[0.0, 0.0, 0.0], rot_piv=[0.0, 0.0, 0.0], pre_rot=(0.0, 0.0, 0.0), pst_rot=(0.0, 0.0, 0.0), rot_ord='XYZ', rot_alt_mat=Matrix(((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0, 0.0), (0.0, 0.0, 0.0, 1.0))), geom_rot=[0.0, 0.0, 0.0], sca=[0.16721996665014188, 0.1672199666500117, 0.16721996665013933], sca_ofs=[0.0, 0.0, 0.0], sca_piv=[0.0, 0.0, 0.0], geom_sca=[1.0, 1.0, 1.0]) ``` Here are some other models exhibiting other instances of the bug, to see what they should look like, you'll need to use one of the FBX viewers, or view the renders (Which it seems I'll have to attach later because windows explorer is misbehaving when I try to access image files..): [siconiuum siege hypercube.fbx](https://archive.blender.org/developer/F434522/siconiuum_siege_hypercube.fbx) [Kaidan ORE advanced cruiser.fbx](https://archive.blender.org/developer/F434516/Kaidan_ORE_advanced_cruiser.fbx) Platform information: (though I don't think it will be terribly useful if even relevant for this bug, never know) AMD FX 9590 16GB Ram AMD R9 295x2 (for primary 4k monitor and 1080p cintiq) + AMD R7 260 (for 3x 1080p secondary monitors) Win 10

Syr commented

2017-01-16 19:23:56 +01:00

Changed status to: 'Open'

Syr commented

2017-01-16 19:23:56 +01:00

Added subscriber: @Syr

Syr commented

2017-01-16 19:26:17 +01:00

Also quick comment - I've tried using exported FBXs from the AD FBX Converter, but those come out even more horribly mangled (it looked like it imported it halfway and then stopped) or were <version 7100 and not supported, so I gave up on that.

Bastien Montagne commented

2017-01-17 11:45:46 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2017-01-17 11:45:46 +01:00

The problem of such file is that it’s practically unusable for investigation & debugging. What I need here is the simplest possible file reproducing the issue (that is, something like three cubes parented in a chain, or something like that, with no animation, etc.). Then I can try to understand what’s going wrong here.

Syr commented

2017-01-17 17:45:55 +01:00

Ok, based my experiments yesterday, I think I can use the AD FBX SDK to write a simple bit of code that will chop the file down to the minimum required to reproduce this scenario, resave it as binary, and submit that.

Joey Ferwerda commented

2017-02-02 17:10:47 +01:00

Added subscriber: @TheOnlyJoey

Joey Ferwerda commented

2017-02-02 17:10:47 +01:00

@Syr Had any time to create a new file? if this remains inactive I will have to close down the report.

Syr commented

2017-02-02 18:23:59 +01:00

I tried for a several days and couldn't quite figure out how to remove all the extra junk in the file. However I did manage to figure out how to correct the models, though I'm not totally sure how to implement it in blender (since I used the FBX SDK from autodesk to get it to work):

What I did was I used the FBX SDK's function to evaluate each object's global transform, save those to a separate file, and then I modified the blender importer to then also load that file and at the very end of the import stage, do a top-down breadth-first traverse through the object hierarchy and place each object (via its world location) at the global coordinates that the FBX SDK had computed for me, and with the exception of a single file so far (which had a only 4 objects out of place, easily fixed as the original import had them in their correct locations, and I just copied over their world location data to fix them), its worked flawlessly.

This report can be closed, just figured it would be helpful to have the information for the fix if someone can figure out how the evaluate global transform works and re-implement it here.

I tried for a several days and couldn't quite figure out how to remove all the extra junk in the file. However I did manage to figure out how to correct the models, though I'm not totally sure how to implement it in blender (since I used the FBX SDK from autodesk to get it to work): What I did was I used the FBX SDK's function to evaluate each object's global transform, save those to a separate file, and then I modified the blender importer to then also load that file and at the very end of the import stage, do a top-down breadth-first traverse through the object hierarchy and place each object (via its world location) at the global coordinates that the FBX SDK had computed for me, and with the exception of a single file so far (which had a only 4 objects out of place, easily fixed as the original import had them in their correct locations, and I just copied over their world location data to fix them), its worked flawlessly. This report can be closed, just figured it would be helpful to have the information for the fix if someone can figure out how the evaluate global transform works and re-implement it here.

Joey Ferwerda commented

2017-02-02 18:26:40 +01:00

Changed status from 'Open' to: 'Archived'

Joey Ferwerda closed this issue

2017-02-02 18:26:40 +01:00

Joey Ferwerda self-assigned this 2017-02-02 18:26:40 +01:00

Joey Ferwerda commented

2017-02-02 18:26:40 +01:00

Allright closing.

Sign in to join this conversation.