From 99d85e8daee4b0f3116b9ba99ac1dcea805c036b Mon Sep 17 00:00:00 2001 From: Par Winzell Date: Mon, 27 Nov 2017 23:39:21 -0800 Subject: [PATCH] Update documentation. --- README.md | 65 +++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 42 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index aa2ec16..baedf00 100644 --- a/README.md +++ b/README.md @@ -44,9 +44,10 @@ Usage: --khr-materials-common (WIP) Use KHR_materials_common extensions to specify Unlit/Lambert/Blinn/Phong shaders. --pbr-metallic-roughness (WIP) Try to glean glTF 2.0 native PBR - attributes from the FBX. + attributes from the FBX, or make a best effort + to convert from traditional shader models. --pbr-specular-glossiness - (WIP) Experimentally fill in the + (WIP) Very experimentally employ the KHR_materials_pbrSpecularGlossiness extension. --blend-shape-normals Include blend shape normals, if reported present by the FBX SDK. @@ -192,50 +193,68 @@ With glTF 2.0, we leaped headlong into physically-based rendering (BPR), where the canonical way of expressing what a mesh looks like is by describing its visible material in fundamental attributes like "how rough is this surface". -By contrast, FBX's material support remains in the older world of Lambert and -Phong, with simpler and more direct illumination and shading models. These modes -are largely incompatible — for example, textures in the old workflow often -contain baked lighting, which would arise naturally in a PBR environment. +By contrast, FBX's material support remains largely in the older world of +Lambert and Phong, with simpler and more direct illumination and shading +models. These modes are inherently incompatible — for example, textures in the +old workflow often contain baked lighting of the type that would arise naturally +in a PBR environment. Some material settings remain well supported and transfer automatically: - Emissive constants and textures - Occlusion maps - Normal maps -This leaves the other traditional settings of Lambert: +This leaves the other traditional settings, first of Lambert: - Ambient — this is anathema in the PBR world, where such effects should emerge naturally from the fundamental colour of the material and any ambient lighting present. - Diffuse — the material's direction-agnostic, non-specular reflection, and additionally, with Blinn/Phong: - Specular — a more polished material's direction-sensitive reflection, - - Shininess — just how polished the material is, + - Shininess — just how polished the material is; a higher value here yields a + more mirror-like surface. (All these can be either constants or textures.) #### Exporting as Unlit/Lambert/Phong -Increasingly with PBR materials, these properties are just left at zero or -default values in the FBX. But when they're there, and they're how you want the -glTF materials generated, one option is to use the --khr-materials-common -command line switch, with the awareness that this incurs a required dependency -on the glTF extension `KHR_materials_common`. +If you have a model was constructed using the traditional workflow, you may +choose to export it using the --khr-materials-common switch. This incurs a +dependency on the glTF extension 'KHR_materials_common'; a client that accepts +that extension is making a promise it'll do its best to render i.e. Lambert or +Phong. + +You can use this flag even for PBR models, but the conversion is imperfect to +say the least, and there is no reason why you would ever want to do such a +thing. **Note that at the time of writing, this glTF extension is still undergoing the ratification process, and is furthermore likely to change names.** #### Exporting as Metallic-Roughness PBR -Given the command line flag --pbr-metallic-roughness, we accept glTF 2.0's PBR -mode, but we do so very partially, filling in a couple of reasonable constants -for metalness and roughness and using the diffuse texture, if it exists, as the -`base colour` texture. +Given the command line flag --pbr-metallic-roughness, we throw ourselves into +the warm embrace of glTF 2.0's PBR preference. -More work is needed to harness the power of glTF's 2.0's materials. The biggest -issue here is the lack of any obviously emerging standards to complement FBX -itself. It's not clear what format an artist can export their PBR materials on, -and when they can, how to communicate this information well to `FBX2glTF`. +As mentioned above, there is lilttle consensus in the world on how PBR should be +represented in FBX. At present, we support only one format: Stingray PBS. This +is a featue that comes bundled with Maya, and any PBR model exported through +that route should be digested propertly by FBX2glTF. -(*Stingray PBS* support is -[high on the TODO list](https://github.com/facebookincubator/FBX2glTF/issues/12).) +(A happy note: Allegorithmic's Susbstance Painter also exports Stingray PBS, +when hooked up to Maya.) + +If your model is not a Stingray PBS one, but you still wish to export PBR +(perhaps you want to generate only core glTF wirhout reliance on extensions), +this converter will try its best to convert your old textures. It calculates, on +a pixel by pixel basis, reasonable values for base colour, metallicness and +roughness, using your model's diffuse, specular, and shinines textures. + +It should noted here that this process cannot ever be perfect; this is very much +an apples and oranges situation. + +A note of gratitude here to Gary Hsu who developed the formulae we use for this +process. They can be eyeballed +[here](https://github.com/KhronosGroup/glTF/blob/master/extensions/Khronos/KHR_materials_pbrSpecularGlossiness/examples/convert-between-workflows/js/three.pbrUtilities.js) +for the curious. ## Draco Compression The tool will optionally apply [Draco](https://github.com/google/draco)