If you see it on all computers it must be some other issue. Could you upload a version of this scene without a video texture and see if it also has such problem? You can make a copy of the scene folder in Documents\Shapespark\ folder, not to remove the video from the original scene. As this is a rather small scene, perhaps a video codec or video resolution is causing troubles on Chrome. Shapespark is using video textures as uploaded in the editor, without any format transformation or resolution reduction, so a high resolution texture could cause performance issues.
Yes, I did feel that the performance improved when I removed the video texture. However, it wasn’t a perfect experience and there was still a visible lag which compromised user experience.
I had few doubts in my mind
- Can using too many lights in a small scene affect performance ?
- Can using too many textures on materials affect performance ?
- Can using too many light probes affect performance ?
- Can using too many reflective materials like glass or metal surfaces affect performance?
- Can using a large file size of HDRI image as Sky affect performance?
- Can the number of triangles in the scene affect performance?
- Can using High res Light map affect performance as compared to low res Light map?
I have seen many scenes made using shapespark and have observed that many users don’t use full capabilities of the software in terms of material finishing and light baking. Is this something I should consider when I make my scene to give best performance and user experience to my clients ?
One surprising thing is that all of these performance issue only arises as I enter full screen. The experience is lag free when I view it on an embedded popup. So, I think there is something wrong only with the full screen mode and not with everything in shapespark.
To clarify by ‘full screen’ do you mean after pressing the f button, so the only thing on the screen is the scene, or when a browser occupies full screen, but still has address bar visible?
As for your performance related questions. Only the number of lights and size of the sky texture does not have any impact on runtime performance. This is because lights are baked, and are nor processed at runtime, and the sky texture is automatically scaled down, so no matter how large the input texture is, the output will have the same resolution.
Textures, light probes, reflective materials, geometry size and lightmap size all have some impact on how much work GPU has to perform. For smaller scenes this impact is negligible, because the GPU is still able to render 60 frames per second even if you add more textures, increase the lightmap resolution, or add a couple of additional objects.
Games usually have a lot of budget to dedicate to optimizations to ensure smooth performance on all devices. Archviz projects have much smaller budgets and much shorter time frame. Most Shapespark customers can’t afford to spend a month optimizing a scene and finding rendering bottlenecks on different devices. It could be more reasonable to follow a couple of rules of thumbs:
- Try to use not more than 2 lightmaps
- Try to keep the geometry size in 2-4 millions range. Often a scene will have a couple of very detailed objects, and replacing them will decrease the size significantly, without much work.
- Usually, reducing the number of textures is not needed. Looking and Shapespark scenes, it looks like it is much easier to include complex geometries in a model than to include enough texture for them to become a performance bottleneck.
- Use at most one light probe per room. If you have rooms without any interesting reflective materials, or rooms that are not important from presentation perspective (like storage), don’t include light probes there.
Look at other Shapespark scenes posted on this forum to see how large scenes are reasonable. Most scenes are apartments or houses. There are many office spaces, but they require more optimization work. Large projects, such as http://data.architektur-visualisierung.build/interaktiv/oekosiedlung3/index.html often target only desktop devices and could require a lot of additional work to run on mobile.
1 Like
Hello,
Thanks for writing in brief. I am clear on what the best practices are when making a scene now. By full screen, I mean when I press “F” key. The overall movement lag comes in when I enter F key mode. After optimization, I was able to reduce the lag somewhat, but still it’s not perfect and smooth like it is for other browsers like Firefox and Internet Explorer.
One more questions: is it constant lag with unusably low frame rate, or is it an occasional freeze and jump that happens every couple of seconds?
Yes, it’s a freeze and jump type of effect. It doesn’t lag continuously.
I have decreased movement speed and the effect has visibly reduced.
1 Like
Hello @jan,
Can you please put some light on this issue as I am still facing it. When I use my Chrome browser, my scenes are very laggy in Fullscreen mode. When I run the same scene on Internet Explorer or any other browser, it works well.
@nishantambekar, may we have a couple of questions to better understand the issue?
- Is it a constant lag with low frame rate, or an occasional freeze and jump as before?
- Do you notice it in a particular scene, or in all your scenes?
- What graphics card does your computer have?
Hello @wojtek,
Is it a constant lag with low frame rate, or an occasional freeze and jump as before?
- It’s an occasional freeze and jump as before. This freeze and jump lag increases when I enter the interior of the building in the scene below
Scene link : https://tour.virtualhomes.in/residential_sample_project
Do you notice it in a particular scene, or in all your scenes?
- The Lag is present in all the scenes but varies as per the scene. In some scenes, the lag is very minute and not so much noticeable. But in some scenes, it’s a total disaster.
What graphics card does your computer have?
- I am having Nvidia GTX 1050 in my laptop.
Do you have a laptop with two graphics cards: an integrated Intel GPU and the dedicated GTX 1050? Perhaps, IE is configured to use the GTX 1050, whereas Chrome is configured to use the dedicated Intel GPU?
Please take a look at this YouTube video showing how to switch a program to use the dedicated GPU: How to switch from Intel HD graphics to dedicated Nvidia graphics card - YouTube
Yes, I have two GPUs - Integrated Intel GPU and GTX 1050
Thanks for sharing the link to the video. However, such laggy experience is not there when I use my Mobile phone with chrome, where I doubt there is a GPU boost to the browser.
Also, the tour/scene would be played by people located anywhere. Since chrome is the number 1 used browser, it isn’t possible to ask all of them to change their graphics settings. Is there a fix from shapespark’s side where we can solve this issue ?
One more point of thinking is that, such laggy experience is only when the scene is played on full screen (F12). When the scene is played with an iframe which doesn’t occupy entire screen, the lag is not there anymore.
We were able to reproduce laggy behavior on one of our machines, but it looked like a browser/drivers/OS issue. The laggy behavior occured for all WebGL websites, not only Shapespark.
We’ve just updated the NVIDIA drivers to the most recent version 451.67 and it helped. Could you check the drivers version on your laptop?
Ok. I’ll update my drivers and check again.
Upon updating my drivers to the latest version, the experience was still the same. Also, most of my clients are using Chrome as their default browser and have had many such laggy experiences which have also directly affected my presentation. Could you please tell why exactly is there a problem only with chrome in Full screen mode ? Is there a way where we can make it as smooth as other browsers like Microsoft Edge or Firefox. This will really be a big plus if chrome is also working like a charm like other browsers are.
We are investigating the issue and trying to reproduce it on our machines.
Would it be possible for you to provide us with screen capture showing the laggy performance? If possible please capture both the windowed and full-screen performance.
Hello,
Video : - YouTube
I have uploaded the video on Youtube to give you deep insights about the lag while comparing Chrome with Microsoft Edge. The Edge browser seems to support GPU Boost and hence gives a flawless experience. However, the same is not with Chrome.
I tried to run this tour with another PC which has a lot more computing power. The CPU usage was 17-18% but still there was lag while the scene was running in Chrome.
So there is definitely something which isn’t compatible with Chrome browser
@nishantambekar Thank you for the video. Do I see correctly that the issue occurs outside in the full scren mode, but not inside?
GPU will be doing most work when the camera is outside and all the model is visible on the screen. The optimizations that prevent rendering of objects that are outside of the camera frustum, and rendering of triangles that are behind walls have small effect when the whole model is on the screen. The screen resolution also affects performance, the larger the window the more work needs to be done by the GPU.
For this particular model, perhaps optimizations of the most complex geometries could improve performance. To test this, could you hide trees, small rings from which the Club House facade is made and driveways to garages (they consist of many small triangles) and see if it helps? This can be done using Hide in views option in the Shapespark editor Objects tab.
Finally I was able to decode why such Lag happens. Here are my findings -
-
The number of polygons play a major role and Shapespark tries to render all the possible polygons visible in the camera frustum, even if they’re hidden behind the wall or not visible at all. When there are too many polygons squeezed in the camera frustum, then the lag kicks in and Shapespark tries to render everything. If the polygons are spread out evenly then even with high number of total polygons in the scene, it would work fine.
-
Chrome does not have any GPU acceleration and hence, the hardware of the device on which the tour is played is the determining factor of the user experience.
Hence, for the tour to be very smooth on Chrome and to avoid such a laggy experience, I urge shapespark to create a new thumb rule of the number of polygons to be below 500K.
When the 3D modelling artist would create the model using this thumb rule, it would be very user friendly with most of the devices worldwide.
Thanks for the analysis. Reducing the triangle count in always beneficial for a Shapespark scene, as it improves the frame rate and shortens the load time. However, the the 500K limit may require significant quality tradeoff for larger scenes, and may be too restrictive for a rule of thumb in my opinion. An average Shapespark scene visitor is not a gamer, so I think, has some level of tolerance for a lag. Also, based on what we hear from our users, feature/quality improvements seem to be currently more important than frame rate. That’s, why I think 3-4M triangles is reasonable as a general rule of thumb.
That said, I am aware each case is different. If you anticipate your audience is sensitive to low frame rate, you can adjust the general rule of thumb to your use case.
1 Like
Hello @wojtek,
Yes, I agree with your views as you’re definitely more experienced as you’re the creator of this marvelous piece of software. With due respect to you, wanted to just share my opinion so that a person which considers “UX” to be at the top most priority would consider modelling withing 500K range.
Cheers !
2 Likes