Node material compiling performance issue

[njarraud]

Description of the problem

I have been using the node material system in production for a bit now and one of the thing which is currently the biggest issue is the compiling time. It was somehow expected that it would take more time than the standard threejs system, but the difference is huge in an environment where materials are numerous and have to be updated often.

One of the longest operations is to build the fragment shader code especially when using an HDR environment map. This is a killer. In my case it takes 90% of the fragment code build time. Considering that the exact same operation is done over and over again for each material of the scene (most of the time all objects have the same environment setup), there is maybe something to to do to make the calculation only once and save almost 90% of the combined fragment shader code build times?

Example with my test material (environment, color, metalness, roughness, normal):

• 102 nodes including 82 nodes (~80%) for the environment input only!
• Fragment code build time: 5ms with an environment map and 0.5ms without

The difference between MeshStandardMaterial and StandardNodeMaterial is even more impressive. Example with my test scene including 100 different materials:

• MeshStandardMaterial: Compiling time of 3ms
• StandardNodeMaterial: Compiling time of 1.5sec including 500ms to build the fragment code!

In a CAD environment dealing with 1000s of different objects and with a material number that can be much bigger than my test scene, it is a really big deal. To switch between different viewport display settings it was taking just a few milliseconds which was invisible to the user while now it can take multiple seconds with the node material system.

I am not complaining, just reporting and maybe hoping to find some optimizations to make this system even more awesome.

/ping @sunag

Three.js version

• Dev
• r112

Browser

• All of them

OS

• All of them

[sunag]

Thanks to reporting this. I have some techniques to optimize this that still I not implemented... but I think that the first step could be create a NodeMaterial Profiling?

For now, you can attach the .json Performance profile of Chrome?

[njarraud]

Thanks, I actually didn't know about this. I'll check that.

[Mugen87]

After merging #19673 and NodeMaterial adapting Material.customProgramCacheKey(), it would be interesting to know if you could detect a performance improvement. The above changes can be verified in dev or with r119 (which is already released next week).

There might be no performance improvement for the actual compilation. But you should see faster execution times when the renderer has to check for a potentially required compilation in initMaterial().

[Mugen87]

Closing due to lack of feedback.