Examples: Remove need for manually assigning Line2 material resolution

[gkjohnson]

Related issue: #28335

Description

Remove the need to manually assign the resolution uniform for rendering Line2. If rendering to multiple resolutions of canvas or render targets then the resolution still needs to be set before performing raycasting.

[WestLangley]

Nice. This is working for me.

I think there are a few more lines that can be edited. Grep for "resolution" in the relevant examples.

Perhaps unrelated, there is also a webgpu example. It renders lines with a slightly different width for some reason. /ping @sunag

[gkjohnson]

I think there are a few more lines that can be edited. Grep for "resolution" in the relevant examples.

There was one straggler - thanks!

Perhaps unrelated, there is also a webgpu example. It renders lines with a slightly different width for some reason.

I'm not familiar enough with all the WebGPU stuff yet to make changes here

[WestLangley]

There are additional comments to remove:

//resolution:  // to be set by renderer, eventually

[gkjohnson]

There are additional comments to remove:

Thanks, missed those

[aardgoose]

I think there are a few more lines that can be edited. Grep for "resolution" in the relevant examples.

There was one straggler - thanks!

Perhaps unrelated, there is also a webgpu example. It renders lines with a slightly different width for some reason.

I'm not familiar enough with all the WebGPU stuff yet to make changes here

The viewport uniform in the nodes material is automatically updated so there is no need for changes there. Not sure where the width variation comes from though.

[WestLangley]

@gkjohnson The line widths are different compared to those in the previous release. At least on my machine.

I expect you are off by a factor of pixelRatio. You have to differentiate between CSS pixel units and device pixel units when sizing the viewport.

[gkjohnson]

I expect you are off by a factor of pixelRatio. You have to differentiate between CSS pixel units and device pixel units when sizing the viewport.

Oh interesting - I guess WebGLRenderer.getSize does not include the pixelRatio and WebGLRenderer.getViewport does. I've fixed it by multiplying the pixel ratio out of the viewport and it looks the same on my mac, now.

[WestLangley]

I guess WebGLRenderer.getSize does not include the pixelRatio and WebGLRenderer.getViewport does.

No, that is not true. getViewport() returns results in CSS logical pixel units.

[WestLangley]

This should be:

renderer.getViewport( _viewport );

[aardgoose]

@WestLangley

Is the line width discrepancy you see in the webgpu version the width in the inset box when in css pixel width mode?

If so I have found the issue that creates that difference.

[WestLangley]

@aardgoose

Is the line width discrepancy you see in the webgpu version the width in the inset box

yes

[gkjohnson]

No, that is not true. getViewport() returns results in CSS logical pixel units.

Gotcha thanks - just fixed. The naming of getViewport vs getCurrentViewport is not super clear 😅

[gkjohnson]

The naming of getViewport vs getCurrentViewport is not super clear 😅

Oh man even the documentation between the two is identical:

Returns the current viewport.

I'm wondering if this should just be changed to a flag to be passed into getViewport to indicate css or real pixels.

[WestLangley]

This line should be removed.

@Mugen87 How do you feel about removing this entire comment block? Apparently, we no longer use this coding pattern.

[Mugen87]

I'm fine with that.

[WestLangley]

I'll fix it. It's time to move on.

[Mugen87]

Um, does webgpu_lines_fat need an update? The E2E test seems to fail.

[WestLangley]

@aardgoose
@sunag

With this PR, webgpu_lines_fat.html fails in .onBeforeRender() due to this reference:

this.material.uniforms.resolution

This fixes it:

this.material.uniforms?.resolution

Is there a "proper" way of handing this?

[sunag]

I think the best solution at this is your code this.material.uniforms?.resolution or this.material.uniforms !== undefined && ..., I don't remember if we had a reason not to use optional chaining? /@Mugen87.

The Nodes update the values individually so we don't need a uniform object for each material. I think that soon we would also have to review the implementation of the default material LineMaterial to avoid GLSL code within a possible compilation of the code too.

[Mugen87]

I don't remember if we had a reason not to use optional chaining?

We have reverted optional chaining because we want to stick to ECMA 2018 syntax, see #25172.

WebGPU example breaks.