You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of identified, and unidentified issues with the handling of materials from imported FBX and GLTF models,
possibly related issues and PR's: #222 #230 #300 #307 #221
it is sort of a 3x3x11 matrix, left to right is metallic (full, half, none). Front to back is roughness (full, half, none) and top to bottom is albedo (11 levels of grayscale).
How it works is that each diagonal row of 4 cylinders is set up look identical, but configured in 4 different ways
Red: values for Albedo, Metallic and roughness.
Green: values for albedo and roughness, texture for metallic.
Blue: values for albedo and metallic, texture for roughness.
Yellow: values for metallic and roughness, texture for albedo.
Each material is named to describe how it was set up like so: ALBEDO_METALLIC_ROUGHNESS so for example, 0x808080_50pctGrayTexture_0 is mid gray albedo (color in hex) 50 percent gray texture for metallic and 0 value for roughness.
you can use the material inspector and the Debug frame buffer in luci.js to see how the serializer interpreted the material, some are very clearly wrong. Like this one FBX example:
It does not have a roughness map but seems to apply the metallic map to roughness so instead of no roughness (value of 0), it appears fully rough (white texture)
Obviously there are many more way to combine things but I was hoping this could give an idea of which combinations make it break but I can't really see a distinct pattern, I think there are several issues at play here, inconclusively:
both GLTF and FBX has issues.
Generally I think materials using only values work, and materials using only texture maps work, combining them sometimes fail.
Specular values are ignored, this is expected. though it would be nice to be able set the specular value independently.
The test model may not prove that useful for identifying the issues but it may be handy for testing.
Metallic debug buffer, should be: white, gray, black. Left to right
Roughness debug buffer, should be: white, gray, black. Front to back.
The text was updated successfully, but these errors were encountered:
Did you test the same thing but with material overriden by fst or material entity?
It could be interesting to know if at least this is working a s expected. It might help to figure a possible issues.
I did not, it's about 400 materials, and at least for fst overrides, that is probably more than I can handle 😄
In my experience, both fst and material entity overrides works well, apart from some odd cases with fallthrough and defaultfallthrough and sometimes fst overrides don't update correctly, even when cachebusting.
I think these issues are in the serializer not quite working right in all cases, not the rendering itself.
So, it looks like this is not related to the import parsing, at least the change to cgltf did not change anything.
On master 314, wich I believe should be using cgltf for GLTF import everything looks the same:
Roughness
Metallic
I maintain my claim that there are some material combinations that fail to render properly, but maybe a sanity check of my testing methods would be in order because I can't make sense of what I am seeing
There are a number of identified, and unidentified issues with the handling of materials from imported FBX and GLTF models,
possibly related issues and PR's:
#222
#230
#300
#307
#221
There still seem to quite a bit of confusion, disagreement even, on what and how things are broken, or working. I think it's because there are some weird interactions going on between properties where changing one property can affect how another one is interpreted so I made a test model to try and quantify where it breaks:
http://silverfishbucket.s3.amazonaws.com/materialtest/fbx_PBR/gradient%20tubes6.blend
http://silverfishbucket.s3.amazonaws.com/materialtest/fbx_PBR/gradient%20tubes6.fbx
http://silverfishbucket.s3.amazonaws.com/materialtest/fbx_PBR/gradient%20tubes6.glb
Import the FBX and GLB exports into a world with nice skybox to fully appreciate the gore.
it is sort of a 3x3x11 matrix, left to right is metallic (full, half, none). Front to back is roughness (full, half, none) and top to bottom is albedo (11 levels of grayscale).
How it works is that each diagonal row of 4 cylinders is set up look identical, but configured in 4 different ways
Each material is named to describe how it was set up like so:
ALBEDO_METALLIC_ROUGHNESS
so for example,0x808080_50pctGrayTexture_0
is mid gray albedo (color in hex) 50 percent gray texture for metallic and 0 value for roughness.you can use the material inspector and the Debug frame buffer in luci.js to see how the serializer interpreted the material, some are very clearly wrong. Like this one FBX example:
It does not have a roughness map but seems to apply the metallic map to roughness so instead of no roughness (value of 0), it appears fully rough (white texture)
Obviously there are many more way to combine things but I was hoping this could give an idea of which combinations make it break but I can't really see a distinct pattern, I think there are several issues at play here, inconclusively:
The test model may not prove that useful for identifying the issues but it may be handy for testing.
Metallic debug buffer, should be: white, gray, black. Left to right
Roughness debug buffer, should be: white, gray, black. Front to back.
The text was updated successfully, but these errors were encountered: