fix(useRaycaster): set delta on pointer-missed events

[AntoninRousset]

Fixes #852.

Introduces a very small overhead because the delta is computed for every pointerup event.

[netlify]

✅ Deploy Preview for tresjs-docs ready!

Name	Link
🔨 Latest commit	888b770
🔍 Latest deploy log	https://app.netlify.com/sites/tresjs-docs/deploys/672a2cf12f65910008d2e132
😎 Deploy Preview	https://deploy-preview-853--tresjs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[alvarosabu]

Hi, @andretchen0 is this contemplated in your refactor #844? Should we merge this PR first?

[andretchen0]

@alvarosabu

Hi, @andretchen0 is this contemplated in your refactor #844?

In the event system rewrite, event.delta is recalculated (and usually non-0) for pointerup, contextmenu, dblclick, and click. Otherwise, it's 0. (This is more like R3F than our current main implementation, which keeps the delta value until the next pointerup, iirc. Not sure if that interferes with @AntoninRousset 's use case.)

Here's the code. (It's called distance internally.)

  const distance = (incomingEvent.type === 'click' || incomingEvent.type === 'contextmenu' || incomingEvent.type === 'dblclick' || incomingEvent.type === 'pointerup')
    ? Math.sqrt(((incomingEvent.offsetX - config.pointerDownPosition.x) ** 2) + ((incomingEvent.offsetY - config.pointerDownPosition.y) ** 2))
    : 0

From here

Also in the rewrite, users can supply their own handleIntersections method to TresCanvas (the method is a few hundred lines long, though). Hopefully that will allow users to make their own tweaks for cases like this one in the future.

Fwiw, for the use case under discussion, the new system also implements pointer capture, which makes dragging things around a lot simpler.

Should we merge this PR first?

I don't have a feeling one way or another on this one.

[andretchen0]

@alvarosabu @AntoninRousset

Fwiw, the new event system sets delta on @pointermissed.

Screen.Recording.2024-10-17.at.13.11.31.mov

But, @pointermissed works slightly differently and the current @pointer-missed [sic]:

• current: @pointer-missed is only fired when all objects are missed
• new: @pointermissed is fired on an object whenever the object registering a @pointermissed handler is missed. I.e. not only when all objects are missed. This works like R3F.

So, again, I don't have a strong opinion here. We can merge here if it helps someone, but there are changes in the pipeline for the next major version.

[alvarosabu]

Hi @AntoninRousset did you check the latest comments? We are currently working on something that will change some of the behaviors on v5, let us know if you still want to merge this one in the meantime

[AntoninRousset]

Thank you @alvarosabu. I think the suggested behaviour makes sense (to be honest, I even thought this already the case). I would expect @pointermissed registered on the TresCanvas to be triggered when no object of the scene has been reached by the raycaster, is it what is planned?

Would you also fire a pointermissed event when the click was used to control the camera? In the end, reading the delta property was more a workaround of mine to dismiss these type of interaction.

Nevertheless, the constant delta of 0 we are experimenting now seems to be a bug and I am happy to see that it will be fixed. Personally I don't need this to be merged soon, so I guess you can close this.

[andretchen0]

Thank you @alvarosabu. I think the suggested behaviour makes sense (to be honest, I even thought this already the case). I would expect @pointermissed registered on the TresCanvas to be triggered when no object of the scene has been reached by the raycaster, is it what is planned?

That's how the current event system handles it, but that changes with the new version.

@pointermissed will be triggered whenever the object registering the handler (and all of its children) are missed, even if another object is hit by the same event.

This brings us closer to R3F's behavior. And it's more flexible:

• You can get behavior similar to the current Tres behavior by putting an @pointermissed at the root of the scene.
• But you can also choose just to be notified when a particular subtree was missed.

Would you also fire a pointermissed event when the click was used to control the camera? In the end, reading the delta property was more a workaround of mine to dismiss these type of interaction.

This is a case I've thought about handling.

I would be interested in getting more details. Can you put a code example an explanation in StackBlitz or elsewhere?

Thanks!