Loading the same mesh as a comparison following draco compression with defaults in gltf-pipeline. The mesh on the left is compressed and appears completely saturated while the original looks correct. Created a second light with intensity set to 0.0001 when that is active the compressed file looks correct.
Why would the mesh compression change the lighting, and how might I fix this?
Thanks!
Whooot it looks like the vertex colors are all messed up and multiplied by 255
@Evgeni_Popov would you mind having a look at our loader ? it looks like we are missing some normalized buffer or that some conversion are not working ???
Ok as it does not work in 4.2 as well, it is not related to our latest buffer conversions. Is the model ok in other viewers ?
If yes, @bghgary will have a look 
Perfect we ll fix it ASAP !!!
@bghgary it looks like the draco compression relies on vertex data so always expect our default types. I can not remember if it is a known issue or planned to be addressed, so I ll let you check on Monday.
Spent a couple of hours debugging. I believe the color data for the Draco attribute in this GLB is marked as a float which causes the Draco code to not convert the values into the expected normalized values. This may be an issue with gltf-pipeline.
It doesn’t repro with Don’s viewer because I think the code is using UINT8 for the color data which I’m not sure is right for this asset.
Thanks for looking at that! I am able to load in a compressed version properly in the following pg when the full asset string is used and changed a floatColors flag when I created the file. I am hosting the objects on glitch and it seems to be using a cached version rather than the updated version unless it is specified, I know this isn’t a bjs issue.
