Camera rotate event listener

Questions
1

EDIT: Managed to make some improvements with the PG Not sure if this is the best way to keep the texts in front of the ball: https://playground.babylonjs.com/#O4OXG#77
Current PG still doesn’t work for camera Beta change, and not perfect for Alpha either.

In this playground, I am trying to make the plane text so that it’s constantly infront of the sphere on any camera rotation. Firstly, I was planning on using Dynamic texture on the sphere material and set billboard option on sphere, although dynamic texture texts on sphere meshes looks pretty distorted compared to mesh squares.

My current plan on the PG is to use the plane mesh and attach a dynamic texture to it and make the plane invisible. The plane will rotate according to camera rotate event listeners and ensure the text(plane) is always infront of the sphere at all times.

So my question firstly, is there an easier way to accomplish my task? If there isn’t, what is the best way I can get the camera rotation listener?

2

Hi Kzaky! Hey, have you tried Babylon GUI 2d (tracking feature)? It has a linkWithMesh() option that can keep labels (textControls) nicely aligned over mesh, aimed at camera.

https://playground.babylonjs.com/#O4OXG#78

It’s all done in lines 64-88. Could THAT system work for you? It sure is easy, huh?

There are lots of options for making the labels clickable, too. Also pointer onOver/onOut observers with customizable event handlers. Powerful.

5 Likes
3

Hey Wingnut! Thanks for the answer, this is EXACTLY what I am looking for and it is simply done!

4

Another problem came across, so if two of the spheres (axis) clashes together, the text will both overlap everything. Is there a solution to this?

5

Hi again, K. Nope, I don’t know how to avoid text overlap when two spheres align with camera line-of-sight. There IS a zIndex property on all controls… Use the Babylon GUI - Babylon.js Documentation …but I couldn’t make it work right, yet. Even if I COULD get it working, I’m not sure what to do with it.

I added a GUI Rectangle control (a container) for each textBlock… each having a border thickness of 1, for now. Currently, each rectangle container has no background.

https://playground.babylonjs.com/#O4OXG#80

Anyway, you can activate line 75 to set a zIndex on rectX. Doing so… makes rectX go to top-left corner of screen. I’m not sure WHY it is doing that.

Even if zIndex DOES start working, somehow, what would we do with it? We could constantly check the distance between camera and spheres, and “arrange” the zIndex order… based upon those distances. But even then… I don’t think we would win the battle… because the backgrounds to the rects… are transparent/null. I think we could see text THRU text, no matter if we had a special zIndex automatic-ordering algorithm, or not.

Perhaps, our best option is to TRY to code a way to turn-off all unwanted “background labels”… when spheres/labels overlap. Then re-activate them when when no overlap. Not sure how, yet.

I’ll keep thinking, and so will others. Stay tuned.

6

I presume that it goes to the top left corner when z-index is enabled because fullscreen mode dynamic texture is a 2D rendering as it states on Use the Babylon GUI - Babylon.js Documentation - “The fullscreen mode is not intended to be used with WebVR as it is a pure 2d rendering.” That’s what I thought at first until I’ve seen another PG that managed to make the labels work the z-index correctly: https://www.babylonjs-playground.com/#3VMTI9#60.

EDIT: seems we have to call z.index then call linkwithmesh again for it to position correctly

2 Likes
7

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.

Ideas?

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. :slight_smile: If experts think such a system IS plausible, we’ll migrate the idea over to the Feature Requests thread.

8

Hey Wignut, thanks you very much for putting lots of effort in my question! I believe no one else replied because I had the initial question solved. I ‘unsolved’ the question post, hopefully it gets a little more attention and someone can help out!

The objective you mentioned at the end would make a good solution to my problem. Is there a smart way I can check if a mesh is overlapping from the camera angle, rather than actual meshes colliding?

9

nod. Yep, a way to test for ONLY the GUI 2d labels overlapping (no mesh involvement at all except the linkWIthMesh connections). GUI controls are little sections of 2d canvas (little bit maps), as far as I know. There might not be good systems to test for overlapping of little bit maps.

Also, with a screen full of GUI 2d controls… with many mesh and many labels linkedWithMesh… and the camera starts panning-around… a LOT of code in the GUI 2d tracking system… might be running hard. By installing over-lap observing and notify-listeners within that, we might bog that tracking system.

Just thinkin’. Maybe we’ll get some cool ideas/inventions, and maybe some will say “not enough use-cases to make such a monster plausible”.

But you could code-up your own tracking code, as wanted. In fact, that’s sort of what you were doing… when you first posted, eh? (using planes instead of GUI 2d controls). :slight_smile:

The measuring system (widget sizing/setting-edges) in GUI 2d is… busy… needs updating often, and is plenty complex (as far as I’m concerned). We would need to use that very same measuring system… for the overlap testing. There’s good inventors around here, though.

1 Like
10

Helloo , did you find any solution for the clashing problem (overlaps of labels) ?

11

Adding @DarraghBurke for the GUI

12

@sebavan Sorry I didn’t understand

13

I am adding @DarraghBurke to have a look as he is our GUI awesome dev

14

Answered in your other thread :slight_smile: I don’t think either @kzaky or @Wingnut are still active here, sadly.

2 Likes