Non overlapping GUI linked controls

Hi!
I had to solve how to remove overlapping on my linked controls, so I am sharing a solution.

So you can easily clean up this mess:
image
and end up with this:
image

Two PG’s here, one without the non overlapping stuff, another with it.
Overlapping buttons:
https://playground.babylonjs.com/#SZR2MH#8

Non-Overlapping buttons:
https://playground.babylonjs.com/#SZR2MH#9

R.

4 Likes

This is nice and I wonder if we should have it in the Gui set of tools @msDestiny14 ?

3 Likes

Oh this is wonderful!!!

Either can do a PR with your code (feel free to add me on it) or can I can add it to the documentation as an example demo under linked controls.

2 Likes

I would like to contribute to the BabylonJS source finally so I would like to try to create a PR under your lead if you agree.

3 Likes

Yep! Add me under the PR for sure!

Ok, I will have a look at the source whether I can grab a starting point. Thank you!

1 Like

You will likely want to add something under control.ts file. But I will leave it to your creativity for the interface and function names.

When you’re ready for you PR we’ll do a full review and give feedback/suggestions if need. No worries. Then you get a cool contributor badge on the forums! :wink:

2 Likes

Hello!
I’ve created a preview of the proposed changes in the PG. There is a new class extending Control at line 108. Actually the changes will be implemented directly into the Control class, I’ve created that one so I can add the methods in the PG. You can set an overlapGroup value for a control. All controls in the a group will be deoverlapped I’m not sure of the name here so please feel free to correct me :slight_smile: So you can have two overlapping group each of groups deoverlapped. Does this makes sense? :smiley: I am sure, you get the point. If you set the overlapGroup to undefined or null, the observer will be removed and the control will not be deovlerapped anymore. I am not sure whether BJS supports non-rectangle based controls but for the record this one supports only rectangle based. :slight_smile:

Waiting the comments! :vulcan_salute:
Thank you!

https://playground.babylonjs.com/#SZR2MH#14

1 Like

Ooops, forgot to mention one thing I am not sure of. Whats the best approach to get the high level control in the gui? I am now just doing a this.parent.
image

I assume that only a linked control will use the deoverlapping stuff and linked controls must be at the top level, so this.parent should always return the top level control, so I can get safelly all the children. Maybe we should not allow to set the overlapGroup for a non linked control?

Thanks!

1 Like

Will take a look more in depth over the next few days.

Quick note I don’t know if making an extending class of control makes sense just to add one feature.

Maybe we should not allow to set the overlapGroup for a non linked control?

I like this a lot more

Hey,
please note:


:slight_smile:

I already have a more optimalized version. Will show you the final.

1 Like

TGIF! Ya I knew something was off. Functions nicely playing with it. :heart:

1 Like

I will go with control.host(). This is a better approach then relying on the actual fact that a linked control must be added to the top level container. This rule could change.

1 Like

Hello @msDestiny14!
I think a better place for the deoverlap method will be the AdvancedDynamicTexture class. It is the container which should constrain and control the layout not the control itself. I am thinking just exposing a public function (line 136) on the ADT and let the user to call it whenever he needs to move the controls away so I would not add an observer to the ADT and call the deoverlap method on every frame automatically. The user can call the method with a overlapGroup specified or leave it undefined to process all groups. The second parameter allows the user to set the speed of the movement at every frame. Freedom! :smiley:

Starting at line 109:
https://playground.babylonjs.com/#SZR2MH#17

What are your thoughts about this approach?

Thanks! :vulcan_salute: :joystick:
R.

1 Like

Sounds good so me

1 Like

Ok! I had time to today to look into this. Well done. The method seems better to from a user interface side too.

Feel free to put it into the code base. Also a couple of comments in between will help for anyone looking at it in the future. :slight_smile:

1 Like

Hello @msDestiny14!
Unfortunatelly after using this method in a real life app I have discovered that after some crazy rotations of the camera I can end up with very messed positions like:

  1. starting organized:
    image

  2. ending in chaos
    image

I have a solution in mind (EDIT: not working in real scenarios so not implemented):

I need to preserve the original linkOffsetXY values and I’ll introduce a private property called linkOffsetOffset: Vector2 (any better name in mind?) which will offset the offset set by the user :slight_smile: and I will only calculate this value and not override the original linkOffsetXY values.

The controls will primarily try to reach the original linkOffsetXY if not in overlap.

And as an addition I will add deoverlapSpeed to the control. Controls with a lower speed value will move slower or never if set to zero.
R.

1 Like

Pull request created :slight_smile: I’ve already created the documentation for it, so I will create a PR in the Doc repo when this gets merged.
Thank you!

4 Likes

Awesome! So glad to have a new contributor to Babylon.js :slight_smile: This feature is a fantastic addition to the GUI system, I’ll definitely use it when it’s merged in!

2 Likes