mainly unused parameter and unused function
some parameters are indeed used in a debug built, I used the
(void)(param) trick
warnings reported by clang 4
The changes here (which only apply to reading from or writing to pbrSpecularGlossiness) will:
- store and read specular color on `AI_MATKEY_COLOR_SPECULAR ` rather than `AI_MATKEY_GLTF_PBRSPECULARGLOSSINESS_SPECULAR_FACTOR`
- store and read specular texture from `aiTextureType_SPECULAR` rather than `AI_MATKEY_GLTF_PBRSPECULARGLOSSINESS_SPECULARGLOSSINESS_TEXTURE`. Even though pbrSG’s specularGlossiness texture uses the alpha channel for glossiness, it will still work well enough with just the RGB channels of the image
These changes do a better of importing and exporting baseColor colors and textures, as well as diffuse colors and textures (in the case of pbrSpecularGlossiness)
- baseColorFactor will be stored on both `$clr.diffuse` and `$mat.gltf.pbrMetallicRoughness.baseColorFactor`, and will be extracted from `$mat.gltf.pbrMetallicRoughness.baseColorFactor` first, and falling back to `$clr.diffuse`. The behaviour for baseColorTexture is similar
- pbrSG’s diffuseFactor will now only be store on `$clr.diffuse` (overwriting any previous assignments to `$clr.diffuse`, e.g. from metallicRoughness’ baseColorFactor, as diffuseFactor is more analogous to diffuse color than baseColor), and will only extract from `$clr.diffuse`
Samplers are now imported into assimp internal format from textures;
Samplers have defaults as per spec;
Sampler enums are strongly typed with UNSET values;
Samplers are exported properly;
Sampler filters are exported as well;
Samplers are re-used across textures on export
Default sampler values are not written
pbrMetallicRoughness and pbrSpecularGlossiness as structs; persist textureinfo properties from start to finish; persist pbrSpecularGlossiness (via extensionsUsed) usage from start to finish
Thomas Lemaire
Daniel Hritzkiv
Jared Mulconry
John Senneker
jamesgk