FBX exporter does not store parameter, which is used in FBX SDKs FbxProperty::IsValid() #40904

New Issue

Norbert.Nopper@freescale.com · 2014-07-01T15:48:27+02:00

2014-07-01 15:48:27 +02:00

System Information
Any

Blender Version
Broken: 2.71

Short description of error
The FBX exporter does not store the parameter, which is used to check, if the parameter is valid or not. The method in the FBX SDK is IsValid() from FbxProperty.

Exact steps for others to reproduce the error
Load the blend file and export it as FBX (binary or ASCII). Load the FBX file with e.g.FBX Review from Autodesk.

The red sphere has no emission (see Blender file), but is rendered full emissive.

In a FBX file, normally the property is marked, if it is valid. The emissive factor is zero but not used, as this property is marked as not valid.

Red_Sphere.blend

**System Information** Any **Blender Version** Broken: 2.71 **Short description of error** The FBX exporter does not store the parameter, which is used to check, if the parameter is valid or not. The method in the FBX SDK is IsValid() from FbxProperty. **Exact steps for others to reproduce the error** Load the blend file and export it as FBX (binary or ASCII). Load the FBX file with e.g.FBX Review from Autodesk. The red sphere has no emission (see Blender file), but is rendered full emissive. In a FBX file, normally the property is marked, if it is valid. The emissive factor is zero but not used, as this property is marked as not valid. [Red_Sphere.blend](https://archive.blender.org/developer/F96189/Red_Sphere.blend)

Norbert.Nopper@freescale.com commented

2014-07-01 15:48:28 +02:00

Changed status to: 'Open'

Norbert.Nopper@freescale.com commented

2014-07-01 15:48:28 +02:00

Added subscriber: @Norbert.Nopper

Norbert.Nopper@freescale.com commented

2014-07-01 16:34:06 +02:00

Cross checked again:

ASCII is working, as FBX Review does not use IsValid() method.

Cross checked again: - ASCII is working, as FBX Review does not use IsValid() method.

Norbert.Nopper@freescale.com commented

2014-07-01 16:49:37 +02:00

Debugged the binary FBX file using an example program with the latest FBX SDK.

Emission factor property is marked as valid but the factor is 1.0 instead of 0.0.

Debugged the binary FBX file using an example program with the latest FBX SDK. Emission factor property is marked as valid but the factor is 1.0 instead of 0.0.

Bastien Montagne was assigned by Sergey Sharybin

2014-07-01 19:43:44 +02:00

Sergey Sharybin commented

2014-07-01 19:43:44 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-07-01 19:43:44 +02:00

@mon29, guess this is something you're best person to ask about :)

Bastien Montagne commented

2014-07-01 22:38:02 +02:00

@Norbert.Nopper I do not really understand what’s happening here…

I file exporte by Blender (7.4bin, 6.1ascii is deprecated), materials have a default (template, 'Definitions') emissive factor of 0.0.

The fact that emissive color is re-defined in the mat itself should not change anything, template still have null emission. So why the heck is sdk outputting a 1.0 emissive factor here???

I would assume incorrect naming somewhere in template…

@Norbert.Nopper I do not really understand what’s happening here… I file exporte by Blender (7.4bin, 6.1ascii is deprecated), materials have a default (template, 'Definitions') emissive factor of 0.0. The fact that emissive color is re-defined in the mat itself should not change anything, template still have null emission. So why the heck is sdk outputting a 1.0 emissive factor here??? I would assume incorrect naming somewhere in template…

Bastien Montagne commented

2014-07-01 22:41:56 +02:00

in fact, this would look as if SDK actually did not care at all about default values written in 'Definitions' place, always expecting the same, 'official' default value here (1.0 for emissive factor)… Question would then be: why the heck to write default values if they are not used at all (and make things 'invalid' when reading the file)?

I feel again like sending all this to canal…

in fact, this would look as if SDK actually did not care at all about default values written in 'Definitions' place, always expecting the same, 'official' default value here (1.0 for emissive factor)… Question would then be: why the heck to write default values if they are not used at all (and make things 'invalid' when reading the file)? I feel again like sending all this to canal…

Norbert.Nopper@freescale.com commented

2014-07-02 11:23:19 +02:00

I did have a further look at the Blender FBX python scripts and I think I did find the problem.

File: export_fbx_bin.py
In the function fbx_data_material_elements(), the template dictionary is initialized (line 1062) and then the properties field is initialized (line 1063).
Then starting form line 1065, all the material properties are set.

File: fbx_utils.py
Function elem_props_template_set() checks, if a value has been written. If something has beend written and the value did not change, nothing is stored in properties.

In function elem_props_template_init() the used dictionary is initalized, where it is checked, if a value has been written or not.

I think there is the bug:

In this function, nothing is written to properties. Each entry in the look up dictionary is initialized with possible true (if tmpl.written- [x] is true), which is in my opinion wrong.
As any subelement of Material has not yet been written to properties, the dictionary has to be initialized with written as false. (Or, the properties have to be set in this function).

I have attached the modified python script from my Blender Linux installation. Please have a look at line 495ff

With this change, it seems that the FBX exporter works fine.

Please note, that this problem can occur with other values, if the Blender default value differs from the FBX SDK default value.

I did have a further look at the Blender FBX python scripts and I think I did find the problem. File: export_fbx_bin.py In the function fbx_data_material_elements(), the template dictionary is initialized (line 1062) and then the properties field is initialized (line 1063). Then starting form line 1065, all the material properties are set. File: fbx_utils.py Function elem_props_template_set() checks, if a value has been written. If something has beend written and the value did not change, nothing is stored in properties. In function elem_props_template_init() the used dictionary is initalized, where it is checked, if a value has been written or not. I think there is the bug: --------------------------------- In this function, nothing is written to properties. Each entry in the look up dictionary is initialized with possible true (if tmpl.written- [x] is true), which is in my opinion wrong. As any subelement of Material has not yet been written to properties, the dictionary has to be initialized with written as false. (Or, the properties have to be set in this function). I have attached the modified python script from my Blender Linux installation. Please have a look at line 495ff With this change, it seems that the FBX exporter works fine. Please note, that this problem can occur with other values, if the Blender default value differs from the FBX SDK default value.

Bastien Montagne commented

2014-07-02 12:41:20 +02:00

Well, this patch fixes thing because it completely ignores whether that same value has already be written in the template or not… This should not be needed, but again , as I said above, I have the horrible feeling values in templates are fixed, defined by Its Highness the FBX SDK - and hence are absolutely useless and just take unneeded room in FBX files…

I wonder when I’ll end discovering horrors in this… thing they dare to call an “open exchange file format”!

Will replace own (sensible!) default values by those found in ref files for templates, and we’ll see… sigh

Well, this patch fixes thing because it completely ignores whether that same value has already be written in the template or not… This should not be needed, but again , as I said above, I have the horrible feeling values in templates are **fixed**, defined by Its Highness the FBX SDK - and hence are absolutely useless and just take unneeded room in FBX files… I wonder when I’ll end discovering horrors in this… thing they dare to call an “open exchange file format”! Will replace own (sensible!) default values by those found in ref files for templates, and we’ll see… *sigh*

Norbert.Nopper@freescale.com commented

2014-07-02 15:20:48 +02:00

Okay, got it. Normally FBX should take the default values written by Blender "globally" in the FBX file - but it does not. With my fix, I am always writing the value.

Good to know and thanks for your time.

Okay, got it. Normally FBX should take the default values written by Blender "globally" in the FBX file - but it does not. With my fix, I am always writing the value. Good to know and thanks for your time.

blender-admin commented

2014-07-02 15:39:09 +02:00

This issue was referenced by blender/blender-addons@df966fb0c5

This issue was referenced by blender/blender-addons@df966fb0c54446197e5d72e0e1132ed15459c8b9

Bastien Montagne commented

2014-07-02 15:54:24 +02:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2014-07-02 15:54:24 +02:00

Bastien Montagne commented

2014-07-02 15:54:24 +02:00

Closed by commit blender/blender-addons@df966fb0c5.