A new issue has seemed to appear overnight, my models from blender that have been fine in the past are now today having issues properly showing textures. When I use other GLTF viewers the issue is completely fine, this is only happening for some textures as well. The solution I’ve found for the time being has been re-exporting from blender and unchecking the ‘Vertex Colors’ box. Even if the textures are image based they still have this issue as seen in the image below the face texture still shows up in the scene and is connected to the mesh but its not showing up.
Again the strangest part to me is everything has been showing up fine the whole week, only today has this now become an issue.
Thanks for the help!
Yes, me too!
Was just about to post this same thing. These models were working for me yesterday. And today, not.
Here’s the same model in Gltf.Report:
Also, webGPU is not working anymore…
Could you please share a repro ???
cc @bghgary and @Evgeni_Popov
thanks @bigrig I can repro I ll check now with @bghgary
@bghgary is amazing !!! he found the issue and is creating a fix. Basically the draco part of the file is not correct and it looks like there are a lot of incorrect files so we ll revert to the previous behavior not listening to the draco flags
I ll push a new release in a couple hours.
Sounds great. Thx for jumping into it.
@bigrig Can you provide the original file before you ran glTF-Transform? I’m trying to see how to get a file like this. These files have bad Draco data, specifically the
normalized flag is wrong. I tested glTF-Transform on the BoxVertexColors model and it didn’t have a problem, so I want to know how to get into this state.
Sure thing. Here’s the source.
Beaver.zip (447.5 KB)
I usually run the following shell commands using the CLI in batch:
gltf-transform center "$file" "output/$filename"
#gltf-transform optimize "output/$filename" "output/$filename" --texture-compress webp --simplify 0.1
But i just ran this again on the source - and a number of other variations and the output i get loads fine into BJS sandbox. Best thing I can imagine is that I ran these with a previous version of the CLI which may have had this bug in it? One odd thing is that only 6 or so models out of this same batch of 70 are bad-
Although it sounds like @alexa had the same problem with a Blender export - so…?
I don’t think there is an issue with glTF-Transform. I did find an issue with Blender’s exporter. If you select to use Draco in Blender, it will write the wrong information for normalized attributes. I will confirm this and file a bug. glTF-Transform will propagate this error. Did you perhaps select Draco compression from Blender?
This PR addresses the problem and has been deployed. If you see this in the console log, the Draco data does not match the glTF attribute info.
Normalized flag from Draco data (false) does not match normalized flag from glTF accessor (true). Using flag from glTF accessor.
Thx for fixing!
Will keep an eye out for that log msg so can re-process any assets with errors.
I will try to repro, but if you can confirm this is what happened with your assets, that would be great.
Unfortunately, I can’t confirm or deny since it’s been a couple months since I processed these. I’m 98% sure that all Draco was done after Blender in gltf-transform … since that’s my usual process. So the source file above would have been the output from Blender. And i don’t remember Dracoing from Blender… I avoid that part of the panel - b/c i like to have a clean source before compression.
But every now and then I do something irregular for one reason or another… thus the hedging.
Thanks to @donmccurdy (author of glTF-Transform), I found that the Draco code itself has the same bug as Blender. I have filed two issues:
Once these are fixed and glTF-Transform updates to the latest version of Draco, these problems should go away.
In the interim, are you going to revert to ignoring the issue - so that previously exported assets continue to work?
I’m not sure what you mean by this, but the code should behave exactly the same as before in terms of support by default. The only difference is that there will be a warning in the console log if there is a mismatch.
Ah yes, just retested with that asset above that was rendering white and it’s rendering again in sandbox. And I see the warning in console. Sounds good.
@bghgary, these GPU errors started appearing at the same time as the white objects. they have not resolved as of yet. if i add one of these animal assets to the scene, with gpu engine on, i get a bunch of warnings and the game does not load.
if i use the source model, pre-draco compression, it works fine - no gpu error.
related to this same babylon js update perhaps?
Shark.zip (385.6 KB)
@Evgeni_Popov can you have a look ?
It’s related to this one (from WebGPU Status | Babylon.js Documentation, section
Features not working because not implemented yet):
- Support types other than
float for the vertex buffers (position, normal, uv, …)
- Contrary to WebGL, in WebGPU there’s no automatic conversion from the type of the vertex buffer to the type used by shader
It’s on my todo list, but not a straightforward one…
I don’t think it’s related to Draco => if you keep float / normalized data for positions, normals, … it should work.