Threejs V2

[Makio64]

Description

When I'm talking with other webgl dev about the WebGPURenderer, I see it's really confusing peoples as they often think it's only WebGPU ( as the name suggest ) when it's actually embedding both backend ( WebGL2 + WebGPU ) and also forcing to use the node material system ( bye chunks! )

To explain these breaking changes I started to refer it as a Threejs.v2 with new concept and new way to develop shader/material and it's much easier.

I think advertise it as a v2 will help the adoption, boost visibility and make all the new concept less confusing

Solution

Advertise it as Threejs V2

• Add a page with the new concepts introduce here
• Add the new Node documentation
• Celebrate somehow with cool demo or other stuffs :)

Alternatives

Find a way to make this concept of backend less confusing ,

• Update the documentations with at least the WebGPURenderer
• Add a page with the new concepts introduce in WebGPURenderer
• Maybe the name WebGPURenderer is actually the fault here ?

Additional context

Interested to know what you think about it :
@mrdoob @sunag @Mugen87 @RenaudRohlinger

[RenaudRohlinger]

I agree with the concept of a "V2" for Three.js. However, the WebGPURenderer’s primary purpose is to bridge us into the WebGPU era. The WebGL fallback is not meant as a V2 of the WebGLRenderer but as a transitional aid for smoother adoption, and I expect this fallback to become obsolete and likely deprecated as WebGPU gains standardization.

Recent updates, like the latest iOS beta enabling WebGPU by default, indicate accelerating WebGPU adoption. Major browsers are signaling strong intent to implement WebGPU quickly, and with support from Safari and iOS that seems to be already enabled by default on the latest 18.2 beta of iOS, we could see 80%+ browser coverage by the end of 2025. Likely, only developer-focused platforms like Firefox and Linux may lag behind. By this point, developers will recognize WebGPU as the next generation for Web 3D graphics, naturally positioning the WebGPURenderer as "Three.js V2."

The node material system and compute shading pipeline are definite strengths of the WebGPURenderer, but the WebGL backend will likely continue to lag, particularly for compute shading. Emulating such features in WebGL2 using double array buffers and PBOs imposes substantial performance limitations. For developers needing GPGPU in WebGL2, the classic WebGLRenderer with DataTextures remains a more efficient and practical approach.

In summary, while the WebGPURenderer introduces exciting new paradigms, it should be seen as a forward-looking tool focused on WebGPU. As adoption grows, its natural alignment with WebGPU will reinforce its place as "Three.js V2," making these new concepts more intuitive and accessible over time.

[sylwesterdigital]

The idea of rebranding the WebGPURenderer and its associated changes as Three.js V2 might seem appealing at first, but it risks creating confusion and fragmentation in the ecosystem, as we’ve seen in other software transitions. While the intention is to clarify and advertise the new features, calling it V2 could have unintended consequences:

1. Fragmenting the Ecosystem:

   • Splitting the community between "Three.js V1" and "Three.js V2" creates an implicit divide. Developers using V1 may feel left behind or pressured to transition, especially if the focus shifts heavily toward V2. This could result in unfinished migrations, abandoned projects, or unnecessary tension between the two approaches.
   • Consider the AngularJS to Angular transition: despite Angular (V2+) being technically superior, the abrupt change left many projects stuck on AngularJS or entirely abandoned.

2. Backward Compatibility Concerns:

   • Branding this as "V2" implies a significant departure from existing paradigms and workflows. It could signal to developers that backward compatibility is no longer a priority, leading to hesitancy to adopt Three.js in the long term. Many developers rely on stability and gradual evolution, not revolutions.

3. Perceived Obsolescence of V1:

   • By emphasizing V2, the current version (what is now Three.js) may be seen as outdated or second-class, even though it is still highly capable and widely used. This is particularly concerning for developers maintaining large-scale legacy projects who may lack the resources to migrate.

4. Risk of Over-Promising:

   • Rebranding this as "V2" suggests a polished, stable new era for Three.js. If the WebGPURenderer and its new concepts are not fully mature (documentation gaps, edge-case bugs, incomplete support for existing use cases), it could lead to disappointment and damage the library's reputation.

5. Adding Complexity Without Clear Benefit:

   • The current name, WebGPURenderer, already conveys its purpose as a renderer option. Rebranding as V2 introduces additional cognitive load for developers, forcing them to distinguish between "V1 workflows" and "V2 workflows." This might be unnecessary, as the WebGPURenderer could simply evolve alongside the rest of the library.

6. Dependency Hell and Community Expectations:

   • A "V2" label could lead to a rapid deprecation of older practices, forcing contributors and plugin developers to scramble to update their tools. This creates unnecessary churn and alienates parts of the ecosystem, as seen with the Python 2-to-3 migration, which caused years of fragmentation.

---

Alternative Suggestions

Instead of branding it as Three.js V2:

• Enhance the Messaging Around WebGPURenderer:
  Clarify its role as an additional, optional renderer rather than a replacement for the current WebGL renderer. Improved documentation and clearer naming (e.g., HybridRenderer) could reduce confusion.

• Focus on Incremental Evolution:
  Emphasize that the node material system and WebGPU support are forward-looking but coexist with the current chunk-based system. This avoids alienating developers while allowing them to adopt new paradigms at their own pace.

• Dedicated Marketing and Documentation:
  Create a standalone "WebGPURenderer" section with new demos, tutorials, and materials to showcase its power. Celebrate it as a major milestone without tying it to a version number that implies ecosystem-wide change.

By keeping the focus on evolution rather than revolution, Three.js can maintain its strong, unified community while introducing powerful new concepts without the baggage of a "V2" rebranding.