Well @shaderbytes Im pretty sure that it is in fact duplicating those textures, I actually went over most of them on the inspector and noticed that they were the same, and you re right it shouldnt change those stats it should be the same amount of materials vs textures thats why I created that thread about the material cloning duplicating textures, but maybe is the case that they are not being duplicated but just appear as a new texture on the inspector , but only they know for sure.
I just went and checked on my configurator :
this scene only has 27 textures.
If you are doing the upfront caching of textures , i did mention it had the con of memory build up. Anyway you need to dig a little and get to the bottom of that number because even at 4 times the number you mention ( 479) , it doesnt get close to what the inspector is reporting (479 x 4 = 1916) and inspector in screenshot is 3227
ahh well there is a little misunderstanding there @shaderbytes , its 479 PBR textures for the initial GLB , I don’t know how the GLB uses or organize those textures but that’s how many of them come with it. If I don’t clone the GLB 4 times this would be the count:
then when I clone them 4 times:
So actually yeah the numbers do add up, I got the original GLB (161 materials) + 4 other cloned (161*4 materials)= that would be 805 materials i guess 4 of them are not there cuz correspond to shadowmap or environment or smt.
I guess I should get rid of the Root mesh so there would be only the clones left , but at the end when I clone the materials the textures should not go up 4 times if the material is referencing the same texture right ? so the inspector is actually telling me that the cloning is creating new textures there.
ok , so besides the issues , in general i see it doesnt look very optimized.
Do you need that amount of materials you are using?
Do you need that amount of textures?
Based on what I see in the configuration options I cant think how you are getting to these numbers unless you have not streamlined anything at all?
Are you sharing materials where possible?
Are you using separate decal geometry where possible? ( plane with transparency slightly above the surface )
btw , the inspector doesnt open up properly on my desktop . I had to go into the dev tools and mangle the css to use absolute positioning and z-index , otherwise i cant see or use it , it opens like this…
ahaha yeah I know what’s happening , I don’t know why but It doesn’t apply the CSS to the inspector right away so you gotta keep pressing “d” so it can place the inspector where my captures show.
Well I would love to know if the materials can be shared when creating the GLB cuz this Model has 5 different Thrash cans, most of them have the same label, so I think that could be shared, but apart from that they all have different sizes, so the unwrapping of the materials wouldn’t fit to all of them if they shared it , just in the accessories that are similar I guess but since I’m not the one who designs the 3D model I don’t know how can that be done or if it can be done.
looking at all the textures , why are you duplicating them 4 times , what is the purpose ? They are all identical copies?
Also not sure if it is just the small preview window in the inspector but many of your normal , roughness and occulsion maps look like flat colors?
yeah they are all identical, and Im not the one duplicating them 4 times , at least not the textures, the materials I do clone them 4 times but that’s because I need to, if I don’t and they share the same material when I change one of them all the other cans will change to the same one and they will all look the same. I could perhaps skip some of the materials that arent configurable I guess that’s some optimization I can perform. but that never represented an issue to the other 2 apps , all 3 apps clone the meshes and its materials 4 times, but the last one is the only one I have been having trouble with.
ahahah yeah most of roughness and normal are flat since the cans are made of steel , without imperfections , I guess I could ask my 3D designer partner if he can get rid of those channels, I guess its just that 3dMax or substance exports them that way on default.
for the materials , since most of your surfaces are flat , i would highly recogmmend using decals , this is a known optimization done in real time rendering ( using a plane with transparency above the surface ) No user will ever really notice its not part of the surface and it then opens up the possibility to optimize your scene.
For the flat textures , yes , trash those not used ( normal and occlusion ) and for roughness just use a number. this alone will drastically optimize your app.
if you look at this model , all the text and logos you see here on the back of this xbox are decals. SO they are not part of the plastic material , they are overlaid, as you can imagine this method makes it possible to work with the underlaying materials as you please it also makes it possible to change the decals with little impact. Micro surface detailing is not really an issue either , so no need for normal mapping and also , its easy to use a different roughness value even.
Looking at your scene I can see this technique will be very handy in optimizing
1 Like
thanks for the recommendation @shaderbytes I will make sure to do those optimizations as soon as I fix the problem that makes it crash on IOs mobile devices.
So @carolhmj I just changed the “SceneLoader.Append” for “SceneLoader.ImportMesh” and you are right, the default loading screen from babylon is not showing anymore , but the app still crashes, I was hopping it had to do with that specific method of the SceneLoader but its not that. 
.
Can someone please try the Safari on Mac remote debugger like @Cedric recommended and see if they can catch any specific error code or see what’s different between these 3 apps that I have ? As I said I don’t own a Mac so I cant. I would really appreciate a little help here.
Actually, if I can allow myself, you should do this optimization recom of @shaderbytes straight away. Especially, the one that results in a count of 3k+ textures!!! I’m about 90 something% sure that this will never make it through in iOS. Already simply because of the timeout vs the time needed to generate all these textures after loading a 30mb+ mesh (and then, all on the scene init).
2 Likes
Yeah your first action should be to optimize the model, as that would rule out a (very probable) reason for the crash.
1 Like
hmm I guess I can make a quick “fix” to try and see if the texture count is the main problem for IOs not running the app, Im gonna comment out the cloning part of the code, so the materials and textures will go down to 161 and 666 correspondingly, then Im gonna try the app on the Iphone 6 I got and see if this does the trick, Im still doing that optimization that @shaderbytes recommended for sure, I already told my partner to get rid of normal, roughness and occlusion channels, I just want to make sure fast enough I know what the problem is on IOs so I can get rid of it sooner, but the thing is that I will still be left with the problem that most of those textures(80% at least) weren’t created by me but by the cloning material process, and it goes over my abilities to fix this matter since is babylon source code and its pretty tricky , I wouldnt even know where to start, but anyway Im gonna go ahead and do what I can and I ll tell you how it goes 
Sadly I got the same outcome, the app still crashes with the minimum materials and textures count that I can set there. seems to me that this is not the main problem, there is something else there that we are ignoring.
what are minimum materials ? I see you still mentioning 666 ( evil number haha ) materials?
You need to rethink how you are doing things. This is a very unrealistic number.
Also 161 textures is rather high as well . ( or if its other way around 666 textures and 161 materials … still far too high numbers )
You mentioned 5 unique models. This should use 5 materials ( your models are simple enough for a single material per model) If each model has its own decal , thats another 5 materials .
assuming the numbers above , i dont know how many decals per bin/object -
Your configurator shoud use about 10 materials and 10 textures ( knowing already you only use diffuse texture ) …
Not exact numbers but understand the reasoning … you need to aim for this kind of logic. ( im not saying you cant have higher than this … you can , im saying always aim for the lowset possible for your needs )
In real time rendering every corner you can cut you should do it. Even AAA games do it.
Just because the others have not crashed doest make them ideal or optimized. Over 600 materials and 160 textures is asking for trouble on many mobile devices… you dont want to be walking on the edge of fatality… 
@shaderbytes I really understand what you re telling me, I meant minimum right now that I don’t have a new 3D model , so yeah I was trying to state the fact that almost with the same amount of materials and textures this app crashes fatally while the other 2 that have maybe 20% less textures and materials (which I think it isn’t that much less) run so good on this old Iphone (Iphone 6 is relatively old right?) , so if it was for materials and textures it should run 20% slower than the other 2 or at least not crash right away as is doing right now, it should try a little harder to work but I haven’t seen a change on its performance nor with 3227 textures nor with 666 textures(hahaha yeah quite a number), and I know my model might seem simple but it has quite some accessories, and every thrash can has his own set of them, and each its own material, so yeah there is some optimization that can still be done but I think we are focusing too much on this while the problem could and must certainly is something else.
So yeah Im really looking forward to getting those numbers down but Im also considering the possibility that when I do that the app would still crash. So there could even be a scenario where the model preserves a high amount of materials and textures and don’t even flinch to run on IOs mobile device.
Or do you consider that 121 materials and 486 textures, or 67 materials and 278 textures to be a perfect count for IOs ? cuz that’s the count for the 2 apps that run just fine.
So I don’t really get that huge difference on performance between my apps when at this point all of them share almost the same material and textures count.
you may very well be walking the edge with the previous ones. You say the third is not much more , but if you are on the edge , its only takes one too many to make everything fall over.
Just find a way to reduce the numbers of the third app into the realms of your other apps and see if it still crashes. ( just monkey patch a small side solution for test purposes if needed and comment out other code etc… )
those texture numbers are high ( even on the other apps ) but i cant say for sure where the edge is , but knowning that memory is finite … this is a concern.
of course it could be something else more intricate, im not denying this and I know you want to believe it is something else, like maybe some stack overflow or something but you need to rule out these other “more obvious” things first. It takes time and effort to debug , test and optimize. People will be reluctant to dive in and help when such glaring possible causes are standing in the way. That is up to you to get sorted first , this is what im trying to point you to.
I cant speak for everyone but this is generally how it works , myself included. We will get to the bottom of this eventually.
1 Like
Well I guess you re right , I ll make that count go as low as the other 2 apps and see how it goes, then I ll come back and tell you what the results were
1 Like
I think you should go further and optimize the three apps as much as possible, or else the models will always be in the way of debugging 