Hi everyone,
we are experiencing a severe issue with some IOS devices.
We are presuming that the IOS devices is crashing due to some ‘memory leak’.
We created a playground for showcasing the issue:
On some IOS devices, the device will keep refreshing itself and display the message "a problem repeatedly occurred … ".
This issue is NOT occurring on Android devices and on PC, only mobile iOS seems to be affected.
This is the scenario where we are experiencing the issue:
we make use of multiple 3D scenes
one main scene acts as a 3D map. User can interact with it while we are loading a second model. This first 3D is a 20-30 MB model with a camera, HDR and 2 lights.
while the users interacts with the first model, we load the second model in the background in another scene (so that the user won’t have to wait to download the model when they switch scenes). Size is around 20-50 mbs. The shared PG implements this logic.
when the user moves to the second scene or when the large second model is finished loading, the system crashes. This is shown in the recording/image that I’m sharing below.
we are using some hotspot inside the scene, by clicking on that we are opening an iframe. When opening, the iframe, browser is also crashing.
deactivating any resizing and set the canvas to a static width and height → didn’t solve
lowering the engine rendering quality → didn’t solve
reducing texture size of the model to below 1k → didn’t solve
removing HDRI lighting and animations → didn’t solve
Here are the recordings of the crashes we got on some devices using the Browserstack testing suite (please note that in some cases, as in these recordings, the system ‘hangs’ with a perpetual loading and sometimes the error “a problem repeatedly occurred …” is displayed).
50mb is a lot. Did you try not to exceed 20mb for a single asset loaded async?
I found 45mb may be the limit but it is depending on bandwidth/loading time.
The safe option (in my opinion) would be to keep it at or below 20mb.
Did you also make sure none of your texture exceeds the size of native retina resolution for iPhoneX (2436 x 1125 px)?
Else, to try remove some from the list:
You can already disregard these (in my opinion). Never heard of any issue with that.
Edit: And I forgot to mention since you are saying you are loading models async. Are you running a lot of code before commiting the promise or chaining multiple assets import with promise all? You should return the promise ASAP making sure the loading time does not exceed the time out.
50mb is a lot. Did you try not to exceed 20mb for a single asset loaded async?
I found 45mb may be the limit but it is depending on bandwidth/loading time.
The safe option (in my opinion) would be to keep it at or below 20mb.
Our Model size in 13mb only and texture is below 1k (verified)
we are loading model two times(each 13mb) in seperate scenes with
BABYLON.SceneLoader.ImportMesh()
Did you also make sure none of your texture exceeds the size of native retina resolution for iPhoneX (2436 x 1125 px)?
Yes all the textures are below 1k.
Are you running a lot of code before commiting the promise or chaining multiple assets import with promise all? You should return the promise ASAP making sure the loading time does not exceed the time out.
I’m afraid it’s going to take some time to debug. I would likely start with this:
Try with async for each model.
Are you running this code AFTER or ONLOAD. Try to remove this code for a minute.
That seems fine but then, how many meshes and submeshes? Try merge a number or even merge everything for a minute, just to run some tests.
How many materials. Remove all materials and apply just a single or a few materials to your merged mesh for a minute, just to run some tests.
Else, do you have a GUI in your scene? Anything else we should be aware of?
Thanks and I hope you’ll soon find the source of your issue. I know how frustrating and time consuming this crap is
Yes. Told you it might be a long journey… Let’s just wait for the others to kick-in before going further.
More minds is better than one, but I’ll be back on this later and we will certainly not let you down with this issue. The more input we have and the more potential problems we can eliminate, the closer we come to identifying the issue. Meanwhile, have a great day
I’m just not sure about iOS and Draco. We should may be remove the compression for running the tests. Given the above I sort of have the feeling that, same as in a plane crash, we might be cumulating small issues (which could explain why it’s so hard to identify the problem).
@guido_wikipoint, just out of curiosity, are you able to pull up a javascript console log after experiencing this issue? I know that there’s a way to do it from a locally run simulator or device but I’m unfamiliar with BrowserStack’s setup.
i hate swearing , I never swear but really … I fucking hate apple. apologies but yeah , they deserve it.
I hope you get it sorted out. ( im currently working on a 2d version of my clients configurator to have a option to avoid using 3D on apple devices… even desktop macOS because you know … safari )
We have spent almost 3 weeks with my lead 3D developer and my lead 3D designer in trying everything we could think of in tweaking the 3D models to be accepted by some IOS devices.
As you can see from this thread in the Apple Forum, it is known that Apple devices have issues with WebGL rendering https://developer.apple.com/forums/thread/662251
We are now working on some more ideas some of which are coming from this great and super-collaborative forum.
Namely from @PolygonalSun@sebavan@mawa (thanks!)
I’ll update you all as soon as our tests are finished.
We ran into a lot of issues on iOS 15 specifically, can you dial down to a lower OS and see if that works for you, the only solution was to optimise the textures even further to a point where it stopped crashing.
Well @Grane , as I said, getting to this point, it’s usually a combination of things and a compromise. You solved your problem lowering the textures but may be speeding up the model load, committing the promise faster, removing the load on materials, etc… all could have given you the same result. The point is that the timeout and overall restrictions in iOS/Safari is kind of out of range of the implicit norm. As if Apple wanted to be the world police of Internet and WebGL. Well, they sure are US enough in this aspect if you ask me.
reducing the complexity of the 3D models (textures, number of polygons). We made use of a useful tool: rapidcompact.com)
releasing memory load while switching scenes (to mitigate the memory leak)
Now we are storing two different models in the DB: one for the ‘standard devices’ and one (simplified) for those IOS devices that have trouble in handling complex 3D models and we fetch accordingly
By applying these rules we reduced the incidence of the issues although we cannot say that the problem is fully solved.
Looking in perspective, this issue can greatly hinder our releases.
We constantly struggle in improving the quality of the user experience and we consider these iphone issues a blocker. Some of our customers have 40-45% of traffic coming from iphone devices and we cannot pretend the problem is not there.
In attachment, you can see that the system is not crashing anymore when changing scenes although more tests are required to state the incidence of the issue. Issue is mitigated but unfortunately not solved.
Being an all-time mac addict (since mac), I can only state here that I’m very unhappy with the handling of WebGL on apple devices. It’s like these Guys just don’t want to hear it. Knowing Apple for that long, it could take just another decade before they fix the issue. I’m afraid that for now there’s no other solution than struggling, making compromises and keep on complaining in forums. This is all truly unacceptable if you ask me (and again, I’m a mac user for business since over 3 decades!!!)
Hi everyone, I’m sharing how we mitigated the issue with the IOS devices, hoping that these indications may be useful for other developers.
Our projects consists of two 3D scenes: Mass Plan (a 3D map of the area) and the car dealer.
We performed the following optimizations:
massplan model
original model size => 18mb with 190k faces
IOS optimized size => 1.29mb with 45k faces
Car Dealer model
original model size => 18mb with 190k faces
IOS optimization size => 9.75mb with 190k faces
We select dynamically the model to present to the user in front, based on his/her user device.
To mitigate memory leak, we performed optimizations in the code to improve memory reuse.
The IOS devices that seem most affected by these issues are: iPhone 13 and iPhone 13mini.
These devices seem to have 60-80mb of total resource that can be loaded with webgl on a single web load. if we trying to exceed the size limit they the site automatic reloads.
I want to thank all who gave us support in trying to solve this issue that is really degrading the 3D experience of users and, IMHO, a potential blocker in the use of web-based Metaverse solutions on IOS devices.
I’m glad you found a solution for your breaking issue. Even if it involves compromises.
On behalf of the community (if I can allow myself) I’d like to also thank you for sharing your experience with us. Such feedback is invaluable both for the team and community.
GL with your project and happy BJSying. Have a great day,
if you ask me.
Even if it involves compromises.
Such feedback is invaluable both for the team and community.