PBR Materials

[par.winzell]

This has been asked once before in this forum, years ago, with no responses. But the world has moved further along this track since then, so it's worth asking again:

Are there any plans for allowing FBX to natively express models made in a Metal/Roughness workflows?

It could surely be as simple as standardized property nomenclature and a couple of new FbxSurfaceMaterial subclasses? It seems very peculiar to still be stuck with the incompatible workarounds the authoring tools are coming up with.

[Anonymous]

Very good question indeed!!!!

I am truly baffled by the lack of support for PBR material by FBX SDK.  I wish someone from the FBX SDK development team would chime in and give the reason as to why PBR material is being ignored.

[par.winzell]

I can only assume at this point, the implicit standard is Stingray PBS. It does establish a property namespace of sorts. For metalness, for example:

• "Maya|metallic" :float
• "Maya|use_metallic_map" :Boolean (in guise of a float)
• "Maya|TEX_metallic_map :Vector3D (presumably only ever used when shadowed by a texture)

For base colour, there's "Maya|base_color", "Maya|use_color_map" and "Maya|TEX_color_map".

And so on, and so forth.

The Substance plugin for Maya seems to (at least for now) create a Stingray PBS material, so that's another pretty indication that this is the defacto way to represent PBR in FBX right now.

For Blender? I don't even know if their Cycles materials export to FBX, so I guess we might be able to discount that for now.

Modo? I believe they side-step FBX-specific support here and basically create a materials XML file if you want to import in i.e. Unreal or Unity.

It would still be hugely useful for Autodesk to establish a canonical property namespace for declarative metallic/roughness and specular/glossness workflows -- a namespace without a vendor-specific prefix like "Maya".

[samsonite151]

What would it take to get PBR materials supported in FBX?  Do PBR materials have standardized properties, or do the various 3D modelling packages (Max, Maya, etc..) export their own custom properties?  And if it was supported, would that translate well into other 3D packages, like Unreal/Unity?

My personal opinion, I would rather have something that's standardized.  I shouldn't care about vendor specific properties, or what program the data is coming from.

[par.winzell]

I don't really understand why Autodesk didn't include new surface classes for PBR roughness/metallic and PBR specular/glossiness workflows years ago. I agree it would be hugely helpful to have the property names ironed down without vendor specification.

However, we work with what we've given, and Autodesk is mute on this point. The void created by that reality has somewhat been filled by ShaderFX and especially Stingray PBS. The fact that Allegorithmic outputs in this format makes it de-facto standard in a way.

The properties are pretty easy to get to; you look for the compound property 'Maya' and do hierarchical lookups for the other names on that one. I can post code later if anyone is interested. Right now I've only done experimental probes.

As for your other questions, I don't know well enough to say, but I am also interested.

[samsonite151]

I hope to see something soon.  VR markets are growing, and they need PBR environments to make things look realistic.  FBX can be a part of that.

[Anonymous]

I've been using User Defined Attributes feature of Maya and FBX SDK just to get by for now.

(Maya is the only animation/modeling software I have access to at the moment)

You can add user defined attributes to phong or blinn and retrieve then as a user defined properties of FbxSurfaceMaterial in FBX.  So far, it looks promising. 

[par.winzell]

Ardavan, yeah, none of this would be quite as irritating were it not for the fact that FBX already has this super-extensible free-form property system. Autodesk wouldn't even need to write any new code -- I mean, ideally they would, but even just publishing a *standard namespace* for what goes under which property name... it'd be incredibly beneficial.

Your hack sounds perfectly doable, but I want to find something as close to an official standard as possible. I'm settling on Stingray PBS for that. Stingray is bundled with Maya, right?

[Anonymous]

Yes, Stingray PBS is bundled in Maya and Maya LT. 

I sure wish someone from the FBX team would chime in and tell us about their plans for PBR.

This has been a major road block in my work forcing me to resort to such hacks just to get by.  I'm guessing the same might be true for many others who'd like to use FBX and see it prosper.

Anyways, I hope more people read this thread and keep it alive 

[actrask]

Is there an update on this? It would be really helpful to export pbr materials in an .fbx

[agusti.curia]

I was having the same problem, but it seems PBR material data is exported to the fbx file regardless of the warning message on the export process.

You can get the PBR material data this way:

				FbxSurfaceMaterial* material = fbxNode.GetMaterial(materialIndex);

				const FbxProperty topProp = material->FindProperty("3dsMax", false);
				if (topProp.IsValid())
				{
					const FbxProperty props = topProp.Find("Parameters", false);
					if (props.IsValid())
					{
						auto getTex = [&](std::string propName) -> const FbxFileTexture*
						{
							const FbxFileTexture* ptr = nullptr;
							const FbxProperty texProp = props.Find((propName + "_map").c_str(), false);
							if (texProp.IsValid())
							{
								const FbxProperty useProp = props.Find((propName + "_map_on").c_str(), false);
								if (useProp.IsValid() && !useProp.Get<FbxBool>()) {
									// skip this texture if the _on property exists *and* is explicitly false
									return nullptr;
								}
								ptr = texProp.GetSrcObject<FbxFileTexture>();
							}
							return ptr;
						};

						const auto* albedoMap = getTex("base_color");
						const auto* roughnessMap = getTex("roughness");
						const auto* metalnessMap = getTex("metalness");
						const auto* normalMap = getTex("bump");
						const auto* emissiveMap = getTex("emit_color");
					}
				}