graphology-layout-tree node overlap

[Rich5]

I was testing out the graphology-layout-tree mentioned in this discussion #1477 (comment) and for the most part it looks good, but is there a way to prevent the nodes from overlapping as shown in the image here?

Also if I set the itemSizesReference to "positions" as in the storybook all the nodes grow in size and overlap one another so I didn't use that settings (honestly I'm not entirely sure what it's doing since I'm still learning the details of how the rendering works)

I recognize that this isn't necessarily a released feature, but thought I'd ask since my dagre implementation I mentioned in 1477 gets mixed results and this seems much more "native".

[jacomyal]

Hi @Rich5,

There are two different issues here, I think:

1. The fact that the nodes are not only overlapped, but kind of interlaced, is due to Combined (border+image) Program Node Rendering Issue #1427. It will not be solved soon, though, and will be addressed hopefully next year, when we will work on sigma.js v4
2. I added a documentation page on how sigma handles node and edge sizes. This should make it easier for you to better handle sizes in your use-case.

Also, there are some options you can give some options to the treeLayout function:

• xGroupsOffset is the horizontal space between two consecutive depth levels, in pixels
• yInGroupOffset is the vertical space between two consecutive nodes in the same group, in pixels
• yGroupsOffset is the vertical space between two consecutive groups of nodes, in pixels

Combining these options with sigma's setting itemSizesReference as "positions" should guarantee you no overlap.

[Rich5]

Thanks for this! The documentation is very helpful. I guess I missed that before. Playing around with the offset settings and refactoring a bit got me to a good solution.

[Rich5]

@jacomyal after more testing I noticed that this also doesn't play well when a customBBox is set. Similar to the initial fitViewportToNodes function noted in #1471 (reply in thread)

setting sigma.setCustomBBox(null) before any layout changes seems to work better, but I'm still testing.

[rahst12]

[jacomyal]

@rahst12 The way I see it, you have different options:

1. You can indeed wait for sigma v4. It's barely even a project yet, we don't have a definitive timeline, nor do we have solve all the technical issues. And we don't have resources to develop it yet. So, that might take some time. I hope it's for 2025, but I can't be sure yet.
2. If your issue is the mess with depth management and combined programs (Combined (border+image) Program Node Rendering Issue #1427), you can fork @sigma/node-image to integrate the borders rendering from @sigma/node-border. If it's all rendered in the single same program, there won't be any depth issue anymore.
3. Finally, you can try to avoid having overlapping nodes. Basically, it first consists of getting a more precise control of the node and edge sizes, using itemSizesReference (as described in this doc page). Then, if you still have nodes overlapping, you can either update your layouts to "stretch" them (so that your nodes have more space around, and don't collide anymore), or you can make your nodes smaller.

[rahst12]

Thanks for the tips, we'll review them! Really excited where all this is headed!