RaycasterHelper

[abernier]

Related issue: #23877

Description

a raycaster helper, from @gsimone https://github.com/gsimone/things?tab=readme-ov-file#raycasterhelper code

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	339.21 79.01	339.22 79.01	+16 B +4 B
WebGPU	485.93 134.88	485.94 134.88	+16 B +4 B
WebGPU Nodes	485.39 134.78	485.41 134.78	+16 B +5 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	465.1 112.06	465.1 112.06	+0 B +0 B
WebGPU	555.03 150.31	555.03 150.31	+0 B +0 B
WebGPU Nodes	510.88 140.02	510.88 140.02	+0 B +0 B

[Mugen87]

Thinking about this now....what are the benefits of moving this into the main repository?

There is already a dedicated package where developers can import the helper. Besides, we want to be more strict in adding modules like RaycasterHelper so I'm not sure it's a necessary one to add.

In any event, RaycasterHelper should not be part of the core, see #23877 (comment).

[abernier]

I have to say that I also asked myself the same question…

I would say (without being 100% sure) that the main benefit would probably being “officially” supported (and therefore maintained) by three.js — since Raycaster is an important class.

It also brings discoverability and overall consistency¹

i let you decide obviously :)

In any event, RaycasterHelper should not be part of the core, see #23877 (comment).

I had hesitation but because Raycaster is a core class, that's the reason why I've made this choice, but no problen to move to jsm/helpers if we decide to integrate that helper 👍🏻

Footnotes

1. because one could take the opposite approach and ask: “why not moving "ArrowHelper"/"BoxHelper"... to a third-party package?” ↩

[Mugen87]

I also want to avoid the situation when developers encounter the same thing in different repositories. In my view, when RaycasterHelper is added to this repository, the original developer should do it and then remove the code from the previous location.

Besides, we often stated that we can't add "everything" into this repository. I understand it improves discoverability but it is simply not manageable for us. Having third-party repositories is totally fine and search engines makes sure developers find them. We from the core-team should make sure the most common and relevant modules are in the main repo. I don't think that includes RaycasterHelper.

[mrdoob]

How about adding the example but importing from jsdelivr instead?

import { RaycasterHelper } from "https://cdn.jsdelivr.net/npm/@gsimone/three-raycaster-helper@0.1.0/dist/gsimone-three-raycaster-helper.esm.js";

[Mugen87]

I'm fine with that. Especially since we can tag the example as external so it should be clear it uses an external library.

[Mugen87]

@abernier Do you mind updating the PR like suggested by @mrdoob ?

[abernier]

sure, i will ;)