OnPointerOverTrigger triggers when mesh hidden by others

Questions
1

I don’t know if it is a bug or a wanted behaviour. But the OnPointerOverTrigger is triggered even when the mesh is not visible because it is hidden by another mesh.

But I have the problem only with OnPointerOverTrigger and OnPointerOutTrigger because, with OnPickTrigger, the event is not triggered if we can’t see the mesh.
So it would be weird and not obvious to have different behaviours depending on the pick event.

I found a former topic talking about the same thing: Check Visibility PointerOver Action - Questions & Answers - HTML5 Game Devs Forum

And here is a playground to reproduce: Babylon.js Playground

Thanks, Pichou

1 Like
2

This is an expected behavior as the hover is used to also change the cursor so you know that there is something you can click there.

To change that behavior:
https://playground.babylonjs.com/#J2SJEZ#1

See line 6-8:

scene.pointerMovePredicate = function(mesh) {
        return mesh.isPickable && mesh.isVisible && mesh.isReady() && mesh.isEnabled();
    }
2 Likes
3

Ok thanks I will use that to avoid the hover pointer mouse to show then.

But I feel like I misunderstood something:
What is the point of knowing there is something you can click there thanks to the OnPointerOverTrigger event when you actually can’t click on it using the OnPickTrigger event?

4

You can if you change the predicate of pointerdown:)

But the very reason with the pointerdown predicate is more restrictive is perf: we do not want to do a picking on almost all meshes when you move so the predicate restricts itself to meshes with actionmanager. The side effect is that in your case the occluder is not seen

1 Like
5

Just faced the same issue and found this post from 5 years ago, boom problem solved. Love this community :slight_smile:

1 Like
6

Ouch. I’ve just moved this to a pretty large scene and I now see why the check for an action manager was there in the first place. Hover is blinky now due to performance I guess.

Are there any known ways to handle this without sacrificing that a mesh behind another is not hoverable?

7

you might need to implement your own raycast based technique in this case

8

Thanks for the pointer @sebavan. What would that look like? I’ve currently code something custom in pointerMovePredicate to include only some meshes based on the heuristics of my app. E.g. don’t pick through grounds, too many walls, but grounds is fine. Is there a more advanced technique with better performance or capabilities?

9

The other way would be to only rely on imposter meshes, invisible low poly meshes not being drawn and only used for the picking scenari.

This is a pretty significant investment but it might speed up the process as you could merge all the static meshes in only a few low pol representation.