You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SplatAccumulator saves and restore the current render state. However, for the render target it only recorded the target itself and not the active cube face or active mipmap level. This caused a regression in the envMap example, where the resulting envmap does not have all its faces rendered, as can be seen by the "black" reflected in the duck model.
It would be nicer if SparkRenderer.renderCubeMap could ensure that the splats are only updated once, instead of once per cube face. That said, this bugfix would still be needed in any situation where the current render target has a non-zero cube face or mipmap level.
@mrxz I actually intended for renderCubeMap to not update for each cube face. I guess if autoUpdate is turn in you would indeed update 6 times potentially.. I usually try to steer people to have a separate SparkRenderer to use for things like rendering environment maps. In that case there is a single .update() that is awaited inside the renderCubeMap and the 6 renders should be from the same update step.
I actually intended for renderCubeMap to not update for each cube face. I guess if autoUpdate is turn in you would indeed update 6 times potentially.. I usually try to steer people to have a separate SparkRenderer to use for things like rendering environment maps. In that case there is a single .update() that is awaited inside the renderCubeMap and the 6 renders should be from the same update step.
The envmap example does use a separate SparkRenderer, but since autoUpdate defaults to true it still ends up with this problem. We should probably update the example to disable auto update and document this aspect of renderCubeMap as I can easily see users run into this issue.
Ideally I'd like to see renderEnvMap, renderCubeMap and renderTarget becoming obsolete as they are quite opaque to the user. It'd be nicer IMHO for users to write these how they'd normally would in vanilla Three.js with only the relevant additions needed for Spark (e.g. .update()).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
The
SplatAccumulatorsaves and restore the current render state. However, for the render target it only recorded the target itself and not the active cube face or active mipmap level. This caused a regression in the envMap example, where the resulting envmap does not have all its faces rendered, as can be seen by the "black" reflected in the duck model.It would be nicer if
SparkRenderer.renderCubeMapcould ensure that the splats are only updated once, instead of once per cube face. That said, this bugfix would still be needed in any situation where the current render target has a non-zero cube face or mipmap level.