How we improved our 3D web viewer performance

First of all, one of our core values is universality. This is something we really care about as we want the content made with our tools to be easily accessible and seen by anyone. It was already the case, but sometimes, depending on your computer or mobile, the rendering of some 3D interactive content could be painful for your machine leading to some uncool results such as your computer fan which becomes crazy or your mobile battery which dives.

Even if it was really occasional we needed to do something about it so that our contents stay fully universal!

But what did we exactly improve?! In order to follow the improvements made, we will be following how is evolving CPU (Central Processing Unit), and GPU (Graphics Processing Unit) usage, plus the browser Scripting and Rendering times. With the former viewer, we had this:

‍

First trick: Reduce FPS

FPS means Frame Per Second. A frame is when an engine will make all the calculations about your 3D scene. Because every time something changes in your scene, the engine needs to check what is impacted in order to be able to render the new result. For instance, if you change the position of a light in a 3D environment, every object in the scene will be impacted by that change and so you need to redo almost all the calculations at each time.

‍

Usually, the screen's pixels are updated at 60 FPS. So your machine will calculate everything 60 times per second and this can quickly become really hard to execute when your 3D content is a bit complex.

‍

While surfing on the web, searching for interactive content and inspiring stuff, we found some use cases where the website uses a list of images in order to simulate 3D animation. This is the case of the Airpods pro website made by Apple (Read our article about it)
If you go slow on the scroll you can notice the experience is not very fluid, you will see the image changing frame by frame. However, it is still really cool to explore the page and have those interactive animations. Following those observations, we found out that the frame rate wasn’t that important and, therefore, we decided to try to render at a lower frame rate, more specifically at 30 FPS!
Did you know that our brains (our very own engine) are able to process between 20 and 25 images per second? So, 30 FPS is enough to have a comfortable experience. By doing so, we also noticed that counter-intuitively, lowering the FPS made the experience sometimes smoother. Since there is much less strain on your computer, this one can better focus on those 30 FPS.

Now, if we make our performance test again, we can already observe some great improvements, with a drop of 1/3 in CPU usage and a split by half of the browser scripting and rendering:

Second trick: Render only when necessary

Everything might sound obvious here but it’s still worth to explain. When displaying such interactive content online, you usually push it at some specific places on your website but it’s really rare that you cover your whole website with this kind of content. Knowing this, it isn’t required to render it all the time then. So, now we only render your Naker’s content when the visitor arrives on your interactive content and it stops rendering when it is no more displayed on his screen.

‍

One more thing we changed in Naker’s editor in order to provide a better viewer performance is that we limited the interaction of your 3D objects to the mouse movement and scroll. That way when the visitor isn’t interacting with your content while this one is still visible, we stop the rendering and we replace it with a static image that needs no calculation instead (no worries the visitor won’t see anything of it, the result remains the same).

Let’s have a look at our performance again. I made a simple test where I simulate a user who sees the interactive content only half the time he is spending on a website. Again we can observe big improvements since the CPU and GPU usage is split by half:

‍

Third trick: Separate threads

What is a thread? On your computer, you have a processor. In this processor, you can have several threads making calculations simultaneously. For instance, when you play a game on your computer, it has access to all the threads (multithreading) of your processor which gives a lot of flexibility to game developers. They can indeed separate different processes that may need a lot of resources and this allows to remain effective. In our case, since we are web-based and not computer-based, our main technical difficulty is to render 3D in your browser with only one thread available. This is mainly for security reasons and unfortunately, none browser can use several threads at the same time:

‍

Nowadays, this is the main reason why you aren’t able to play the game Star Wars: Fallen Order in your browser, at least not very soon but someday.

‍

But that’s not all! When you play a game, your computer or mobile is only focused on that specific task. However, in your browser, there is a lot of things going on at the same time, so, a lot of resources are already needed.

If you wish to deepen the subject, I suggest checking this great list of article written by Mariko Kosaka : Inside look at modern web browser

What’s our solution? we found a way to improve that and it’s called “offscreen canvas”. Behind that name stand a new feature brought by the Babylon.js team (BabylonJS is the engine we use to render 3D in your browser). Indeed they added a way to separate the rendering of the 3D scene from the browser. This is not Multithreading BUT it still allows to greatly improve performance.

‍

Your computer or mobile will be a lot happier to be able to manage the 3D content in a separate thread from the browser. It will greatly help to have both the browser and the content staying fluid all the time while gaining in performance!

At last, let see how this new optimization will improve our performance. The CPU and GPU usage haven’t changed but the scripting and rendering time are significantly decreasing and eventually match with a classic usage of the browser as if the complex 3D stuff wasn’t there!

‍

Conclusion

By doing all of this, we manage to divide by 3 our usage in CPU and GPU and divide by almost 10 our use in browser scripting and rendering, which is HUGE!

Moreover, we also improve the easiness and smoothness of any interactive content rendered with Naker. That way, the content becomes more universal than ever since all the machines are able to render the content without any trouble. Icing on the cake, it saves energy, battery and much more which is great for our planet!

Contact us to start!

‍