Hi Everyone, I have a simple scene with two-floor level and the scene has 4M poly count as shown in shapespark.
I am having an issue while using it on iOS mobile platform, it slow and laggy. I have tried it on iphone11 and iphone11 pro. Is there any way to speed up performance other than reducing the poly count.?
Does “Hide in view” option in Object view helps in improving the performance??. As i could hide the 1st floor when the viewer is on ground floor. Will that help in boosting the performance?
Thank @Kuba for the quick response. i’l definatly try reducing the lightmaps and resolution.
Is there any limit for poly count on mobile platform that shouldn’t exceed?
Also Hiding the object in view wont speed up the loading of scene? or its doesn’t matter? i thought it would load the object and consume memory only for the objects which are visible.
Hiding elements surely wouldn’t speed up loading time. The scene is loaded as a whole at the beginning (btw. it would be great if it could load the visible parts at the beginning to speed up starting the presentation).
There is no hard polycount limit - it all depends on the device you are using. When 3 million polygons is to much, try reducing it to 1 million
1)Does the polycount shown in the Shapespark includes the polygon count of instanced object or its just the original mesh polygon count?
2) Does instance object consume separate memory per instance or It doesn’t(Like how it works on other render engines)?
@Mahesh I am not sure if I know answer on this question.
In statistics Shapespark shows me always more than 3d program so I guess it shows all polygons, including instances.
I am not sure how it works under the hood but I guess using instances can save you tons of memory but still all this has to be render on the screen so even if everything is instances it wouldn’t be performance neutral.
@Kuba is right. It shows the number of all triangles in the scene. So, for example if a chair is instanced 12 times in the scene, the triangle count includes triangles from all 12 chairs.
Right, again. Instances makes the scene size smaller, both for download and in-memory, but they don’t make rendering faster.
Hi @wojtek, I have tasted my scene on iPhone 11 and iphone10, The performance is so much slow iphone11 as compared to iPhone 10. On iphone10 it was running very smoothly as compared to iphone11. I have sent you the videos comparing the performance in a personal message. Also, I have sent the scene link which I used for testing. Can you please have a look and let me know what’s causing this issue. Because as per me if it’s running fine on iphone10 , it should run smoothly on iPhone 11 too.
We’ve tried your scene on iPhone 11, and I can confirm it works slower than expected. We’re not sure yet what is causing this, and if it’s something with our viewer or drivers/WebGL implementation specific to iPhone 11.
Your scene is already well optimized - ~1.3M triangles, but what you could try to further reduce the triangle count is optimizing the 6 office chairs. They are now responsible for ~0.5M triangles. When I hid them using the “Custom hide in views” option (“Objects” tab), the performance improved.
Thanks for quick response . Yes i have reduced the scene further more and still working on optimization. Hoping the issue might be solve with any updates on iOS or shapespark (depending on where the issue is with ) in future.
Hi @wojtek, I’m working on some tours made little changes in each one. I realized different load time between them but a very increase load time in fourth quarters of the wheel? This behavior is not constant and doesn’t depend of internet speed connection, we do not know exactly why!
Can you help me please to understand this and find a solution to decrease the load time of the tours?
@jorgearq, in my tests the three scenes download a similar amount of data and it takes roughly the same time in all cases.
So, perhaps what you’re observing is that if you open a scene with data in the browser cache it takes less time than if you open another scene with data not yet in the cache.
