Hi,
I am uploading a 3d model (gltf) and when we interact (zoom, rotate…etc), the frame rate (fps) keeps dropping. How can we render the camera view only instead of the full model?
Any suggestion please?
Thank you
There is no easy way of solving this. A typical approach is to design a large model such that it consists of independent components. Think of designing a house not as a single entity but as a collection of doors, floors and so on. In this way, the renderer will process each items separately and thus is able to cull them if possible (if they are outside of the view frustum).
The problem of this approach is the fact that you increase the number of draw calls which could introduce a new performance bottleneck. So you need to find a good balance.
How big and complex is that model?
I have displayed many somewhat complex models in three.js and they all run at 60 fps.
Here is one of mine for comparison purposes:
FM-2 Wildcat in skybox
The FPS are shown in the lower right. This runs consistently at 60 fps.
One example that displays at less than 60 fps on some computers is:
B-29 in skybox with low clouds
The reason is that the clouds consist of several thousand identical sprites. Also, note that the aircraft surface is reflective.
I have other examples, including a flight simulation (emulation?) with a complete aircraft interior with animated working gauges. It has two separate models - an internal model and an external model. You can switch from one to the other and make the other “disappear”.
Rotating and zooming has no effect on these frame rates. I generally use a simple set of equations to “orbit” around the aircraft and have the camera “look at” the aircraft.
If you are designing models to be displayed over the internet, you would not want to make them too large - or they would take forever to load. I believe that 5,000kb is the suggested limit. All of these models are below that limit.
Thank you for the explanation.
The model size is usually between 25MB-35MB (a building with three towers and every tower about 60 floors), Triangles: 191.7k and Vertices: 160.5k. We tried to reduce the size but looks like very difficult for this model. Maybe we need some other optimization technique.
When I add animation/zoom using TweenJS, it also keeps shaking.
Given that file size, your best approach appears to be, as Mugen87 suggested, to use independent components. Not having seen the models, it would seem that there is a lot of opportunity to do so. For example, when viewing the buildings from the outside, it seems that a lot of the interior would be hidden (unless you are using some kind of cutaway view). If hidden, you could use very primitive interiors. Even if you get up close to a particular floor, the rest of the floors would still be hidden from view. You might be able to standardize the floors - using a few basic versions for each building. You could add small embellishments to make each floor different. Three.js can easily handle the task of placing these floors in the building.
Another technique used to improve render speed to to create models or floors with different levels of detail (LOD). This approach swaps in low or higher poly models depending on your distance from the object.
Finally, and this may not be an issue for you, the biggest contributor to file size in my models has been textures. If my recollection is correct, saving a file in glb can result in the same texture being added to your files multiple times. I was able to solve this by breaking the textures into separate files based on parts. However, if you have to several parts that access the same texture file, you may want to use gltf, which does not compress and store textures with the program.
Hello,
This might sound like a dumb question, but do you try to refresh the image on camera changes instead of requestanimationframe?
I had made such a mistake once with a large mesh, it would be displayed smoothly at ~55fps, but when I interacted with the scene it dropped because the camera change would make hundreds of render calls.
1 Like
Ngc, sorry for the delay in responding.
In my programs, I just used the standard requestanimationframe and I had not noticed any big drop in frame rate due to camera changes.
But perhaps my programs were running fast enough that they always exceeded 60 fps, even when there were camera changes, and were thus always displayed at 60 fps.