parameter that determines node's repulsion to mouse pointer

[Alex Reynolds]

When I move the mouse pointer towards a node in a force-directed graph, there seems to be a "repulsive" effect where the node moves away, like trying to push the same poles of two magnets together. Is there a parameter that controls this effect?

I'd like for the user to be able to click on a node or text element, but it keeps "running away", so to speak. I have looked at the parameters here:

https://github.com/mbostock/d3/wiki/Force-Layout

but it wasn't clear to me if these parameters affect more than inter-node dynamics. Is the mouse pointer treated like another "node"?

Thanks,
Alex

[Mike Bostock]

> When I move the mouse pointer towards a node in a
> force-directed graph, there seems to be a "repulsive"
> effect where the node moves away

This doesn't happen by default. Did you copy an example that does
this? For example, the collision detection example places an invisible
node at the mouse location. This invisible node has a charge force of
-2000, whereas the other nodes have a charge force of 0. Line 35:

http://mbostock.github.com/d3/talk/20111018/collision.html

Mike

[Kevin Marzec]

Hi Alex,

Did you ever manage to resolve this?  I'm seeing the same behavior and I'm not sure what is causing it.  

Thanks,

Kevin

[Zellyn Hunter]

I'm seeing this too.

[Zellyn Hunter]

The effect is subtle, but can be seen if you look closely. For instance, on http://bl.ocks.org/950642, move your mouse carefully beside a singly-connected node.

With different settings of gravity, distance, and charge, it becomes difficult to click on nodes.

Zellyn

[Mike Bostock]

There is no repulsive force from the mouse pointer, and I can't see
the effect you're describing. The only thing involving the mouse is
that the node's `fixed` property is set to true on mouseover, provided
you've also enabled the force layout's drag behavior. The purpose of
this is to prevent the node from escaping the mouse when you mouseover
to make the nodes easier to click on.

Mike

[Zellyn Hunter]

Here's a video: http://dl.dropbox.com/u/138229/mouse-repel.ogv

Here's the code: http://dpaste.org/NOw2i/

Zellyn

[wimdows]

Weird. I am getting the same sort of thing, using bog standard tick
and drag code in a force graph
.
But it doesn't look to me like a repulsive force. It seems the nodes
dive into the direction of the center of the graph on mouseover, the
effect becoming stronger with gravity.

I set the froce graph with these basic parameters:
var force = d3.layout.force()
.charge(-440)
.gravity(.8)
.linkDistance(120)

Upon creation the nodes beget a straightforward .call(force.drag). The
coordinates for the nodes and links are set in the most basic way in
the .on("tick") event,

The effect is a lot more pronounced at gravity(8), and a lot less at (.
08).

The nodes do seem to get fixed after some chasing at a point of their
preference, somewhat more toward the center of gravity.
The effect goes away after the graph has come to rest.

(Can't share the exact data, but the dataset contains the (many)
connections between 40 or so nodes of one type, ranging on a scale
from 0 to 16000, and 100 or so nodes of a second type ranging from 0
to 100 on another scale.)

Regards,

wim

[Asher Baker]

I was seeing the same behaviour on one of my visualisations, ended up having to disable interaction, would love to see this resolved.

[Ger Hobbelt]

Wim et al,

You might want to check (plot) the force.alpha value; all force layout experiments I did which exhibited a 'hard to catch with the mouse' behaviour had a problem due to the .alpha being 'reset' to 0.1 by the drag behaviour addition to the force. (On retrospect it's not a 'problem' but merely an 'artifact'. Which can be very obnoxious some times.)

You can 'debug' the alpha (and other) parameter of the force layout by plotting it as if you're doing a classic 'logger' engine (sorry, I fail at providing the proper English technical name for this; anyone who's ever been interested in his [mechanical] engineering history may recognize this one instantly and feel obliged to provide the proper general name for this little 'grapher / logger' engine: http://www.utsic.org/2011/09/bendix-hygro-thermograph-mechanical.html ; the OG will definitely have handled these buggers and their 'infinite' graph paper rolls in research and controlled environment plants anywhere... maybe you need to ask your real OG ;-) )

For an example of this debugging, see http://bl.ocks.org/3637711 where the top bright-blue line in the background (note the debug slider at top-left) is the force.alpha value plotted over time; wait a short while to see what happens when it hits the right edge. This is the way you debugged equipment before there was modern fancy stuff around like logic analyzers and computers in every gadget.

When your problem is force.drag behaviour related, you may also note a certain 'heartbeat'-like visual behaviour when you drag a force node around.

Anyway, the problem may be similar or identical to this scenario:

you move the mouse to 'touch' (mouseover) a moving force node. This node gets marked 'fixed' immediately, but since human movement is not robot-precise, a slight jitter exists and you happen to move outwards a pixel without noticing and the node gets un'fixed' right away; at the same moment the force.drag behaviour, which picked up your mouseover before, has already 'updated'/'reset' the alpha to 0.1 so at this mouseout the 'unfixed' node gets a copious amount of force applied, including gravity, so it 'jumps away', making it feel like it's almost 'rejecting' a mousepointer that seems to radiate a force of its own (incorrect, it's just the alpha change kicking in in a single animation frame and making the force layout 'jump' due to increased influence of forces all around).

Irrespective of whether I hit the spot here or not, start by graphically debugging your force input signals such as that force.alpha in a way similar to the referred gist; I'm sure you're in for a few surprises there. ;-)

Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------

[Mike Bostock]

I have identified a cause of this behavior and submitted a fix in V3:

https://github.com/mbostock/d3/commit/75e4ab519f5c76a068fcdf146a7ed506803db1d3

Prior to this commit, the node would get fixed at its previous
position, rather than its current position. This would cause the node
to jump back a tick on mouseover, and could then trigger an immediate
mouseout. The mouseout would then unfix the node, making it hard to
capture! By fixing the node at the current position, it should stay
put on mouseover.

It's still possible to mouseover a small target and then mouseout
because the *mouse* moved (rather than the node). And it's also likely
that the node will jump a bit on mouseout because the rest of the
graph keeps moving. But changing this behavior would require a more
substantial change to the design, such as adding hysteresis to delay
unfixing nodes.

Not yet pushed to d3js.org, but I will soon.

Mike

[marc fawzi]

Speaking of hysteresis, I found this fun little toy:

http://demonstrations.wolfram.com/TheDiscretePreisachModelOfHysteresis/

pretty cool

[fred trotter]

Mike,

         From what I can tell, this patch has made it into the core d3, but I still see this effect in my graphs..

Here is the stock example code running on my data where you can see the "hopping". I am not clicking at all on this graph this is just the result of move movement. 

http://screencast.com/t/jXejnCwGN45

When I change the the charge/gravity settings the hopping makes clicking on nodes unusable.

Any advice on how to fix this?

-FT

[fred trotter]

bump

[fred trotter]

Figured I would go with the more formal bug request:

https://github.com/mbostock/d3/issues/1357

-FT

[Isaac Mann]

I ran into a similar issue when I was applying some custom forces in the tick function.  I had to wrap my custom force in a

if (!link.target.fixed) {}

block to get the problem to go away.