I’m looking to render graphs - that is, mathematical graphs (e.g. directed) - and have done exhaustive research combing through the different libraries available on the web. I’m familiar with three.js and was going to lean towards babylon when I found ROOT. It’s great to see the team implementing D3.
I’d like to work with the ROOTJS/ROOT team towards visualizing and manipulating large graphs (2d+3d). It may be that the naming conventions of the examples provided with JSRoot may have to change (Chart vs. Graph). There are numerous algorithms I’ve found to provide (node) graph layouts.
I believe I can provide some help with making large-scale graph visualizations a reality, and am willing and able to help CERN with this.
Please contact me at jfriedman ‘at’ graphstax ‘dot’ com or through github. In the meanwhile, I’ll be looking through the examples.
Regards
Jacob
p.s. Whether or not this foray takes advantage of the C++ library at this time isn’t a concern.
JSROOT already provides a lot of optimizations to be able to show large datasets - as histograms or graphs in 2D and 3D. If there are too many points - it tries to show only most significant ones. In addition, RCanvas class of ROOT implements special technique to pre-select such points already on C++ side - see rh1_large1.cxx, rh2_large1.cxx, rh3_large1.cxx examples in tutorials/rcanvas subfolder.
Of course, any contributions from your side are welcome.
Thanks for pointing me to those examples! Ill have a look.
Mathematical vs. Display-Graph (perhaps call it a ‘Chart’)… here’s a chart of a graph: https observablehq com/@d3/force-directed-graph
I’ll play around with the examples and see if I can get an algorithm for a graph in the examples. If youd like to work together live, pergaps we can schedule an introduction- let me know if either of you have some time.
That’s fine as it’s merely a visualization library (a Graph of a mathematical graph is fine). I would, then, provide the logic for the display and let ROOT take it from there). It may be a semantic collision in future, but seeing as there’s no demand from the ROOT team, for graphs (as I’m aware of), the mathematical graph may be a sub-type of the actual Graph(ic) as provided in ROOT.
I’ll post here, as well as the github just in case:
Is there an option for users to modify the ROOT file in the Browser- and does that modification instantly update to the main display?
For instance, say we want to take a GraphViz tree and modify it in the browser as a direct transformation on the object for rendering- is it at all possible?
Correct- I’m aware but am particularly interested in how the manipulation of the output connects with its generators (either GraphViz or internal ROOT structures).
Given a graphviz input, manipulated in the ROOT interface, what guarantees are there that I can manipulate it once again in graphviz, or (for instance) manipulate (add/remove) nodes using the ROOTJS interface, keeping the structure of the graph (both visually and structurally) intact?
P.s. thank you very much for fielding the questions
The ROOT GraphViz interface allows to generate graphs and uses the graphical ROOT machinery to render them. The graph computation is delegated to GraphViz. Also, you can dump a ROOT TGraphStruct (“graph structure”) as a “dot” file. That’s basically all you can do. This part of ROOT is not developed anymore.
An issue still remains under the jsroot github for large graphs (manipulating in the browser, socket-event vs polling).
For million-node graphs, the transfer could be quite slow. I’m not sure how the saved root file is saved (patched?) for large files. A simple diff coul save quite a bit of bandwidth and permit large-geometry browser updates.
I may have to provide this solution myself in the buffer class, but is there any work done or being done towards this?
As long as GraphViz is no longer developed inside ROOT, I see no good reasons to add support for it in JSROOT. But if somebody wants to implement it - one can discuss it