WebGPURenderer: PMREMGenerator - calculate blur weights and parameters once #29900
Conversation
📦 Bundle sizeFull ESM build, minified and gzipped.
🌳 Bundle size after tree-shakingMinimal build including a renderer, camera, empty scene, and dependencies.
|
|
/ping @elalish |
|
I guess it's fine if it creates the same pixels. I didn't write that TODO, so I'm not sure what this refactor is for. I generally hope for a refactor to result in less code rather than more. If other folks think this is more clear, then go for it. |
|
One advantage is with dynamic PMREM generation, the weights array is created and weights recalculated every frame, this removes these repeated operations and some others. Eg webgpu_cubemap_dynamic example. |
|
@sunag @Mugen87 are either of you going to review / merge this PR? I don't know enough about the coding style you're moving towards to give any useful feedback here (is userData a normal place for state to live now?). However, this seems useful and I'd also like to do some refactoring of PMREM, so it would be great if this was either merged or rejected so I can avoid a bunch of conflicts. |
| const blurUniforms = blurMaterial.uniforms; | ||
| const { _lodMax } = this; | ||
|
|
||
| const sigmaRadians = Math.sqrt( this._sigmas[ lodOut ] * this._sigmas[ lodOut ] - this._sigmas[ lodOut - 1 ] * this._sigmas[ lodOut - 1 ] ); |
There was a problem hiding this comment.
Hmm - is this right? The cache is based on lodIn, but the sigmas we're saving are based on lodOut. Sometimes they are the same and sometimes they are not, based on how halfblur is called. And does this all continue to work when a PMREM is generated with a different size?
|
Okay, I understand this PR now, as well as a couple of minor issues - if you don't mind I'm going to incorporate this with some modifications into my own refactor: #30165. |
Address TODO and uses userData() instead of material uniforms for per pass constants.