Performance Enhancements for Web Viewer

[kwokcb]

Performance Enhancements

• Add in dirty/refresh mechanism triggered by actions which require a re-render. Reduce big performance overhead of constantly re-rendering which can be quite slow for more complex shading models such as OpenPBR.
• Add in texture cache reuse using ThreeJS cache. Handle http/blob/data encodings properly.
• Add in sphere geometry as this is the lightest weight geometry performance-wise.

Implementation Changes

• Simple implementation of adding in a refresh counter which get's incremented when an action calls to "require an update".
• Refresh look still does constant polling but will only re-render if refresh counter is > 0.
• The actions where refresh requests are added include:
  • material, geometry load (menu or drag-drop)
  • texture load
  • transform changes: camera, viewport resize , turntable
  • background texture toggle

Note: There is no refresh queue management (e.g. compressing the number of requests) so that all camera, property edits, turntable updates are queued. This will never be worse than what occurs before this change and is thus as "safe" as before (no refreshes will be "list". Re-render is gated by how often ThreeJS triggers a refresh/render.

@jstone-lucasfilm : This makes OpenPBR not max-out the GPU on my laptop and should help a fair bit with scenes with more textures such as the chess set as the texture cache is used. Will also help drag-drop.

Example

• OpenPBR with negligible GPU usage (was 100% on my Windows laptop before, about 40% on a Mac M1).

[kwokcb]

Sounds like a good separation. Maybe let's table looking at why "render" has so much overhead. It could be draw time, it could be uniform bind time or state setup time or something else. OpenPBR is the slowest shader but std surface is also good for testing.

[kwokcb]

@jstone-lucasfilm, This is purely a texture caching update PR now.

[kwokcb]

Hi @jstone-lucasfilm, I added a "data" example that can be used in the viewer. The "blob" case I can't really make it show unless the viewer page was loading the data. (I just showed it in my own editor which uses the same URI support but has UI to support setting local images -- basically what Felix logged an issue for that MaterialXViewer could support).

[kwokcb]

I've packaged the http and data examples so it's available as part of the materials menu.

[jstone-lucasfilm]

@kwokcb Oh, I wasn't suggesting that you should add anything more to the set of fixes that I reviewed. I was just curious as to whether you had a generated web site where I could validate that the latest code worked well.

[kwokcb]

Ah. My mistake. I reverted the last push. I tried publishing the viewer page from branch but didn't have any luck.

[jstone-lucasfilm]

Thanks @kwokcb, and I'll give this a try in my own fork of MaterialX.