6d6c6792f1
* checkpoint vitepress docs * edits * edits * hero drop shadow * d3-array edits * resolve d3 * split d3-array * move d3-array stuff around * d3-array is collapsed: true * italicize parameter names * searching edits * update dependencies * d3-array edits * array edits * array edits * array edits * array edits * array edits * move files * array edits * array edits * array edits * getting started edits * modules page * array edits * more structure * live example * dsv edits * fetch edits * dsv edits * random edits * time format edits * time edits * time edits * modules edits * color edits * color edits * interpolate edits * scale-chromatic edits * selection edits * break up d3-interpolate * scale edits * time scale edits * scale edits * scale edits * band edits * band edits * more descriptive titles * band and point edits * sequential edits * diverging edits * quantize edits * quantile edits * threshold edits * doc edits * fix titles * sequential edits * axis edits * axis edits * axis edits * shape edits * shape edits * dark mode chart * dark mode chart * curve edits * interpolate edits * line edits * link edits * radial edits * pie edits * symbol edits * stack edits * stack examples * path edits * polygon edits * quadtree edits * random examples * ease edits * ease edits * ease edits * timer edits * delaunay edits * quadtree find example * voronoi edits * dispatch edits * contour edits * chord edits * chord edits * fix find highlight * quadtree animation * transition edits * transition edits * transition edits * zoom edits * drag edits * brush edits * force edits * voronoi neighbors example * hierarchy edits * api edits * community edits * getting started edits * geo edits * Add short "D3 in React" section (#3659) * Add short "D3 in React" section I know you removed the TODO but I was already trying to fill it in! I think just making the distinction of modules that touch the DOM and those that don't was super clarifying for me personally when I figured that out. And I always forget the most basic ref pattern (and still might've messed it up here). I don't think we should get into updating or interactivity or whatever, but I think just this much goes a long way toward demystifying (and showing just the most basic best practices). * forgot i made data generic, rm reference to normal distribution * useEffect cleans up after itself Co-authored-by: Mike Bostock <mbostock@gmail.com> * Update getting-started.md --------- Co-authored-by: Mike Bostock <mbostock@gmail.com> * build fixes * index edits --------- Co-authored-by: Toph Tucker <tophtucker@gmail.com>
4.0 KiB
Many-body force
The many-body (or n-body) force applies mutually amongst all nodes. It can be used to simulate gravity (attraction) if the strength is positive, or electrostatic charge (repulsion) if the strength is negative. This implementation uses a quadtree and the Barnes–Hut approximation to greatly improve performance; the accuracy can be customized using the theta parameter.
Unlike the link force, which only affect two linked nodes, the charge force is global: every node affects every other node, even if they are on disconnected subgraphs.
forceManyBody()
Source · Creates a new many-body force with the default parameters.
const manyBody = d3.forceManyBody().strength(-100);
manyBody.strength(strength)
Source · If strength is specified, sets the strength accessor to the specified number or function, re-evaluates the strength accessor for each node, and returns this force. A positive value causes nodes to attract each other, similar to gravity, while a negative value causes nodes to repel each other, similar to electrostatic charge. If strength is not specified, returns the current strength accessor, which defaults to:
function strength() {
return -30;
}
The strength accessor is invoked for each node in the simulation, being passed the node and its zero-based index. The resulting number is then stored internally, such that the strength of each node is only recomputed when the force is initialized or when this method is called with a new strength, and not on every application of the force.
manyBody.theta(theta)
Source · If theta is specified, sets the Barnes–Hut approximation criterion to the specified number and returns this force. If theta is not specified, returns the current value, which defaults to 0.9.
To accelerate computation, this force implements the Barnes–Hut approximation which takes O(n log n) per application where n is the number of nodes. For each application, a quadtree stores the current node positions; then for each node, the combined force of all other nodes on the given node is computed. For a cluster of nodes that is far away, the charge force can be approximated by treating the cluster as a single, larger node. The theta parameter determines the accuracy of the approximation: if the ratio w / l of the width w of the quadtree cell to the distance l from the node to the cell’s center of mass is less than theta, all nodes in the given cell are treated as a single node rather than individually.
manyBody.distanceMin(distance)
Source · If distance is specified, sets the minimum distance between nodes over which this force is considered. If distance is not specified, returns the current minimum distance, which defaults to 1. A minimum distance establishes an upper bound on the strength of the force between two nearby nodes, avoiding instability. In particular, it avoids an infinitely-strong force if two nodes are exactly coincident; in this case, the direction of the force is random.
manyBody.distanceMax(distance)
Source · If distance is specified, sets the maximum distance between nodes over which this force is considered. If distance is not specified, returns the current maximum distance, which defaults to infinity. Specifying a finite maximum distance improves performance and produces a more localized layout.