OnPointerOverTrigger is trigger happy on thin instances

Bugs
1

Title pun intended :wink:

Hi @Evgeni_Popov, this is a follow up to the work you did in:

The documentation indicates that both OnPointerOverTrigger and OnPointerOutTrigger should be raised just once, which is the behavior for normal meshes, normal instances, but not thin instances. For thin instances, the triggers are getting called as long as you move the mouse over them.

I’ve edited the PG from the post linked above to create a repro. See the number of calls in the tooltip.

Any idea what could be happening? I’m happy to help but not sure how.
Take care.

2

This is a by-product of setting pointerOverDisableMeshTesting=true. If you do it for instances, you’ll see the same behavior.

We can’t change it, because that’s what makes the over/out pointer work for thin instances in the first place. We’ll be updating the documentation to clarify how this works for fine instances when pointerOverDisableMeshTesting=true.

[EDIT] Doc updated:

1 Like
3

Thanks for the quick reply @Evgeni_Popov and for the updated docs!

I’m wondering how to get around this without reimplementing a chunk of the picking logic in userland. From this reply:

I understand that it would be a major rework to differentiate between thin instances in the action manager code. Is that right?

I’m thinking a leaner way would be to use debounce logic. I see that both pointer over and point out events are emitted in alternance. When the mouse stops on the mesh, the last event is a pointer over, and when the mouse starts moving again the first one is a pointer out event. I could set a debounce type of logic to ignore pointer out/over events if they are emitted too close to each other. This is relatively straight forward to do in userland (I think) so I would be happy with the solution.

2 questions though:

  1. do you think i’m missing something?
  2. would there be any interest in integrating that to the BJS code to solve for thin instance pointer over event?

Thanks again

4

It might be interesting to make it work for thin instances, if you want to try your hand at it. But I think we should do it at a low level (not ActionManager but maybe InputManager), so that we have a single event raised, and don’t have to implement debounce logic in the engine.

Otherwise, implementing debounce logic at the user level is a good workaround, I think.

5

I’d be keen to give it a go, but i’m unfamiliar with the codebase. Do you have broad stroke guidance that could put me on the right path?

Would starting with the debounce approach in a PG help at all?

6

I would look in Inputs/scene.inputManager.ts, as I think it’s the main file for everything related to inputs. But input management is quite complicated and I’m far from an expert in the field. @PolygonalSun will be of greater help if you have some specific questions!

As for the debounce approach, it could be nice to make it work in a PG for people that would like to use it.

7

OK, I started warming up with the debounce approach in PG. Here it is, pretty straight forward I think.

I’m hoping to carve some time to look at the inputManager stuff during the break. @PolygonalSun if you have any pointer, I’m a taker.

Thanks for the help both :slight_smile:

1 Like
9

Hey, I just realized the scene.pick() call in the previous PG was not required since the event already provides all of the required data. Here is an updated version :v:

1 Like