Since upgrading to 0.2.3 and beyond, with the new graph revamp, my graph view is just useless. It went from being nice organized nodes to just a meaningless webby mess.
This is across multiple different projects, always the same.
It’s as if it no longer has any regard for whether or not a connection crosses another connection.
I wasn’t a heavy user of graph view but it was occasionally handy, this is certainly not handy…
Here is the old graph for context(all the un-linked pages are out of frame). Not perfect, but magnitudes better.
1 Like
Also having this issue since it was updated - this is the only place I’ve seen it mentioned. Did you ever figure out what was happening?
1 Like
+1, is there any update on this issue?
This has been resolved in the 0.10.6 release. The graph forces have been improved and you can customise them to your own requirements
logseq:master
← mp-v2:graph_forces
opened 05:28PM - 23 Dec 23 UTC
This MR adds the ability to change graph forces in the graph view, under a new d… ropdown menu item called "Forces"
![image](https://github.com/logseq/logseq/assets/16655368/ff2a04e4-435b-41a0-8a6b-e1c73a58e0ac)
This resolves requests for a customisable/better graph algorithm:
- https://discuss.logseq.com/t/extracting-more-understanding-from-graph-view-additional-graph-layout-algorithms/16841
- https://discuss.logseq.com/t/improve-graph-view-relationship-types-link-styling-and-graph-parameters-like-in-cosma/7023
- https://discuss.logseq.com/t/how-the-graph-view-could-improve-creativity/5579
This should also resolve some a number of user issues related to the graph layout being messy/not being very useful:
- https://discuss.logseq.com/t/graph-overlapping-problems/1726
- https://discuss.logseq.com/t/better-graph-make-sure-the-edges-of-graph-do-not-cross-like-obsidian/16862
Users resorted to manually dragging nodes to where they want them to be, and then requesting that the graph does not reset/re-render each time you click back to it. The ability to change graph forces means users can now customise the default force values, thus the default layout of their graph, using the config.edn default parameters. This indirectly resolves the requests to have a layout-persistant graph option:
- https://discuss.logseq.com/t/have-nodes-in-graph-view-stay-put-unless-moved/7942
- https://discuss.logseq.com/t/predictable-graph-layout-and-journal-nodes/3431
- https://discuss.logseq.com/t/ensuring-that-graphs-dont-revert-to-their-default-messy-state-when-i-click-away/3954/3
- https://discuss.logseq.com/t/persisting-graph-shape-keeping-nodes-position-after-navigating-away/3209
- https://discuss.logseq.com/t/is-it-possible-to-open-a-page-in-the-sidebar-from-the-graph-view/15283
To not overload the number of options, although more are possible using the same structure, I implemented the key ones:
- link distance _(The link force pushes linked nodes together or apart according to the desired link distance)_
- charge strength _(The many-body (or n-body) force applies mutually amongst all nodes. 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)_
- charge range _(The maximum distance between nodes over which this force is considered)_
![image](https://github.com/logseq/logseq/assets/16655368/100ac2d6-722b-4b28-b8c2-ef131f94e510)
The graph is reactive to the sliders, and the graph forces can be reset back to defaults using the "Reset forces" button, similar to "Reset graph" for the n-hops slider.
Force values, in general, default to the same value they were previously, so that the default experience is the same as it was before. Exceptions;
- link distance has been reduced from 180 to 70. This makes graphs significantly cleaner
- the velocity decay when dragging nodes has been reduced from 0.8 to 0.5 to allow the graph to better converge on a clean layout. This (partially) resolves issues like:
- https://discuss.logseq.com/t/better-graph-make-sure-the-edges-of-graph-do-not-cross-like-obsidian/16862
- https://discuss.logseq.com/t/how-the-graph-view-could-improve-creativity/5579/2?u=mapping_world
- https://discuss.logseq.com/t/graph-view-nodes-should-move-with-their-parents/1929
I set the sliders to have a stepsize proportional to the value size (e.g. 5, 10 or 100), to prevent too much rendering of large graphs. It would be more efficient to have the graph render on slider release (instead of on value change), however I would need someone more familiar with Clojure to assist with this.
Cheers,
mp-v2
Here is my personal graph using the master branch:
![image](https://github.com/logseq/logseq/assets/16655368/a2be7fe2-5e81-448b-98f0-b77065fad3ef)
Here is the same graph with default forces in this branch (with lower velocity decay, allowing better convergence on a clean solution):
![image](https://github.com/logseq/logseq/assets/16655368/2a20f9d6-8fa9-4aee-a42d-a170cb9ad766)
Now with adjusted forces based on personal preference. These changes are persistant, even when changing to note pages and returning to the graph view:
![image](https://github.com/logseq/logseq/assets/16655368/e1339161-91da-4ab6-b544-b41f0f464d1a)
Examples from a large graph are much more exciting, but some examples below show options now available
Small link distance:
![image](https://github.com/logseq/logseq/assets/16655368/c4c96ac5-3cab-41c5-96c8-45ec17332353)
Large link distance:
![image](https://github.com/logseq/logseq/assets/16655368/0e35b7a9-da41-4d90-aefc-e4b1649f462d)
Default negative charge (repulsion) changed to positive (gravity) causes orphan pages to come to the centre:
![image](https://github.com/logseq/logseq/assets/16655368/cdc0c314-51c8-407b-bccc-e1551f50c1a3)
A positive charge strength, and long link distance, will group chuild nodes together from one node:
![image](https://github.com/logseq/logseq/assets/16655368/a8dcd853-c8a3-4f7f-b9b5-f62f35959c7a)