@bghgary I was curious whether the fix is already live, so I reopened the original PG example.
The BabylonJS version is on 5.0.0-alpha.64, which seems to be the newest one at the time of writing.
Unfortunately the model doesn’t even load now.
There is a loading loop which ultimately results in an error: “A problem repeatedly occurent on…”.
Again this is only happening on IOS version 15.
Versions below don’t seem to have this issue.
@bghgary The difference is that the original playground example contains the full material library of the project (11 MB) whereas the latest example only comes with the required materials for the example (600 KB).
Still I wonder why the loading loop occurs now, because this wasn’t the case with the BabylonJS version when I started the thread.
However the fix itself seems to work, because otherwise (https://playground.babylonjs.com/#E2FYTU#24 wouldn’t work.
Is there a way to tell when the fix is going to be available in an official release?
This won t be hotfixed in V4 and V5 is meant to be release in April but we are currently not doing anything major mostly bug fix and quality improvment so you can definitely use the preview safely.
Hi @bghgary,
I tried the original PG with an iPad 12.9, Safari V15 (via BrowserStack) and I still had the loading loop.
It occured on the iPhone13 (Safari V15) as well.
After some investigation, I am confident the KTX code isn’t leaking anymore. The issue now with iOS is the amount of memory available on the device. Depending on how much memory is available on the device, loading this model will eventually run out of GPU memory. I believe this is why it crashes inconsistently. I tried commented out the code to upload the resulting data after decoding the KTX and it consistently no longer crashes.
Between iOS 14 and 15, we know that Apple removed support for ETC2 and PVRTC which causes Babylon’s KTX decoder to use raw RGBA textures. This is most likely the reason why this scenario doesn’t crash on iOS 14. I don’t have a device still running iOS 14 to confirm.
On iOS 15, loading the model in the OP, it will try to upload 1.914GB of texture memory. Once in a while, I am able to load this and it works, but it often fails. This is in line with the theory that we don’t have enough GPU memory.
Long story short, this model is too big to load without using GPU compressed textures. The easiest solution is to reduce the amount of texture memory by reducing the size of the textures. There is a possibility that we can use 2-slice ETC1 to handle the lack of ETC2/PVRTC, but that’s a feature that will take some effort to implement if we decide to do it.
I understand that the model may just be too large, that’s fine.
I’m not that experienced with the different methods for KTX compression, but is there currently a way to create compressed texture that are working on iOS15?
Because for me it sounds like it doesn’t since ETC2/PVRTC is not supported anymore and ETC1 is not implemented yet.
The BasisU compression scheme inside the KTX container can only output to certain GPU formats. Since you are using ETC1S for the compression in KTX, the only viable GPU format supported on iOS 15 is ETC1 (for textures without alpha) and RGBA (for textures with alpha). You can use UASTC instead of ETC1S with KTX which will be better quality but bigger. Using UASTC will result in using the ASTC format for the GPU on iOS15.
ETC1 is implemented. It’s the two-slice version that is not (i.e., decode into two textures for RGB and A separately since ETC1 doesn’t support alpha). We don’t have the ability to do this at the moment.