Issue with optimizing my GLTF file FPS low

Questions
, , ,
1

Hello all,

I’m having issues with a GLTF model. I have been optimizing the model as I normally would, but for some reason the FPS of this model is really bad.

I have a different model that I optimized which is a bigger size, more vertices etc. more draw calls but still runs normal 60FPS.

I have been trying already a lot of different things without luck.

Some of these things:

-Removing textures
-Changing materials
-Merging meshes
-Opening and saving in different Blender versions

Running the file through GLTFReport gives me this:

image
image1923×976 196 KB

But I can’t seem to find these unused_objects, I cleaned up literally everything in my Blender file and double checked everything (for as far as my knowledge goes) but as mentioned, no luck.

What other options do I have in trying to solve the issue?

The specs of my not good working model:

-DRACO size including all textures 6mb model alone compressed around 500kb
-21 Draws

  • VRAM 113.5mb
    -vertices 59.000
    -triangles 100.000

As mentioned the other model contains of everything more but runs at a normal 60fps

Thanks in advance for any pointers

2

Update and I guess partly solved. I just removed all my materials and the FPS is good now, so I just have to go carefully through my materials and see which material(s) have the biggest impact on the FPS.

3

I would check the resolution of your textures, and any glTF extensions (e.g. KHR_materials_specular) being used in the asset and on your materials.

  • KHR_materials_unlit — Creates unlit/shadeless materials using THREE.MeshBasicMaterial. Cheapest default three.js material, but doesn’t support lighting.
  • KHR_materials_{specular,ior,transmission,...} — Creates advanced PBR materials using THREE.MeshPhysicalMaterial. More expensive (per pixel drawn to screen) than other three.js materials, and each of these extensions can add features and cost. Can easily cause your app to become fragment-shader-bound, especially on mobile devices.
  • No material extensions — Creates PBR materials using THREE.MeshStandardMaterial, cheaper than MeshPhysicalMaterial but more expensive than THREE.MeshBasicMaterial. Performance can be good enough for mobile devices, but still use caution using this material for the entire viewport on mobile devices.
4

It turns out that the ‘transmission’ property on 1 of my materials caused this drop in FPS, literally switching this to ‘0’ brings the FPS back up. Is this normal? I used transmission before, the only difference is that I’m using it now on a texture of 512x512 that is tiled as a pattern on my model.

Am I doing something wrong or is this impact normal?

5

Transmission is an expensive effect, yes, and would force GLTFLoader to create MeshPhysicalMaterial
rather than MeshStandardMaterial. Transmission will cost more or less depending on the amount of screen area occupied by the transmissive surface, and the draw cost of the rest of the scene, since it requires an additional render pass. It’s considerably more expensive than alpha blending or alpha hashing. I’m not aware that the use of a texture would make much difference here, but perhaps it could.

1 Like
6

Also – if your scene happens to be CPU-bound (lots of draw calls, and transmission doubles them) then it’s likely that an upcoming release will improve the situation with WebGLRenderer: Proof of concept for copying transmission pass, improving rendering performance by gkjohnson · Pull Request #28423 · mrdoob/three.js · GitHub.

This optimization will not help with fragment-shader bound applications, where the device GPU cannot evaluate MeshPhysicalMaterial fragment shader quickly enough, however.

3 Likes
7

Thanks for sharing, that will be interesting to test by the time it is released. For now I think I just need to redesign some of my materials.