Shader compile error with troika-3d-text

[protectwise]

Shader compile error with troika-3d-text

[lojjic]

Thanks for the patience; I've published v 0.28.1 which should fix your frame rate issue. Please reopen if that's not the case. :)

[giulioz]

(Sorry for the very long error log)

[giulioz]

I found out that this only happens when using the postprocessing library, when enabling the instancing workaround.

[giulioz]

The reason this is happening is because of this part:

  // Handler for automatically wrapping the base material with our upgrades. We do the wrapping
  // lazily on _read_ rather than write to avoid unnecessary wrapping on transient values.
  get material() {
    let derivedMaterial = this._derivedMaterial
    const baseMaterial = this._baseMaterial || defaultMaterial
    if (!derivedMaterial || derivedMaterial.baseMaterial !== baseMaterial) {
      if (derivedMaterial) {
        derivedMaterial.dispose()
      }
      derivedMaterial = this._derivedMaterial = createTextDerivedMaterial(baseMaterial)
      // dispose the derived material when its base material is disposed:
      baseMaterial.addEventListener('dispose', function onDispose() {
        baseMaterial.removeEventListener('dispose', onDispose)
        derivedMaterial.dispose()
      })
    }
    return derivedMaterial
  }

The postprocessing workaround changes the materials of all the meshes every render two times: https://github.com/vanruesc/postprocessing/blob/master/src/core/OverrideMaterialManager.js

[lojjic]

Ah I see, so it essentially ends up doing...

let mtl = textMesh.material
...
textMesh.material = mtl

I can see how that would end up double-deriving the material. Should be a simple fix, I just have to check whether the incoming material is already a derived text material.

@giulioz Do you happen to have an online example using your particular postprocessing setup that I could test this with - a Codesandbox or something?

[giulioz]

I tried to replicate a similar situation with react-three-fiber and I got even another kind of error: https://codesandbox.io/s/troika-text-pp-bug-ymsv1?file=/src/index.js

[lojjic]

That codesandbox is using an old version, that shadowSide bug was fixed already.

I've just published version 0.28.0 which I think should fix your postprocessing error, give that a try and reopen this ticket if there's still an issue.

[giulioz]

My fault, I forked from another sandbox and forgot to update...
I updated the sandbox and now it exhibit the bug: https://codesandbox.io/s/troika-text-pp-bug-ymsv1?file=/src/index.js

I'll let you know if 0.28.0 fixes the bug, thank you very much in advance.

[giulioz]

The fix works but it slows down everything. The profiler shows that a lot of time is spent in shader program compilation (getProgramInfoLog).
The debugger shows that createDerivedMaterial gets called every frame, is this right?

In the material getter it enters this branch when rendering the normals for postprocessing:

[lojjic]

Hmm, yeah I suppose that makes sense if postprocessing is assigning a different MeshNormalMaterial instance every frame. The createDerivedMaterial utility will cache by base material instance, not by material class, so if it's not using the same material instance each time it will re-derive.

Still, though, ThreeJS's program management should reuse a webgl program if the shader content isn't changing, so there must be something I'm doing that causes slightly different shader content each time. I'll look into that.

[lojjic]

Ah yes, the rewritten shaders use an id to disambiguate certain things. That id is different per base material, hence the resulting shaders are different.

This could be a tricky one to fix without breaking other things. If you could still provide a testcase for me that would be very helpful.

[giulioz]

I've updated the Codesandbox (https://codesandbox.io/s/troika-text-pp-bug-ymsv1).
If you put a breakpoint in createTextDerivedMaterial (textmesh-standalone.umd.js:5944) you can see it's called every frame.

[lojjic]

@giulioz Thank you for that CSB example, that's perfect. I've been able to reproduce it locally using that and I have a tentative fix that seems to be working. But this derived material logic is pretty finnicky/fragile so I'm going to put it through its paces during my day job work for the rest of the week, before pushing it out. Hope that doesn't hold you up too badly.

[giulioz]

No problem! Thanks for the assistance and your hard work on this amazing library :)