Just trying out the new release. The release notes say that setCompressedTextureExclusions was added as a method to Engine. We have been using this method for some time now, but with the bump to version 4.1.0, I’m getting an error in the console saying it is not a function. Same for setTextureFormatToUse.
I removed these functions when I added support KTX2 and BasisU since it caused problems in the implementation. Are you using KTX files in conjunction with these functions? I will be adding support for selecting the right texture based on platform capabilities Add support for selecting textures based on available compressed texture capabilities · Issue #7643 · BabylonJS/Babylon.js · GitHub. Would that help?
Yes, we are using KTX files, specifically for the use case you mentioned, selecting the right texture based on platform capabilities. Adding that support would be fantastic. For now, we have a workaround that we can use for development.
@abogartz is out of the office for a few days, but he might have additional thoughts when he returns.
Thanks for the info!
1 Like
Yes, those functions solved an issue where the texture loader was looking for the .ktx versions of all files, including .dds files. That resulted in some console spam and unnecessary 404s. I added the ability to exclude files from the .ktx check. I think there is a workaround where we can add the list of compressed texture types after we set the environment files, so we’ll use that for now, but if you could add the exclusion list back sometime soon that would be great. Thanks!
1 Like
@bghgary agree with Alex on this, we need a simple way to prevent the double dl for known excluded types, do you think you could add back smthg similar ?
Yes, I will make sure to check this when I implement the replacement. Thanks for the feedback and sorry for the troubles!
1 Like
Started looking at implementing this. Part of the reason why I removed functionality in the code is because of this exact issue. The old KTX loader didn’t check the file extension before loading the file and depended on setTextureFormatToUse to convert an existing url to a KTX file to use, which caused all sorts of issues when I was implementing the support for KTX2+BasisU. The current version only checks the extension, just like all the other texture loaders, so setCompressedTextureExclusions should hopefully be unnecessary now. I am planning to add the texture selection functionality as a utility layer on top of the texture loader, which should hopefully avoid all of these problems.
If I add a utility layer to load textures, is that going to cause a lot of churn in loading textures in existing code? I’m assuming textures are currently being loaded by constructing a Texture object. If I introduce a static method LoadTexture on a TextureSelector class, it would mean all the new Texture (that are supposed to pick the right url based on device capabilities based on setTextureFormatToUse) will have to be replaced with TextureSelector.LoadTexture. Is that an issue?
I’ve added back the two functions I removed to address this.
This will be available soon once the nightly goes through in about a day from now.
The only difference between now and before is that the texture will no longer fallback to load a secondary url if the textureFormatToUse one is not available. Please let me know if that’s an issue for your scenario.
2 Likes
Ran into some problems, so will be reverting for now. Will put up another PR soon.
1 Like
Attempt 2: Re-add support for selecting texture based on engine capabilities by bghgary · Pull Request #7788 · BabylonJS/Babylon.js · GitHub. I ended up adding most of the functionality back including the fallback behavior. See PR comment for details.
1 Like