-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Importing glTF Materials into MaterialX #874
Comments
Probably conditional on Is it necessary to flag vertex colors, normals, and tangents on the material? |
Good condition for alpha, thanks. I'm not sure how MaterialX handles vertex colors, maybe there's a node for them? If so, the importer could multiply that node by the baseColor / alpha inputs. |
I've moved my sample code to use cgltf and a draft is here. There are obviously many things missing from it and the logic is partial, but a start. Note: For vertex colors there are |
Awesome start, I will need some time for a closer look in the next day or two.
In glTF, there's an extension If there's no unlit extension on a material, the same baseColor/vertex color calculation is used, but fed into the In glTF, when not supplied, baseColor, roughness, metallic, and occlusion all default to 1.0. The default values of |
FYI: To allow for independent repo development, I've migrated the basic glTF->MTLX code to this repo, but can move it wherever folks deem is best. There is basic ASCII glTF conversion |
As a discussion point for MTLX->glTF.
|
House cleaning update: I have migrated my personal branch found in this PR to the Khronos fork here. @jstone-lucasfilm, I have some fixes for the geometry loader to migrate back which fixes pathing, but breaks assignments to the default shaderball. This we discussed before but either the files using looks needs to change, or the glTF files does. I think the latter makes more sense -- the transform hierarchy just needs to be collapsed. @ashwinbhat , I noticed Christian Robles references the personal branch. Please reference the new one. Also do you know who created the glTF file for the default shader ball. Was it Sebastian Dunkel ? The prototype repo I have not updated yet as want to discuss how to proceed with dependencies. |
@emackey , @jstone-lucasfilm I have finished both import (this issue) and export (distillation) in my own repo here which uses the Autodesk contributed translation graph by @ashwinbhat et al.
|
When importing a glTF model, it may be desirable to import the materials as well. This is made easier now with the recently added
<gltf_pbr>
node from #861. Here I'll gather my notes on how this might be done.The obvious first step when encountering a glTF material is to create a
<gltf_pbr>
node connected to a<surfacematerial>
output (I'm going to ignore volumetric for this first pass). The glTF material may have "factors" and "textures" included, where a "factor" roughly corresponds to a preset uniform value. Various factors can, in the abscence of a texture, have their factor values simply copied to the<gltf_pbr>
node:materials
block<gltf_pbr>
nodepbrMetallicRoughness.baseColorFactor[0, 1, 2]
base_color
pbrMetallicRoughness.baseColorFactor[3]
alpha
pbrMetallicRoughness.metallicFactor
metallic
pbrMetallicRoughness.roughnessFactor
roughness
emissiveFactor
emissive
extensions.KHR_materials_transmission.transmissionFactor
transmission
extensions.KHR_materials_specular.specularFactor
specular
extensions.KHR_materials_specular.specularColorFactor
specular_color
extensions.KHR_materials_ior.ior
ior
extensions.KHR_materials_sheen.sheenColorFactor
sheen_color
extensions.KHR_materials_sheen.sheenRoughnessFactor
sheen_roughness
extensions.KHR_materials_clearcoat.clearcoatFactor
clearcoat
extensions.KHR_materials_clearcoat.clearcoatRoughnessFactor
clearcoat_roughness
extensions.KHR_materials_volume.thicknessFactor
thickness
extensions.KHR_materials_volume.attenuationDistance
attenuation_distance
extensions.KHR_materials_volume.attenuationColor
attenuation_color
When a "texture" version of any of the above parameters is present, a
<tiledimage>
node should be created for it, ideally using the tiling strategy given in the glTF's associated texture sampler block (default is to REPEAT texture coordinates).If both a "factor" and a "texture" are present, they are multipled together. In the case of color textures (baseColor, emissive, specularColor, sheenColor), the texture should undergo sRGB-to-Linear transform prior to being multiplied by the factor. I think (but I'm not sure) this can be done by adjusting the
type
attribute on<tiledimage>
. Usecolor3
for images that glTF treats as colors (listed above), andvector3
for the rest.For the case of
pbrMetallicRoughness.metallicRoughnessTexture
, the image must be fed into an<extract>
node to pull out the green channel forroughness
and the blue channel formetallic
. There's an example of this in #870 ingltf_pbr_boombox.mtlx
.Several other images have preassigned channels. If
pbrMetallicRoughness.baseColorTexture
contains an alpha channel, it must be extracted, RGB tobase_color
and the alpha channel toalpha
.occlusion
always comes from the red channel. We can look up the rest, but know that all single-channelfloat
inputs in glTF have specified channel mappings for their source textures. Each one should use<extract>
to ensure it is reading the appropriate single channel.The
normalTexture
andclearcoatNormalTexture
images must be fed to<normalmap>
node(s) prior to being connected to their respective inputs. The normal map space is alwaystangent
in glTF. The<normalmap>
node also has ascale
input that can receive the value of glTF'snormalTexture.scale
orextensions.KHR_materials_clearcoat.clearcoatNormalTexture.scale
setting.Ideally, running this process on the glTF BoomBox sample should produce a node graph quite similar to
gltf_pbr_boombox.mtlx
in #870.I'll write a separate issue for export to glTF some other time.
The text was updated successfully, but these errors were encountered: