Is there a way to force a texture to compile and not be blocking even if its not being used on any material at the time being?
I am not sure what you mean ? as if the texture is not in use, it should not be blocking anything ?
I have a gltf that on it has extra materials and textures that are not actually used on any mesh but are referenced in the gltf so that way I can package multiple texture variations of a model in a single gltf.
Then after the model is loaded, I have a script that checks for that metadata or (color variance) and when the model was requested it comes with a payload that says what material to rebuild and assign out of the gltf.
The problem is sometimes the model parses faster then the textures and when they get assigned to the material and bound to the mesh they do not propagate for some reason sometimes.
Its really hit or miss. Sometimes it works like a charm other times it does not, but I did notice that even if a texture is used in the gltf and loaded through the asset container its pretty much always flags isBlocking == true
Maybe I need to add a catch for when the material is created, that holds the binding of it to the mesh till all the textures are flagged as non blocking?
Because it seems like once they are cached (loaded once after a reload) it never has this problem, its only on a fresh cascade of files.
I kind of feel like if they where loaded by the assetManager that they should never not propagate and they for sure come up in the assetTask.loadedContainer.texture list, so Im kinda confused?
w000t it is really strange indeed… here it looks like the texture never actually finish loading Do you happen to have a repro somewhere we could have a look ?
Also try loading smthg in texture onReady just to see if they all load ?
Ive also noticed that it seems like the fileTools will hang sometimes on parsing too many/too large of images at once out of a gltf, so I might be able to recreate that in a PG.
I think you are right about using the texture observables. When I remap my materials and bind the new textures to them I’m thinking it might be better to hold the application of the material until until the texture declares itself ready. That will hopefully fix it, if it does not then it might be that the fileTools are actually failing to parse sometimes, but ill have to dig deeper to figure that out.
SOOO. The plot thickens…
This behavior is only seen on Brave…
Also would like to note that since Brave’s last update a BJS scene loading or not is hit or miss and a bunch of other parsing stuff seems to struggle.
So if anyone is using Brave and also is having issues change your browser for now.
Pretty confident know that this problem lies outside of our codebase and is specific to that client.