Fat Line Raycast Example: Set the resolution in the correct spot

[gkjohnson]

Related issue: https://github.com/mrdoob/three.js/pull/23358#issuecomment-1046029933

Description

Adjust where the line material resolution is set so the raycast result is correct. Previously the material resolution was being set after the raycast occurred meaning the line width was incorrect during the raycast.

BEFORE https://raw.githack.com/mrdoob/three.js/f35120c9083ce31f1994575cef075357bc98f53d/examples/webgl_lines_fat_raycasting.html

AFTER https://raw.githack.com/mrdoob/three.js/fix-fat-lines-raycast/examples/webgl_lines_fat_raycasting.html

cc @bergden-resonai

[bergden]

I'm not sure I understand this fix - the resolution is set on the frame rate, so assuming the window size didn't change why won't this be identical to the previous code up to the 1st frame?

Either way awesome! seems like it's working well now, crossing this off my todo list :)

Note: I think it's better for the URL to point to a fixed version instead of the dev version otherwise the PR link will be wrong after the merge https://raw.githack.com/mrdoob/three.js/f35120c9083ce31f1994575cef075357bc98f53d/examples/webgl_lines_fat_raycasting.html

[gkjohnson]

I'm not sure I understand this fix - the resolution is set on the frame rate

The render resolution on the material is set twice -- once for the main render and once for the subframe render. It needs to be set for the main render size again before checking intersections otherwise it's left at the previous subframe state.

[mrdoob]

Do we need the subframe in this example? 🤔

[WestLangley]

Do we need the subframe in this example?

I had the same concern: https://github.com/mrdoob/three.js/pull/23358#issuecomment-1046256862

[gkjohnson]

I don't have strong opinions about whether or not it should be in the example. I can remove it if you want.

[bergden]

Sorry to bring this up again, but I still suspect a bug with the raycasting+worldwidth lines+camera near combo

https://user-images.githubusercontent.com/37291459/157725015-4cceb1cd-5e6f-401f-a9e8-ada74d85dc72.mov

I should've opened a ticket after the merge to dev - without this example it will be harder to debug and reproduce camera = new THREE.PerspectiveCamera( 40, window.innerWidth / window.innerHeight, 10, 1000 );

(or even just the rendering)

Partially discussed here: https://github.com/mrdoob/three.js/pull/23358#discussion_r810521468

Can't really formulate my issue at the moment - I'll need more time to isolate what I think is buggy here Having 2 cameras is somewhat helpful

Also: Now that I think about it there might be a bug in the example where the visualization of the threshold is incorrect for the mini canvas, the line width should be adjusted there according to the main canvas

[gkjohnson]

@mrdoob aside from whether the subframe should be in the example I think this should be merged. Right now the example looks broken. If we'd like to update it to remove the picture-in-picture we can do that in another PR.