PMREMGenerator: Fix usage with PMREMNode
.
#31001
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue: -
Description
Two or more PMREM nodes might refer to the same source textures. This use case currently works just for the first PMREM node since the second one produce a runtime error that can be reproduce with webgpu_materials_envmaps_bpcem. Just unselect the checkbox "box projected" and check the browser console:
That happens because every PMREM node has its own
PMREMGenerator
. The render targets used for generating the PMREM are cached and managed globally for the source texture. Meaning if the second generator wants to re-generate the PMREM, its internal state isn't ready. The PR fixes this issue by renaming_allocateTargets()
to_allocateTarget()
and just use the method for allocating the destination render target. A new_init()
method makes sure internal resources (e.g the LOD planes or the blur material) are created if not ready. Exactly these resource were missing in the second generator and produced the above runtime error.