Hi guys,
I’m developing a 3D viewer using three.js.
Here it is GD viewer.
You’ll notice that the FPS drops when you zoom in on the bag.
My code (which is short don’t worry 
) is accessible here gd-viewer/index.js at b585200863fc5ad5589b03ff9c7b77a140b58c90 · theoavoyne/gd-viewer · GitHub.
Any idea of what can be causing that?
Hi!
Looks like it depends on complexity of shaders (fragment shader in this specific case).
Thanks for your reply @prisoner849.
So you’re saying that it has something to do with the model I’m importing? Maybe it isn’t optimised?
Partially - I may be wrong, but it’s probably more about the quality of the material on the model.
Fragment shader @prisoner849 mentioned is run for every pixel in which that specific material appears on the screen. When the model is zoomed out, the amount of pixels containing the model is quite small - and when you zoom in, fragment shader has to execute on almost every pixel of the screen.
First thing you may try is to lower the resolution of textures you’re using - right now all of your textures (incl. normal and roughness maps) are 8K, and that can be quite expensive to render (lowering normal and roughness maps to 1K-2K shouldn’t have significant impact on the looks of your model.)
There are several factors that are affecting your performance. The biggest one is that you’re drawing Sprites individually, taking up 141 drawcalls! Each drawcall takes a fraction of a second, so 141 of them will add up. You should group all of them together like in this example so you can render thousands of them in a single drawcall.
Other thing I noticed is high pixel ratio. A pixel ratio of 2 needs to render four times the number of pixels than a ratio of 1. This is also contributing to slowing down your framerate. I recommend you keep 1 if you’re going to use antialiasing.
Thanks @mjurczyk and @marquizzo, that helped a lot.
I reduced the resolution of textures and set the pixel ratio to 1. It’s now working way better (FPS stays at 60) and the quality of the result wasn’t even affected.
About the Sprites @marquizzo, yeah I knew when I did it that it wasn’t optimal. Yet it seems to be okay right now as execution time is like 2-3 MS on my Mac. Thanks for sharing the link to the example.
It’s also working great on my iPhone 11. However, when I tried to run it on an iPhone 7, it just breaks (both on Safari and Chrome) : the page is reloaded once and then the error message Couldn’t run the page is shown. I don’t have any more details on what could have happened. Any guess?
Thanks a lot for you time, it’s very very helpful!
Now it works way better 
