Non overlapping GUI linked controls

Thank you very much for your kind words! I am happy that you find it useful!



A dude has messaged me whether I am willing to revive my idea to move the controls back “home” when possible. He was communicating with me private (don’t know why) so I don’t want to ping him here nor reveal his identity.

Here is a PG with controls moving home when their original home positions becomes available and are not overlapped anymore. You can drag the spheres. The “Alpha” is the big dog on the scene and pushes away all other controls without channing it’s linkOffset. All the controls should work as “Alpha”. After the controls are not pushed anymore they will go home if possible. The code is not optimized and has some flaws (jittering in movement is some cases - when the controls are too close and there are a lot of them in a small area) however I am curious whether we want add this to the BabylonJS source code. If so, I can continue to work on it.

@jeremy-coleman Hey hello, do you have an algorithm in your magic hat which will make the “go home” function universal? For now the controls go home only if their home positions are free and doesn’t take into account that they could push away the other control(s) to another positions and make it’s own home position free.

Thank you!

r. :vulcan_salute:

1 Like

I think a recursive / tree 2 phase commit would be one solution, but i feel like something simpler is possible

1 Like

More thoughts, will probably edit this a lot.

Other use cases:
games with nameplates / healthbars.

feature name:
Babylon.GUI3D.NameplatesContext (state container for weight assignments / filter / queries / etc )

assign weights to properties on each entity. this would facilitate prioritization and filtering. it could be based on the data the entities represent or it could be arbitrary, like being alphabetical. For ex, if papa and mike have some contention over who is displayed first, mike wins just because its m before p. Marking as alpha would add to score.

freeze unfreeze on events:
camera movement
entity position change
entity data change (Mike changing to Michelangelo might require a layout recalculation)

1 Like


Cool idea!

Yes, it could go into “GUI3D” and I could add depth to the nameplates.

I was thinking about weight assignment already. There is already the possibility to lock the movement/changing the link offset actually by setting the overlapDeltaMultiplier to 0 on the control so it is basically weight = Infinity.

The main problem I have and the biggest challenge here is the freeze/unfreeze logic. Basically when should the control “go home” and when could it be pushed away “from home”. What’s the moment when the control gives up and will not moving towards home or not being pushed away. Solving this problem will remove the jittering as seen in the following video.

The jittering happens in a scenario when the controls wants to move in the opposite directions and in one step Romeo pushes Juliet to the right but Juliet wants to go to the left and pushes Romeo back. But Romeo will not chicken out and pushes Juliet back to the right and this goes in circles forever. For two controls it’s easy to solve but when there are multiple controls every control wants to take it’s home position and they are pushing each other back and forth. The weighting system could solve this I believe. Basically one of the controls must be always a “pusher” control and the other will be the “pushed” control. This is what I did with “Alpha”, it’s always a pusher. Do you think this should work?

EDIT: I mean we could assign the weights based on a rule/rules (the ABC rule what you’ve mentioned for example) so there will be no two controls with the same weight or allow the user to set the weights manually. This could ensure that the controls with lower weights will simpy not fight back and will not be able to push back. Will this work with a dozens of controls? Just thinking…

Thank you very much!

I was hoping the arbitrary weight assignment (like alphabetical sort) would fix the jitter issue

1 Like

I’ll give it a try. :slight_smile:

1 Like

The weight property doesn’t solve the issue with the ‘go home’ functionality which causes the jitter but its a cool addition.

The code for this is pretty light.

I was looking at cassowary libs and some d3 libs but theyre all so huge.

Maybe turning off the layout or fading out the go home force after a 1 second timeout on certain interactions could work.

Keeping a list of every node and the deltas is an option too. Like when the majority isnt moving, turn the layout off.

1 Like

Thanks, I’ll check it this weekend. The repo and your idea of a delay as well.

Thanks again! I’ve checked the repo. It will not help me to solve the problem unfortunately. The issue with my solution was not the collision detection itself. The many-to-many example simply changes the direction of the movement so the rectangles do not overlap. My goal is to move the rectangles home (to a fixed position) without colliding any other rectangles. And while they’re heading home and user can interact with them, drag them, rotate the camera thus changing the positions and so on. So it’s kinda pathtracing with dynamic obstacles. I have something in my mind but I am quite busy these days so I’ll get to this back later.

Have a nice day! :slight_smile:

1 Like