Creating a force directed graph

[denon40]

Hello,

I am attempting to create a force directed graph in my Babylon.js project and was wondering if anyone had suggestions as to how I should go about that. I am looking into the barycentric method and the Barnes-Hut method but am wondering if there are any simpler ways of doing so (such as how it is done in d3.js by typing d3.layout.force) or if I should continue on with one of those methods above.

Thank you

[Wingnut]

Hiya @denon40 !  You baffled everyone, apparently.     Sorry for the slow responses.  I think all the local experts have gone water skiing.

Are you planning on staying primarily 2D?  Ever investigated https://github.com/dhotson/springy/blob/master/springy.js ?  I bet you have... long ago.

Dispersion in 3D?  Phew.  Viewing angle becomes OHH so important in 3D force directed graphs, I would imagine.  i don't think I have ever seen such a thing, but I LOVE (the thought-of) using webGL for data/process visualization.  YUM! 

I volunteer our docs or src github repos... as datasets for your experiments.  (pretty bold of me, eh?)  I heard rumor... that I/we could INDEED use our playground to query our github repos, and gather file names and folder names.  Now, by WHAT criteria... would you want to cluster these names... is anyone's guess.  I guess you could cluster them by their folder path, eh? 

Have you thought about making these FDG's... drillable?  Let's say you DID start with a github repo as your test dataset.  You could disperse the folders ONLY, and then make them clickable.  Upon click, you re-target the camera to the chosen folder, and do a fresh re-disperse (essentially a new scene) that shows (disperses) the subfolders or filenames within.  AND, we have a brand new canvas2D system that does text EXCELLENTLY.

But canvas2d IS 2d, so you would be working with 2D "primitives" and not mesh.  Still, you could use our playground to test a few things, produce some proof-of-concept demos, and likely gain a whole lot of forum interest.  Naturally, these are game junkies, so their interest might lie with gravitational pull as your spacecraft nears planetary bodies (more than one gravity force in a single scene. It depends upon which planetary body your spacecraft is near-to.)

Our local superhero @jerome made a 3D graph (a network weathermap), and although it uses no dispersion systems, it's still worth a browse.  It is not very node-heavy, but it still shows the importance of viewing angles.  (it also crashes with TypeError: meshLinks[curId] is undefined sometimes)

As the amount of nodes doubles and triples, visualizing and nav become larger issues, I suppose.

Interesting topic, Denon!  I hope you do some experiments and show us what you discover.  And, I hope you get more and better replies, than mine. 

[Wingnut]

Darn, I was hoping lots of people would gather around us at this campfire discussion.  But it's fine, we'll just talk to the fire. 

FDG results in some "companding" of the data node plots.  "Companding" is a combination of the words compressing and expanding.  Force-directed graphs CAN be used in this way. 

Sometimes far-off radical-valued data-points need to be brought closer to center... for easier visualizing with a camera view.

Sometimes tightly-clustered data-points need to be spread-out (up-scaled), away from center... for easier visualizing with a camera view.

Purpose-wise, these graphs are often used like any other graph... to do comparisons and contrasts... and to help see "the big picture" AND.... "the little picture".  Having these "views" is a learning tool, and helps in decision making, general learning, and showing us how to make better visualization tools. (What WEREN'T we able to determine from this graph?  How can we fix that?)

So, here we have covered the two most-basic force-directions.  Compressing and expanding.  Companding!  Plot-positional forces.  But "forces" need not ONLY affect positions/scalings.  Data nodes that are close-to the camera... will try to block the viewing of nodes beyond.  In this case, we might use a camera-proximity force to reduce the display-size of nodes that could block views.

Clustering and dispersion... another type of companding... can be based upon comparing characteristics of nodes (ontologies).  For example, if we are graphing squirrel types, and each of our squirrel nodes has properties containing various squirrel characteristics and traits, we could use property comparisons and do clustering forces based upon results, and based upon whatever characteristics the graph-user desires.  For example, we might want to cluster-up all breeds of squirrels from South America.  Or how about all squirrels of a certain sub-genus?  These might be some clustering-criteria used often by a graph user/visualizer.

But we are talking about REASONS (criteria) for clustering or dispersions, eh?  Maybe @denon40 is looking at HOW to compand, and not so much WHY.    As you can tell, I love talking about visualizations.  Looking at some of @jerome's recent announcements (SPS particle trails), he's got the "dispersing" down-pat (mastered).    Talk about your forced directions... phew.  Vizzy!   Visually busy.

Forum Admin / @rich ... I hope the server move went as well as it could.  Thanks for taking care of us.  Let us know if there's something we can help-with.  Be well, everyone.