I was trying to pack circles of different sizes into a rectangular container, not packing in circular container that d3.js
bundled with, under d3.layout.pack
.
here's the layout I want to achieve:
I've found this paper on this matter, but I am not a math guy to understand the article throughly and convert them into code…
Anyone can suggest where I should start to convert this into d3.js layout plugin, or if you have visualized bubbles similar to this layout, please suggest any direction you took to solve that.
Thank you.
If your primary concern finding a tight packing of different-sized circles within a rectangle, then unfortunately you'll have to implement a new d3 layout. I don't know of a plugin that's already written that will do this.
However, if what you're looking for is any old packing into a rectangle, then you can use the the existing circle packing algorithm that d3 provides in
d3.layout.pack
. When you specify the bounds for this layout, you're specifying the dimensions of a rectangle. d3 then determines a circle that the bounding rectangle will circumscribe, and uses that circle to visualize the root of the hierarchical data. So what you can do is provide a "dummy" root node which you don't actually render, and have the real data that you want to visualize be the children of that node.Code example below, and I also put it up on bl.ocks.org so you can see it in action.
There's a much better way to do this -- using Mitchell's Best Fit algorithm.
This is the general pattern:
See for example with random data.
A completely different approach...
As I mentioned in a comment, a d3 cluster-force layout could be adapted into a heuristic method for fitting the circles into the box, by progressively changing the scale until you have a tight fit.
Results so far are not perfect, so I present a few versions:
Option 1, squeezes in the box to the space occupied by the circles before adjusting for circle overlap. The result is very tightly packed, but with slight overlap between circles that get caught between the walls of the box and each other, unable to move without a conflict:
https://jsfiddle.net/LeGfW/2/
Option 2, squeezes in the box after separating overlapped circles. This avoids overlap, but the packing isn't optimum since we don't ever push the circles into each other to force them to spread out to fill the long dimension of the rectangle:
https://jsfiddle.net/LeGfW/3/
Option 3, the happy medium, again squeezes in after adjusting for overlap, but the squeeze factor is based on average out the room in width and height dimensions, instead of the minimum room, so it keeps squeezing until both width and height are filled:
https://jsfiddle.net/LeGfW/5/
Key code consists of the
updateBubbles
method called by the force tick, and thecollide
method which is called in the first line ofupdateBubbles
. This is the "option 3" version:Here is a go at the implementation of your algorithm.
I tweaked it quite a bit, but I think it does basically the same thing.
Bounding circles
I used a trick to make the computation more regular.
Instead of segments defining the bounding box, I used circles with "infinite" radii, that can be considered a good approximation of lines:
The picture shows what the 4 bounding circles look like when the radius is decreased. They are computed to pass through the corners of the bounding box and converge toward the actual sides when the radius grows.
The "corner" circles (as the algorithm calls them) are all computed as tangents to a pair of circles, thus eliminating the special circle+segment or segment+segment cases.
This also simplifies the start condition greatly.
The algorithm simply starts with the four bounding circles and adds one circle at a time, using the greedy heuristic lambda parameter to pick the "best" location.
Best fit strategy
The original algorithm does not produce the smallest rectangle to hold all the circles
(it simply tries to fit a bunch of circles into a given rectangle).
I have added a simple dichotomic search on top of it to guess the minimal surface (which yields the smallest bounding rectangle for a given aspect ratio).
The code
Here is a fiddle
Performance
The code is not optimized, to favor readability (or so I hope :)).
The computation time rises pretty steeply.
You can safely place about 20 circles, but anything above 100 will make your browser crawl.
For some reason, it is way faster on FireFox than on IE11.
Packing efficiency
The algorithm works quite poorly on identically-sized circles (it cannot find the famous honeycomb pattern for 20 circles in a square), but pretty well on a wide distribution of random radii.
Aesthetics
The result is pretty ungainly for identical-sized circles.
There is no attempt to bunch the circles together, so if two possibilities are deemed equivalent by the algorithm, one is just picked at random.
I suspect the lambda parameter could be refined a bit to allow for a more aesthetic choice in case of equal values.
Possible evolutions
With the "infinite radii" trick, it becomes possible to define an arbitrary bounding polygon.
If you provide a function to check if a circle fits into the said polygon, there is no reason the algorithm should not produce a result.
Whether this result would be efficient is another question :).
Well, this is far from optimal packing, but it's something that others can try to beat.
Updated, but still not great
https://jsfiddle.net/LF9Yp/6/
Key code, such as it is: