Prevent Node overlap

[irumgodil]

Hi,

What can I do to ensure nodes never overlap on top of each other?

thanks.

[AlexDM0]

Hi,

Truth be told, nothing. You can increase the repulsion or give bigger nodes more mass. You can have stabilation have more iterations but I assume that's not the problem.

The avoid overlap option is there to help overlapping between big nodes but we cannot guarantee that you will never get overlap.

Play with the physics to see what works for you. If you have a lot of different sized nodes (based on value), make sure the mass is related to that as well.

You can use the configurator to play with the physics as we also show in our examples.

Regards,

Alex

[irumgodil]

Ok, let me try that. One other concern is that when I am using "dynamic edges" the nodes lay out properly in their groups. Eg. nodes from one team lay out together and nodes from a different team lay out together. If in the "Configure options on the page" I change to "Discrete/continuous", it also looks fine. However, if I change the option to discrete in my actual code, then the nodes are not laid out in their silos. They are just close to one another, and I do not get the team distinction I need. Is there anything that can be done to prevent this? thanks.  

[AlexDM0]

Hi,

It's hard to guess without seeing it. Dynamic edges have an invisible support node. If you increase repulsion, the edges are stretched further. You'll have to increase the edge length and/the repulsion of the nodes even further. It's a different situation for the physics engine. You'll have to pick one and optimise for it.

Regards

[irumgodil]

One more thing, the mass is helping, but it is being applied across board generically. How can I ensure the repulsion of each node from another node is based on a certain relationship value b/w them. i.e. the node with the highest relationship value should have the shortest distance from a given node (and not generically be the closest/farthest). Is this possible? thanks.  

[AlexDM0]

Hi,

You shouldnt apply mass in the global settings, you should set it per node. If you do it globally, you might as well increase the gravitational constant.

As for how to determine what amount you should give them, do a preprocessing step and implement your own logic to assign mass.

A node has mass, it cannot have different masses when repelling different nodes.

Regards

[irumgodil]

I am still not getting the desired results, so created a jsbin here: http://jsbin.com/remojizima/1/edit?html,output There are 2 problems here: 1) I have set a MessageSent value on all the nodes, and the value on each node is the sum of all its MessageSents (from all edges on it - since the edge is bi-directional). The mass of the node is the "Max value - node value". The intent is that for 3 nodes, A, B, C, B will be closer to A if the message Sent from B-A is > C-A. (I am using the mass value to achieve this effect).  In the JSBin, I am not necessarily getting this effect. If you look at Node 2, it appears it is closer to Node4 or Node 1 (where as its shortest path should be with Node 3). 2) A second problem is that everytime I refresh my chart (or JSBin), I get a different structure - I want the exact same chart to be rendered each time. By that I do not just mean the positions but also the closeness of the nodes. I tried using the length variable on the edges instead of the mass on nodes, to achieve the above - but length is not predictable either. When it says length = 300, the edge is sometimes shorter than the edge with length = 200. I will appreciate your input here. thanks.  

[irumgodil]

I have resolved the randomness problem above using the randomSeed above. but issue 1 is still there.

[AlexDM0]

The length of the edge that you set is the length of the spring at rest. This is not necessarily the length at which you see them since the springs stretch.

Maybe you should use the thickness of the edges to portray what you want to show instead of the distance. The edges also have a value property for this. From what I can see you probably shouldn't use dynamic smooth edges so you have more direct control over the edges. Apart from that, the mass also shouldn't be your solution since you want directional links.

I think your only option is to put more edges with a short length between nodes you want closer together. 1 per message? I suppose a springconstant per edge would solve your problem but that is not possible at the moment.

I think most merit is in dropping your idea and going for the thickness of the edges to show traffic.

Regards

On 22 jul. 2015, at 23:25, irumgodil notifications@github.com wrote:

I have resolved the randomness problem above using the randomSeed above. but issue 1 is still there.

— Reply to this email directly or view it on GitHub.

[irumgodil]

we already are using the edge thickness, but some users are getting confused with why some nodes are appearing closer to others. I want a way to implement this somehow consistently. thanks.

[AlexDM0]

Then probably stop using dynamic edges. They fold in ways the normal edges do not.

[AlexDM0]

Is this still an issue?

[irumgodil]

Hi, We are living with the current issues. You can close this for now as I do not have time to investigate this, but currently have these problems:

• Node/font overlap- Stabilization time too high at times We need dynamic edges otherwise things are coming too close to each other. thanks.

[AlexDM0]

Hi,

Solving the closeness problem can be done by increasing the gravitational repulsion. You do not need the dynamic edges for this. You could also increase the edge length at rest. To get a good result you will need to play with these settings.

I am currently implementing an algorithm that will greatly improve the performance of the stabilisation. It should be ready within one or two weeks.

Regards

On 11 aug. 2015, at 20:05, irumgodil notifications@github.com wrote:

Hi, We are living with the current issues. You can close this for now as I do not have time to investigate this, but currently have these problems:

• Node/font overlap- Stabilization time too high at times We need dynamic edges otherwise things are coming too close to each other. thanks.

  From: Alex notifications@github.com To: almende/vis vis@noreply.github.com Cc: irumgodil irum_godil@yahoo.com Sent: Friday, August 7, 2015 6:24 AM Subject: Re: [vis] Prevent Node overlap (#1116)

Is this still an issue?— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[irumgodil]

Thanks for your response. I will wait for your fix, really appreciate it. Since it is all part of the same graph, I have dynamic edges for it - but will try to play around with the repulsion/length. When I tried it last time, I did not get any good results, but will keep you in the loop. thanks again.Irum.

[irumgodil]

Hi, I am trying to use the "Continuous" edges and changed the repulsion/nodeDistance to various values. The problems I am facing is that if the nodeDistance is even till about a 100, the nodes are very close. If I increase it much more, the nodes go very far apart and I have to zoom much more to see anything visibly. Essentially what I want to achieve is:

• Much faster stabilization time, which anything but "Dynamic" edges gives.- Minimum nodeDistance value such that the nodes are still visible but not overlapping Is there anything else you can suggest that would help? thanks.  

[AlexDM0]

Hi,

Repulsion is a legacy solver, and it is a slow one! The barnesHut or forceAtlas2Based ones are much much faster. I would recommend not using repulsion.

Without your system I can not really tweak any values, but as for the stabilization time, I'm working on a few algorithms which would greatly improve this (factor 5-10 in some of my tests!). It should be released soonish.

Regards

[irumgodil]

Hi, Not sure why this thread was closed. I had posted more questions on it this week. thanks.

[AlexDM0]

Hi,

Without your code I cannot really comment any more than what I've told you so far. The new algorithms are in there already so you may have seen a boost in stabilization times.

As I've suggested, do not use the repulsion solver for large networks.

Regards