Not sure if I'm using the right terminology so this question may already be answered somewhere on stackoverflow (if so, please let me know). Is there a way to designate multiple "gravity points" in a d3.js graph where the gravity point is one node with a fixed (x,y) value in each cluster? For example, I'm using the code from this example to display clusters. The only difference in what my graphs will look like is that the nodes will have links to each other (possibly to nodes in other clusters as well). I want to make sure the other clusters overlap as little as possible and still show any links between each cluster.
I've tried force.gravity(0.1) with force.charge(-10). That seems to keep the clusters apart but the between-cluster distance continues to decrease as gravity increase because there is only one "gravity point" located in the middle of the graph by default.
Only way i can think of is to add a node where you want to keep gravity and designate its charge with a large positive value , rest of the nodes should have a negative value charge. Hopefully they will attract towards each other. If you have found a better solution , please let me know.
Related
I'm developing a spheroApp quiz. Practically it's a quiz game where it's possible to answer question driving sphero to one of 3 hole that define the answer.
Well, i use locator to define position of sphero. In the wizard section it's possible to define the 3 hole position driving from a single start position (0,0).
I save the 3 hole position and when the sphero go in (i have defined a gap between 10/20 from position of the hole) the app discover that it's a right/wrong answer.
but, every time i try to go in the same position i receive from sphero different coordinates.
there is some method used to improve the precision of locator?
If someone know something about let me know!
thanks ;)
ps:
i have followed this guide!
https://github.com/orbotix/Sphero-iOS-SDK/tree/master/samples/Locator#the-default-setup
tnx
There's a few different things here that I think might be the issue. Unfortunately, the locator is not crazy accurate to begin with, as the data is pulled from the motors taking the ball places. I was discussing with a couple guys here, and we surmise that if you were to put the ball in the center, and then drive it towards what the vertex points of an equilateral triangle that that would probably work best. The other issue that might be getting you is calibration. When you calibrate the ball, the heading is reset and therefore the locator thinks that it is moving in a different direction than it actually is. Perhaps in you app you will need to have some calibration for your gap detection when the ball calibrates to keep everything in sync.
Let me know if there is anything else.
My case is that I am dynamically positioning a bunch of icons on a static map image, each by CSS, positioned absolutely. Now it often happens, that two or even more points are too near to each other, so the icons overlap and they are not anymore distinguishable.
I am looking for an algorithm to find these "too near to each other" points, and then spread their icons out in a manner that they do not overlap each other anymore.
I am thinking of a radial spread, like finding the average middle point of all points that are too near and then spread them out relatively to that point.
Is there any pattern for such a problem of which you may know?
Thanks a lot in advance.
Here are a few solutions that might solve your problem:
Use a solution to the closest pair of points problem to find the two icons that are closest to one another. If the closest pair is "too close" by your definition, you can move them apart from one another and repeat this process.
Use a spatial data structure like a k-d tree or R-tree to store all the points. You can then execute fast nearest-neighbor searches to find points that are close to one another and move them apart.
Use a force-directed layout algorithm to find a layout for the points that globally minimizes some energy function. Algorithms like Fruchterman-Reingold are pretty straightforward to code up and produce good results.
Hope this helps!
I am working on this browser-based experiment where i am given N specific circles (let's say they have a unique picture in them) and need to position them together, leaving as little space between them as possible. It doesn't have to be arranged in a circle, but they should be "clustered" together.
The circle sizes are customizable and a user will be able to change the sizes by dragging a javascript slider, changing some circles' sizes (for example, in 10% of the slider the circle 4 will have radius of 20px, circle 2 10px, circle 5 stays the same, etc...). As you may have already guessed, i will try to "transition" the resizing-repositioning smoothly when the slider is being moved.
The approach i have tried tried so far: instead of manually trying to position them i've tried to use a physics engine-
The idea:
place some kind of gravitational pull in the center of the screen
use a physics engine to take care of the balls collision
during the "drag the time" slider event i would just set different
ball sizes and let the engine take care of the rest
For this task i have used "box2Dweb". i placed a gravitational pull to the center of the screen, however, it took a really long time until the balls were placed in the center and they floated around. Then i put a small static piece of ball in the center so they would hit it and then stop. It looked like this:
The results were a bit better, but the circles still moved for some time before they went static. Even after playing around with variables like the ball friction and different gravitational pulls, the whole thing just floated around and felt very "wobbly", while i wanted the balls move only when i drag the time slider (when they change sizes). Plus, box2d doesn't allow to change the sizes of the objects and i would have to hack my way for a workaround.
So, the box2d approach made me realize that maybe to leave a physics engine to handle this isn't the best solution for the problem. Or maybe i have to include some other force i haven't thought of. I have found this similar question to mine on StackOverflow. However, the very important difference is that it just generates some n unspecific circles "at once" and doesn't allow for additional specific ball size and position manipulation.
I am really stuck now, does anyone have any ideas how to approach this problem?
update: it's been almost a year now and i totally forgot about this thread. what i did in the end is to stick to the physics model and reset forces/stop in almost idle conditions. the result can be seen here http://stateofwealth.net/
the triangles you see are inside those circles. the remaining lines are connected via "delaunay triangulation algorithm"
I recall seeing a d3.js demo that is very similar to what you're describing. It's written by Mike Bostock himself: http://bl.ocks.org/mbostock/1747543
It uses quadtrees for fast collision detection and uses a force based graph, which are both d3.js utilities.
In the tick function, you should be able to add a .attr("r", function(d) { return d.radius; }) which will update the radius each tick for when you change the nodes data. Just for starters you can set it to return random and the circles should jitter around like crazy.
(Not a comment because it wouldn't fit)
I'm impressed that you've brought in Box2D to help with the heavy-lifting, but it's true that unfortunately it is probably not well-suited to your requirements, as Box2D is at its best when you are after simulating rigid objects and their collision dynamics.
I think if you really consider what it is that you need, it isn't quite so much a rigid body dynamics problem at all. You actually want none of the complexity of box2d as all of your geometry consists of spheres (which I assure you are vastly simpler to model than arbitrary convex polygons, which is what IMO Box2D's complexity arises from), and like you mention, Box2D's inability to smoothly change the geometric parameters isn't helping as it will bog down the browser with unnecessary geometry allocations and deallocations and fail to apply any sort of smooth animation.
What you are probably looking for is an algorithm or method to evolve the positions of a set of coordinates (each with a radius that is also potentially changing) so that they stay separated by their radii and also minimize their distance to the center position. If this has to be smooth, you can't just apply the minimal solution every time, as you may get "warping" as the optimal configuration might shift dramatically at particular points along your slider's movement. Suffice it to say there is a lot of tweaking for you to do, but not really anything scarier than what one must contend with inside of Box2D.
How important is it that your circles do not overlap? I think you should just do a simple iterative "solver" that first tries to bring the circles toward their target (center of screen?), and then tries to separate them based on radii.
I believe if you try to come up with a simplified mathematical model for the motion that you want, it will be better than trying to get Box2D to do it. Box2D is magical, but it's only good at what it's good at.
At least for me, seems like the easiest solution is to first set up the circles in a cluster. So first set the largest circle in the center, put the second circle next to the first one. For the third one you can just put it next to the first circle, and then move it along the edge until it hits the second circle.
All the other circles can follow the same method: place it next to an arbitrary circle, and move it along the edge until it is touching, but not intersecting, another circle. Note that this won't make it the most efficient clustering, but it works. After that, when you expand, say, circle 1, you'd move all the adjacent circles outward, and shift them around to re-cluster.
I am rendering a map out of SVG paths (using jVectormap).
There are cases where one region has to be merged with the neighboring region.
Unfortunately both regions don't touch each other and I have to interpolate to fill the space in between.
jVectormap uses very simple SVG paths with M to set the the absolute startpoint and l to connect relative points.
Does any of the SVG libraries cover such an operation?
I haven't tried this, but you may get around it by running the converter at jVectormap with the following parameters:
--buffer_distance=0
--where="ISO='region_1' OR ISO='region_2'"
Where region_1 and region_2 are the two regions that you need to merge.
Solving the problem this way also means that the generated SVG paths are true to the original coordinates, whereas a following fix may lead to some (probably minor) inconsistencies.
This might not be the kind of answer you're looking for, but using Raphael.js you could loop over the entire length of the path of one region getPointAtLength(), comparing it with all points of the second region. If the coordinates are closer than n pixels from any coordinates on the second region and the previous coordinates weren't, than that could be regarded a "glue" point. You would then jump to the second regio and start looping over it, if the next point is still closer than n points, than go in the opposite direction, if still closer change direction and go farther along the path till finding a point that's farther away from the original region than n pixels. Continue looping in that direction till once again finding a new "glue" point, where once again you will switch to the original region in the manner described and all points which weren't covered in this final loop could be discarded (or you could simply create a new shape based on the points you came across whilst looping over the length of the original region.
True enough, it's not the easiest script to make, but it should be quite do-able I believe, especially when you can use a function like getPointAtLength to find the points between the defined svg points (though you need to only 'record' the defined points, and that's sort of the hard path as Raphael.js doesn't excitedly have any functions which would help with this, still even that shouldn't be too hard to match up by hand (in code of course)).
I'm having a problem with finding N positions in a grid based on a central point and a max range.
I have this grid, each coordinate in the grid can be either closed or open, I'm tying to, using an open coordinate, find all the open coordinates around the first that are valid and the walk range between then is equal or lower than the max walk range.
At first I tried a solution using A*, where I would select every coordinate in range, check if they were valid, if they were I would call A* from them to the center position and count the number of steps, if they were higher than my max range I would just remove the coordinate from my list. Of course, this is really is slow for ranges higher than 3, or grids with more than just a few coordinates.
Then I tried recursively searching for the coordinates, starting with the central one, expanding and recursively checking for the coordinates validness. That solution proved to be the most effective, except that in my code, each function call was rechecking coordinates that were already checked and returning repeated values. I thought I could just share the 'checked' list between the functions calls, but that just broke my code, since a call was checking a coordinate and closing it even if it still had child nodes but were technically not in range of their center (but were in range of the first center) it would close them and give some weird results.
Finally, my question is, how do I do that? Is my approach wrong? Is there a better way of doing it?
Thanks.
I've implemented something similar once. The simple recursive solution you proposed worked fine for small walk ranges, but execution time spun out of control for larger values ...
I improved this by implementing a variant of Dijkstra's algorithm, which keeps a list of visited nodes as you said. But instead of running a full path search for every coordinate in reach like you did with A*, do the first N iterations of the algorithm if N is your walk range (the gif on Wikipedia might help you understand what I mean). Your list of visited nodes will then be the reachable tiles you're looking for.
http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm