-
-
Notifications
You must be signed in to change notification settings - Fork 35.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce FramebufferTexture. #22916
Conversation
Very nice! |
Thanks! |
material.roughnessMap.repeat.copy( roughnessMap.repeat ); | ||
material.roughnessMap.center.copy( roughnessMap.center ); | ||
material.roughnessMap.rotation = roughnessMap.rotation; | ||
material.roughnessMap.image = roughnessMap.image; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed it since the image
property from the original roughness texture should not overwrite the image
property of a framebuffer texture. Both are actually different.
Sorry, I wasn't aware that my original solution did still need it. I've thought the instance of FramebufferTexture
is just the target that holds the data from the framebuffer but is never used as a source texture in RoughnessMipmapper
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, if you look at the linked PR, the issue is when you go to export the scene. USDZExporter uses the original image, and even though we're tweaking the roughness here to account for the normal map, you want the original roughness map to go through. Also, since this only has width and height, it just fails to export since it can't actually find an image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably add a comment in that line so we don't remove it again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, let me file a PR that adds the line back.
Related issue: -
Description
The current usage of
WebGLRenderer.copyFramebufferToTexture()
is incorrect and also incompatible withgl.texStorage2D()
.When copying data from the current bound framebuffer to a texture, the texture itself does not need any data definitions. So no call of
gl.texImage2D()
is required. It's sufficient to bind the texture and then callgl.copyTexImage2D()
.gl.copyTexImage2D()
is incompatible with immutable textures so callinggl.texStorage2D()
is not required and wouldn't work anyway (sincegl.texStorage2D()
defines immutable texture storage).Since it is not possible right now to properly process a texture in
WebGLTextures
which was updated viaWebGLRenderer.copyFramebufferToTexture()
, a new type of texture (FramebufferTexture
) is introduced.