Severe performance penalty using the materials generated by glTFast compared to HDRPs default lit material

[ItsCubeTime]

Severe performance penalty using the materials generated by glTFast compared to HDRPs default lit material

Try importing the glb in the following zip file: https://u.teknik.io/C7WFD.zip (the glb was generated by Blenders glb exporter, in Blender version 3.0.0 beta) using glTFast in a HDRP Unity project.

Use the same textures provided in the glb to create a Unity default lit shader:

(in a HDRP project, just creating a new material by right clicking in the content browser should give you just that).

Now drag several copies of the provided mesh into the scene, try switching between the material you created manually using HDRPs default Lit shader and the one generated by glTF.

You can switch between the 2 shaders easily at runtime using this script:
https://u.teknik.io/7PYM3.cs (attach it to an empty in your scene and select the materials you wanna switch inbetween in the inspector, then use E R & T at runtime to switch between them).

When switching between the 2, you should see a major performance impact when looking directly at the mesh, if you dont, try disabling VSync or drag more meshes into the scene.

Note that the glTF shader uses alpha clipped (binary transparency) transparency, however the performance penalty is about the same for a glTF shader that doesnt use alpha at all.

I can see the same performance penalty both in the Unity editor and in packaged builds for Win64_86 (running on a 64 device)

Expected behavior
For the shaders to be useable in our projects, they would need to have a close-to-0 performance penalty compared to HDRPs default lit shaders (I could maybe spare 2-5 fps at most, but it would be even cooler ofc if it was on pair or faster!).

Screenshots

UhjDSAHak7.mp4

Desktop (please complete the following information):

• glTFast version master branch from10/25/2021
• Unity Editor version 2020.3.22f1
• Render Pipeline and version HDRP 10.7.0
• Platform: Win64_86 build (running on a 64x machine) as well as in Win64 editor.

additionally (if significant for the bug):

• Device: GTX 1060 6gb
• OS: Win10

[ItsCubeTime]

@atteneder please let me know if you need any more information or if you come to a conclusion on how patch-able this is (or if I can apply any workaround without having to setup my materials by hand).

Im also available through Discord danieljackson#0286 .

[atteneder]

Hi @ItsCubeTime ,

Thanks for the excellent report. Sorry it took me so long, but I was already working on re-newing the shader graphs back then, so I knew I want to test performance with the newer shaders.

I couldn't load your script, but I compared manually and noticed a 5-10% performance drop (macOS Editor Metal), not nearly as drastic as yours.

My materials (glTF and Lit) look identical though. Maybe there's some difference in the setup?

Feel free to share your Lit based material and test again with glTFast 4.5.0 (soon to be released)

[ItsCubeTime]

Hi @ItsCubeTime ,

Thanks for the excellent report. Sorry it took me so long, but I was already working on re-newing the shader graphs back then, so I knew I want to test performance with the newer shaders.

I couldn't load your script, but I compared manually and noticed a 5-10% performance drop (macOS Editor Metal), not nearly as drastic as yours.

My materials (glTF and Lit) look identical though. Maybe there's some difference in the setup?

Feel free to share your Lit based material and test again with glTFast 4.5.0 (soon to be released)

The performance difference only became obvious once you had enough overdraw (faces stacked behind eachother within the camera view frustum). If you just put a plane covering your screen I only saw like a 2-3 fps drop.

I guess one could argue the amount of faces used in my example is rather extreme. But once you have a few million polygons in your scene (which is normal for modern games of today) I could see this becoming an issue.

But if I were to guess the cause, maybe you've used some vertex shaders that might be a little on the expensive side compared to what Unitys default shaders use?

[atteneder]

I tried to create decent overdraw.

Anyways, guess we'll have to wait for 4.5.0 to compare again. I have some remaining issues to fix first.

[RandomFloat]

I would suggest to just get rid of any handmade shaders and go with what Unity is offering.
At my company we use a very old version of GLTFast (1.1.1) and it actually uses the proper Unity Lit-Shaders. This was done to keep the shaders fully working with every feature that Unity has to offer and to be future-proof.
It's very easy to do by coping around the pixels in the textures and enabling the proper keywords.
We do that in RT on a quest 2. So no worries that it would somehow overload anything. Less hand made stuff is always better.
[if you need help with that i can help you and give you some examples]

[atteneder]

@RandomFloat Thanks for your input!

The custom shaders won't go anywhere soon, but I'm certainly open to add alternatives. In fact I planned to import to Standard/Lit for Editor import and would be curious if it ports well to RT. The main reason for custom shaders was to avoid channel swizzeling the textures at runtime.

Detailed insights or active help in implementing this is always greatly appreciated.

[atteneder]

Hi @RandomFloat and @ItsCubeTime ,

I had another look at this issue and I found the main problem. The difference is how Jpeg/PNG textures are imported at runtime (or in Editor imports, if they're embedded in a .glb file):

1. The default setting is to not create mipmaps (at runtime; in the Editor they are enabled by default since version 4.8.0). While not creating mipmaps yields faster texture loading, rendering becomes much slower (11 instead of 60 fps)!
2. They get decoded into an uncompressed format, which is also slower than compressed DXT1/DXT5

Tested this on a 2019 MacBook Pro / Unity 2022.2 and both URP and HDRP (Play Mode).

Solutions:

• Mipmap creation is an import setting glTFast offers.
  • For Editor (design-time) import make sure it's enabled (which is the default since Fix: design-time import should use Mecanim by default and generate mipmaps #388 and 4.8.0).
  • Runtime import via GltfAsset component: since glTFast 5.0.0 you can enable mipmap generation in the inspector.
  • Runtime import via script: set GenerateMipmaps to true

I'm closing this now. Feel free to re-open or open a new issue if the performance struggle persists.

[ItsCubeTime]

Interesting insights, didnt know texture mipmaps could matter so much assuming the full res versions of the textures would still have to be loaded somewhere during runtime?