FBX importer normal strength

Blender Development
#1

The FBX importer seems to do a strange conversion for the normal strength, which was brought to my attention by a question on Blender’s StackExchange.

Creating a material with a Normal Map node with strength set to 1.0, exported to .fbx and imported again, will result in a strength of approximately 0.14. The reason for this seems to be the following conversion in line 1429 of the import_fbx.py (4225323a26c8bc41a35d928acd13e470f81f54fe4) introduced in commit 94a1268efa6a16b2e85b95a6ad145e3bbd63f018 .

# (x / 7.142) is only a guess, cycles usable range is (0.0 -> 0.5)
ma_wrap.normalmap_strength = elem_props_get_number(fbx_props, b'BumpFactor', 2.5) / 7.142

The comment seems inaccurate, since Cycles can use normal strength in the range of (0.0, 1.0) with plausible results.

Does anybody more familiar with the fbx format know why this conversion is performed?

#2

I’d welcome it if a couple of smart people could sit down and fix this damned fbx import-export once and for all. It’s not just the issue you described, but the exporter is making all sorts of inexcusable mistakes that make working with fbx extremely difficult sometimes. For game developers in particular this can be a disaster sometimes.

Bastien Montagne stated on the developer board that he is unable to figure out how to code the fbx import-export properly, and that he has no time to look into it further. Most of the issues are known and have existed for many years.
The Blender Institute’s current strategy is simply to ignore the fbx format and wait a couple of years until another format takes its place as the new industry standard. Not a good solution.

#3

@mont29 Did I miss something obvious here?

#4

If you are aware of any developer that actually knows the internals of that piece of crap of a format, and that is willing to work on enhancing our add-on for it, please share, it’d be welcome. I personnaly consider the ratio of time invested in that format, versus results so far, very disappointing (understatement of the year), and am not willing to lose more time on it. Format is not ignored, casual bug fixes and enhancements still happen there, but indeed we have a pile of known issues with no way to fix them currently.

1 Like
#5

Am not really aware of what are the range of values expected in Cycles vs. those expected in FBX here, though a round-trip (exporting and re-importing in Blender) should give same results, can you please make a bug-report, with minimal example file to reproduce that issue? thanks.

#6

I understand completely. I am merely one of many frustrated end users who have to work with FBX import-export every single day. Obvisouly, there are more important issues for you to take care of.
But this particular one has been following me for years, and I cannot walk away from it. Maybe this could become a GSOC project in the future if awareness of this is spread further…

#7

The ticket on the bug tracker can be found here.