Rename `WebGPURenderer` to `Renderer`.

[Mugen87]

Description

After working with WebGPURenderer for a while now and after observing how the community approaches it, I think the name WebGPURenderer is no good choice for what that thing actually is. I've seen this differently in the past but in the meanwhile, I do think the name should be Renderer.

When I initially worked on WebGPURenderer, the name was fine because it always targeted WebGPU. When WebGL support was added as a fallback, I also understand why WebGPURenderer wasn't renamed because to emphasize the usage of WebGPU.

However, this name does not make clear that WebGPURenderer is actually a universal renderer than can target different backends. It's more of a terminology thing but it is important since different expectations form in the developer's mind. We shouldn't talk about WebGL as a fallback but as a viable backend option for rendering. Hence I would suggest to:

• Rename the internal Renderer class to AbstractRenderer (or BaseRenderer).
• Rename WebGPURenderer to Renderer and let it derive from AbstractRenderer.
• Rename src/renderers/webgl-fallback folder to src/renderers/webgl and avoid the "fallback" terminology completely.
• Rename the existing src/renderers/webgl to src/renderers/webgl-legacy (it's the directory for WebGLRenderer).

This will also better reflect the long-term strategy to have a single renderer with multiple backend options. By default, the renderer picks the best available option but the developer has the freedom to choose/force the preferred backend.

Solution

Rename WebGPURenderer to Renderer.

Alternatives

Keep the name as it is.

Additional context

No response

[Makio64]

100% agree WebGPURenderer is a confusing name and hide the fallback system as you mention but i think Renderer might also lead to confusion.

WebGLRenderer -> WebGLRendererLegacy to accentuated its a Legacy version ?

WebGPURenderer -> GPURenderer-> renderer working in gpu , opposed to the css3d /svg/ etc.. renderers ?

[Mugen87]

but i think Renderer might also lead to confusion.

Do you mind explaining why you think that?

WebGPURenderer -> GPURenderer-> renderer working in gpu , opposed to the css3d /svg/ etc.. renderers ?

I'd like to avoid any backend related terms in the name. Naming it GPURenderer is the same like e.g. GLRenderer. The renderer can do both and the name should reflect that. Hence the more common name Renderer.

The more specific addon renderers are an exception and shouldn't be a guideline for the core renderers, imo.

WebGLRenderer -> WebGLRendererLegacy to accentuated its a Legacy version ?

To avoid migration tasks I would suggest to not rename WebGLRenderer. At least at this point.

[Mugen87]

My point is: When looking at the webgpu_* examples, I have often noticed we don't do anything WebGPU specific. Even our shaders are now expressed in a backend-neutral syntax. Apart from certain compute and render bundle demos, there are hardly any references to WebGPU. Basically, this is code that could run on any native 3D backend. Hence, the more common name Renderer seems a more appropriate fit to our new approach.

Ideally, most users don't care on what backend the code is executed. The engine picks the best available one and that's it. Advanced users which require more control can still target specific backends or even write native shaders. But I do think this will be the exception. In most cases, custom shader code will be expressed as TSL and it won't matter on what backend it is executed.

[mrdoob]

The WebGL fallback is temporary.

It's there just to help people start using WebGPU (and TSL) without having to worry about Firefox and Safari lack of WebGPU support.

However, even after Firefox and Safari add WebGPU support, there will still be many devices that will never support it and the WebGL fallback will still be needed.

WebGPU Compatibility Mode tries to address that issue and I'm hoping it'll eventually make the WebGL fallback redundant.

Once the WebGL fallback is removed from WebGPURenderer, we could turn it into WebGLRenderer, and may be that's howe we could end up with TSL support in both renderers...

I can definitely see how it's confusing right now, but I feel like it'll be much more clear in one year.

[Mugen87]

Once the WebGL fallback is removed from WebGPURenderer, we could turn it into WebGLRenderer

Um, why would rename a renderer that has nothing to do with WebGL to WebGLRenderer? In this case, I would expect it to be WebGPURenderer(because it only supports WebGPU and WebGPU Compatibility mode). Anything else seems highly confusing to me...

[mrdoob]

Sorry, that part of the explanation was confusing indeed.

What I meant was that we could turn the WebGL fallback code into WebGLRenderer depending on where things are at.

WebGPURenderer would remain WebGPURenderer and only support WebGPU.

[DennisSmolek]

I've been saying this for a while now too. I think there is a lot of confusion about it being "Only" WebGPU but with the fallback architecture the whole point is that it will be the new Renderer. In the future too as to @mrdoob's point, if something like WebVulkanRenderer or WebFutureSpaceLaserRenderer comes out it can all map to the core Renderer object.

Instead of it being a fight vs WebGLRenderer and WebGPU in general its the Old Vs the new

[mrdoob]

In the future too as to @mrdoob's point, if something like WebVulkanRenderer or WebFutureSpaceLaserRenderer comes out it can all map to the core Renderer object.

What if the core Renderer is not a good abstraction in the future? What if the in the future there's only (say) Gaussian Splats? Do we have to keep Mesh? Then we have to remove API because it's no longer relevant. I think that would more confusing.

I know it's confusing now, but it's a confusion I can imagine. I'm just afraid of a confusion we could have that I can't imagine.

[DennisSmolek]

In the future too as to @mrdoob's point, if something like WebVulkanRenderer or WebFutureSpaceLaserRenderer comes out it can all map to the core Renderer object.

What if the core Renderer is not a good abstraction in the future? What if the in the future there's only (say) Gaussian Splats? Do we have to keep Mesh? Then we have to remove API because it's no longer relevant. I think that would more confusing.

I know it's confusing now, but it's a confusion I can imagine. I'm just afraid of a confusion we could have that I can't imagine.

This is a good mental experiment, lets say it's "Splats" or "Ascii" The core node support, cameras, etc and the api from it would come from the BaseRenderer or similar structure I suppose. They could be extensions of the main Renderer and it be understood that when you use XExtensions it has specific support, OR there is an extension mechanism for abstract renderers until they become core?

Derived:

const renderer = new AsciiRenderer();
renderer.render(scene, textCam); // texCam only compatible with this renderer, regular three objects work fine

That way its super clear you are using a dedicated subset, and if you need that special thing or if Mesh wont work.

Extension:

THREE.Renderer.extend(SplatExtensions);
const renderer = new THREE.Renderer();
renderer.render(superSpecialSpatScene, regularThreeCam); // I too support both things

This way the API/Docs/surface remains the same and tooling/third-parties will work as expected

This is all just spitballing..

I assume WebGPU will be the primary element for the foreseeable future so Renderer as "The most current of methods for most things" and dedicated derived renderers feels like the best pattern to me.

Lets say in 5 years theres a big need for something like WebMetalRenderer.

Both patterns work, You could THREE.Renderer.extend(WebMetalExtension) for dev/alpha and eventually the renderer just includes those extensions etc.

I'm just thinking aloud..