Skip to content

Conversation

@Mugen87
Copy link
Collaborator

@Mugen87 Mugen87 commented Aug 28, 2025

Fixed #31764.

Description

The PR makes sure the WebGPU backend implements the render pipeline values for frontFace and cullMode like in WebGL backend.

@Mugen87 Mugen87 added this to the r181 milestone Aug 28, 2025
@github-actions
Copy link

github-actions bot commented Aug 28, 2025

📦 Bundle size

Full ESM build, minified and gzipped.

Before After Diff
WebGL 338.91
79.11
338.91
79.11
+0 B
+0 B
WebGPU 579.39
159.66
579.32
159.68
-71 B
+19 B
WebGPU Nodes 578
159.42
577.93
159.44
-71 B
+20 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Before After Diff
WebGL 470.78
113.9
470.78
113.9
+0 B
+0 B
WebGPU 649.54
175.53
649.47
175.55
-70 B
+23 B
WebGPU Nodes 603.64
164.67
603.57
164.69
-70 B
+24 B

@Mugen87 Mugen87 modified the milestones: r181, r180 Aug 28, 2025
@Mugen87 Mugen87 merged commit fd74f49 into mrdoob:dev Aug 28, 2025
9 checks passed
@WestLangley
Copy link
Collaborator

/ping @sunag

This PR causes breakage, and I would advise against changing the winding order convention at this late hour prior to a release.

TBH, I would prefer to continue with the convention @sunag established with WebGPURenderer, wherein front face winding order is always CCW. In that way, the front face is not ambiguous.

//

For example, consider the following color node when rendering transparent, double-sided materials:

material.colorNode = select( frontFacing, color( 0xff0000 ), color( 0x0000ff ) );

With this PR, the back faces will have the same color as the front faces. Transparent, double-sided materials render in two passes, with front faces and back faces rendered separately.

@sunag
Copy link
Collaborator

sunag commented Aug 29, 2025

Yes, the PR brings other implications. We can revert it and bring a more robust solution in the next release.

@Mugen87
Copy link
Collaborator Author

Mugen87 commented Aug 29, 2025

Agreed! Thanks for reverting.

But should when then consider to align the WebGL backend to the WebGPU one? Using negative scaling is currently broken as highlighted in #31764. Having at least a consistent response of both backends seems preferable to me.

sunag added a commit to sunag/three.js that referenced this pull request Aug 29, 2025
@WestLangley
Copy link
Collaborator

align the WebGL backend to the WebGPU one?

@Mugen87 Yes, that sounds like a very good idea.

But be particularly careful in testing bump mapping, which uses FrontFacingNode, which I expect will need to be modified. If front faces are extruded, back faces should be indented. Currently, I believe both backends are rendering bump maps correctly.

sunag added a commit that referenced this pull request Aug 31, 2025
#31784)

* Reapply #31769

* fix frontFace webgpu backend

* cleanup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WebGPU: Negative scale inverts front-face direction

3 participants