I’m currently working on an app that uses babylonjs v5.8.2 and that works well on chrome desktop.
However it doesn’t work on safari for IOS nor chrome for Samsung tablet. (Works well on chrome for my Huawei p20 pro).
Sometimes the app just crash when opening it and sometimes it just loses the WebGL context and doesn’t display anything on the canvas like the following :
Or sometimes it just displays an error where it says that WebGL is not supported.
Is this somehow linked to memory leak or something like that ? I saw that some bug fixes have been made here specificaly for the GLB loader to handle memory leaks.
Sorry for not having a playground for repro, I’m mainly here for asking for help or tips if you already had same issue, it’s pretty hard to do a repro from a playground as the app is kind of heavy. What I can say is that at the beginning of the app I load a glb file and apply some PBR materials on it, and it seems like the crash comes when we reach that part.
Hi,
Did you try it with a former/legacy version or is it a new app?
Did you check on the size of your textures or replace them with much lower res texture or no textures at all?
If you cannot do a repro, can you at least share the specs of your mesh (import method, weight, number of vertices, faces, draw calls…). Also extend a little on how the app is made. Using NPM packages? Is it a react or vue.js app? Are the materials imported or created? May be share a link to the desktop version?
I don’t think anyone will be able to help here fast with just the information above, I’m sorry…
When you say smaller textures do you mean reduced resolution ? Or by weight ?
I’m asking because I use webp texture which are really lighter but as they are lighter we use Bigger texture (2k).
Also it’s a vue app. I import like between 5 to 6 glb at the start, they are like a few mb. (less then 10 each) It seems like it’s when I’m starting to import the glb that everything crash.
The meaning of smaller texture on iOS downwards compatibility with iPhone X means they should not be of a dimension bigger than native retina 2436 x 1125 px. Beyond this, textures should not exceed about 1mb. However this is of course not true with Safari on desktop, so I’m not too sure that this would be the only issue here.
Another point is compatibility with env texture. I believe the glb is loaded with materials so it could be the textures or materials. But it could also be a problem with the loaders. You would also need to check on compatibility of webp textures (can’t tell you, never used them so far).
Others might know better now that we have a bit more information…
Meanwhile, have a great sunday
When that happens, its generally due to jetsam ( high watermark flavor ) and there is 0 insight into it for safari. Fun times, been trying to find a memory pattern the jetsam gods like for over a year now in our app
High watermark is the best because the system comes around at random times asking for memory for reasons unrelated to you, which your app has no idea about. Not that you actually blew some hard, documented limit. If you don’t give it up in the next milliseconds, it kills you
So @sebavan@mawa I updated the textures I use, and it seems like it solved the problem on the Samsung tab (which also is a galaxy A tab , a low end tab)
I haven’t tested it yet on safari or safari mobile but I hope it will do the trick.
However I reduced the texture from 2048 to 256 so it really changed the quality of the rendering.
Can you give me some informations about why big resolution textures can create memory leaks ?
Are there some tricks to avoid that and to optimize the usage ?
No, the fact that it’s working might just be incidental. You cannot have just 256px textures even on mobile. This will look terrible in most cases. I mean it’s ok for smaller objects but the limitation is certainly not that low. Try it on safari, may be use the solution for debug provided by @br-matt. I have the feeling there’s something else behind this.
I will do more research but what is sure is that it’s definitely something linked to textures or material because the crash happened either when I create the PBR materials by using the textures or just a few frame after that.
So yeah lower resolution may be giving side effect that “solves the problem”.
Hi @carolhmj
Yes I actually still need help, for now I didn’t still checked jetsam event as it’s not only a memory leak that happens only on iOS device but also on poor android device.
The “biggest case” of use is that I have an app that configurate items.
To configurate them you have a main item which is represented by a mesh that never changes.
The main mesh is loaded on the beginning of the application as a gltf.
Accessories can be added to the item which add other meshes on the scene.
You can change the item material, same for its accessories.
At first I used a json that contains all the material list that could be used with each items and accessories , and the json contained the url to the textures needed
Every material used are PBR material so at least three textures each.
All the material were loaded at the beginning of the application, same with all the textures
There was some code to manage the possibility of loading the same material or textures twice, but it was still a lot of materials loaded at the beginning of the app.
Every texture were 2048*2048 size textures.
Also all the mesh (item and accessories) are also loaded in the beginning of the app, they are not visible but instance of them are used when needed
I used a DDS texture as an environment texture at first, it was loaded by the method of prefiltering
There could have been more than 20 materials created in the beginning with 3 textures each
Optimization I made :
I stopped using the the environment texture which changed things a lot because before that safari and low-end mobile couldn’t even run the application before crashing , I still use it on desktop browser that are not Safari
I created a different pack of textures with reduced size (256, 512, 1024), depending on what device is used :
For mobile device I reduced the texture to 512*512px which also improved things a bit
For Safari desktop I use 1024*1024px texture
Some optimization I made in the code :
I stopped importing every material in the beginning of the app. And load them only when change the item or accessory material.
I dispose the previous material and previous textures if they are not used by any item or texture
If a mesh is disposed (accessory) , I’m verifying if the material and textures are disposed as well.
I also freeze my material since they don’t have the purpose to have their properties modified
I also freeze my meshes geometry as well
I didn’t changed the way meshes are imported. I don’t know how heavy is it, since it also load the textures given by the gltf by default. However I changed the default texture used to 256*256px.
I really made some improvement however there are still some critical case, for example I tried on an Iphone 8 with Safari. I can now use the app but at some point after testing some accessories and some materials there is a point where the app crashes (but clearly later than before).
Do you have some tips that can make me avoid those crashes ? Is it still possible that it comes from memory leaks due to texture use ?
Thanks for going more in-depth about your app! It looks like you’re doing everything right, but @Cedric@srzerbetto are more familiar with mobile environments so they might have some more pointers?
It looks like Safari is not releasing texture fast enough. or there is a leak in babylon code.
I would try to profile the app using Safari on Mac with the remote debugger. How to Debug Websites on iPhone Safari | BrowserStack
check memory usage and see if you see something in the console.
Hi guys I have some more workable intel for you to check on this matter, don’t know if its gonna be of help but I feel like it will, I got 3 apps , 2 of which run so damn fine on any device , even iphone and ipads which are the most difficult ones to have running on, and the third one is crashing on any IOs mobile device and even on some old android devices, all 3 of them have very similar code, almost identical , the biggest differences between them are the model complexity and number of textures , but that doesn’t seem to be the problem either cuz I checked and the 2 GLB models that work fine have 17Mb and 33Mb size and the one that doesn’t has 27Mb , the first two have 71 textures and 263 textures (GLB built in PBR textures) correspondingly and the third one that doesn’t work well has 479 textures this may be the highest difference , but all of them are between 512x512 px and 1024x1024 px on both the ones that work well and the one that doesn’t, all of them are ordinary png. so I was thinking that you may be able to spot the breaking point since you have better debugging tools than I do for IOs mobile devices , I don’t own a Mac so debugging its out of question for me, but you may compare the 3 apps and see what’s different or wrong on the third.
this are the 2 that work well on any device: SLOPE Product Configurator - this is the one with 17Mb and 71 textures UMEA Waste Receptacles - this is the one with 33Mb and 263 textures
this is the one that doesn’t work well on IOs mobile devices and old android devices: VALUTA Product Configurator - this one is 27Mb and 479 textures
here I leave some inspector count info on the 3 different apps so you can see they kind of share the same specs, also if you wanna check the inspector by yourself you can do it by pressing the letter “d” on your keyboard 10 times , that will launch the inspector.
the 2 that work:
this might be silly or not relevant for many but I noticed that gathering all the app scripts in just one script and minifying it helps on performance, maybe even on those leaks that you mention, I realized of this cuz when I did that on the 3rd app it went a little further without crashing , but at the end still crashed though. But on the devices that do work (my samsung s8 phone) it didn’t demand so much to the machine as it was before that change. cuz my phone was going so slow when having that app open on the browser, and now not so much.
if you need any more info on the code of these 3 apps in order to spot the problem , just let me know.
also noticed the babylon loading gizmo on the back of my 3rd app when launching on mobile devices, which doesn’t show up on the other 2 and for experience I know this happens when something is off with the model Import code, but havent been able to spot why.
This is more of a general observation, but the amount of vertices in your models are a lot compared to their relative complexity. It’s probably a good idea to have a look into optimizing these assets.
Can you elaborate more on this? The loading screen appears by default if you’re using AssetsManager or SceneLoader.Append, and is hidden once the model is done loading. It might be that during your model import there is some code causing the load to not complete, but otherwise, the screen should disappear once the model is loaded.
ahh @shaderbytes you re right but thats also related to the other thread , is 4 times the textures I said cuz when I clone the material it duplicates the textures instead of referencing the same ones, so the same applies to the other 2 projects since in all of them you can configure 4 different thrash cans, so yeah I guess it is a good idea to fix that texture duplicating issue when you re cloning materials, you end up having lots of textures that are exactly the same , and that cant be good.
ahh and @carolhmj yeah you right too, now that I look I am in fact using sceneLoader.append on the 3rd project and sceneLoader.importMesh on the other 2, but yeah that loading screen disapears as soon as the model pops up, I mean is not sticking but definitively shouldnt be appearing either, why would it only appear on mobiles and not on the desktop? , maybe the "sceneLoader.Append is causing all the trouble ? I mean is one of the things that is different from the other 2, so im gonna go ahead and change that and see if there is any improvement. thanks for that !
Also would be of great help if someone could debug it on IOs, see what the console is throwing , maybe there is a more specific issue there
well im not sure because im sure I have seen the devs stating that the textures are not duplicated and are referenced.
BUT That said , i would them question them on this number. Let say I create one material with one texture , and duplicate it 4000 times and it is not creating new textures in memory as they say, then I would expect the stats to show 1 texture …
So are the stats showing javascript texture classes or actual image objects in memory?. I cant see the point of showing the amount of classes … so then the number in the stats window is concerning…
