Hey, thx for that secret info about linkWithMesh needing re-applying after z-index setting on GUI control. Good find.
I’ve been thinking some more… about this issue. We have gui rect-text labels… linked onto spheres… and with no backgrounds on the rect-text labels. They “clash” when they over-lap (at certain camera angles).
We thought about constantly monitoring the distances between camera and all spheres, and setting label .zIndex values constantly, based upon what was derived.
But, with no backgrounds, zIndex doesn’t really solve the problem. It won’t matter if a label is foreground or background to/with another label, because they are see-thru backgrounded… they will “clash” no matter the z-Indices of the labels.
Anyway… https://playground.babylonjs.com/#O4OXG#81 I’ve installed some continuous distance checking in lines 95-117… probably fruitlessly. I’m not sure what to do with it, now.
I’m not real “hip” on the precise meaning of the term “occluded”, but I think it basically means “blocking”, so I will use the term “blocking” and maybe “overlap”.
Does anyone know-of, or think they can build… a mod to GUI 2d… that is essentially onLinkedControlOverlapEnter (and exit/out) observers?
What I envision… is somewhat similar to multi-pick. When we use multi-pick, it returns an array of ALL mesh that were “hit” by that ray-shot. The array… [firstMeshHit, secondMeshHit, thirdMeshHit], etc. With the multi-pick, we could learn the depth-sort-order of the ray-hit mesh.
The objective… turn OFF all overlapped “background” labels when an overlap-Enter is observed (no mesh involved, ONLY GUI2d code).
BUT… we might STILL need constantly updating z-index values on the labels (which involves distance measuring on the mesh themselves, perhaps)… or else we won’t know which label is hypothetically in-front-of/behind another.
Ideal objective - summary: Turn OFF all “rear” labels… when two or more labels overlap… and turn it/them ON again, when overlap is gone.
It’s as-if we need to constantly monitor the distance.z of the linkWithMesh “connection”… ie. how far is the label from the mesh it is linked-with (for the overlapped labels). This will tell us WHICH labels should remain isVisible, and which should be disabled temporarily… until overlap condition clears.
Thoughts, anyone? thx. Kzaky… I hope you don’t mind me extending your thread a bit longer. If experts think such a system IS plausible, we’ll migrate the idea over to the Feature Requests thread.