Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combined (border+image) Program Node Rendering Issue #1427

Open
oda79 opened this issue May 17, 2024 · 7 comments
Open

Combined (border+image) Program Node Rendering Issue #1427

oda79 opened this issue May 17, 2024 · 7 comments
Labels
bug pinned postponed This will be handled later, in a furter version.
Milestone

Comments

@oda79
Copy link

oda79 commented May 17, 2024

Combined (border+image) Program Node Rendering Issue

Description

When using a combined program (node-image and node-border) for rendering nodes, overlapping nodes appear messy. The nodes' borders are rendered separately and on a different layer from their images, resulting in a 'transparent background effect' or incorrect clipping areas. This issue is critical for large graphs, as graphology lacks collision layout, leading to massive node overlap.

Details

  • Sigma.js version: 3.0.0-beta.18
  • Graphology version: 0.25.4
  • Operating system: Windows 11
  • Web browser: Google Chrome Version 124.0.6367.202 (Official Build) (64-bit)

Steps to Reproduce

  1. Visit the live example: Codesandbox Example
  2. Observe the rendering of overlapping nodes.

Expected Behavior

When nodes overlap, their borders should be clipped accordingly, similar to the node 'B' in the reference image below:

Expected Node Overlapping

Actual Behavior

Nodes' borders are displayed regardless of the nodes' z-position, leading to visual artifacts and a cluttered appearance:

Actual Node Overlapping Issue

Additional Information

This issue becomes more noticeable and problematic for large graphs due to the lack of collision layout in Graphology, causing significant node overlap.

@oda79 oda79 added the bug label May 17, 2024
@jacomyal
Copy link
Owner

jacomyal commented May 24, 2024

@oda79 Thanks for that report!

I totally get this issue, and that's bad, and I have no idea how to solve it yet. Maybe something with z indexing, I'll try as soon as I can.

About collision layout in Graphology though, you can use graphology-layout-noverlap. It was not working properly with sigma.js before because we reinterpolated node sizes before, but since v3 you can use zoomToSizeRatioFunction and itemSizesReference (like in this example) to render sizes exactly as they are in the data, which allows graphology-layout-noverlap to work properly.

I hope this helps, until I find how to solve the initial problem.

@jacomyal
Copy link
Owner

Just to keep you updated, I started digging, and enabling the depth buffer might be the solution, though it kinda collides with alpha blending at the moment. I'll keep trying when I have some time.


(source)

@oda79
Copy link
Author

oda79 commented Jun 11, 2024

Thank you for the update! And also for the hint about using zoomToSizeRatioFunction and itemSizesReference, these options made a lot of difference.

In general, graphology layouts are a bit weird in comparison to d3-force, and they can not be combined.

Regarding the issue, to overcome it I made a new node-image-border program/package, which is a combination of node-image and node-border. It draws a circle node with one outer border and image/colored pictorgam/color inside. In addition, I added an alpha attribute to a node (0..1). All settings are similar to these of the parent programs. So, it looks like the following.

image

It is definitely not the fix. But if is worth being added to the packages, I guess it needs a new issue for a further PR.

Thanks for your efforts!

@jacomyal
Copy link
Owner

jacomyal commented Jul 1, 2024

Update:

I found a way to fix the issue using the discard; GLSL instruction (source). Unfortunately, it supposedly has a bad impact on performances... So I keep looking, but in the worst case we could imagine having those discard; only used in the shaders when the zIndex setting is set, for instance (using GLSL macros).

@jacomyal jacomyal added the pinned label Jul 5, 2024
jacomyal added a commit that referenced this issue Jul 8, 2024
This commit is related to #1427.
jacomyal added a commit that referenced this issue Jul 8, 2024
This commit is related to #1427.

Details:
- Updates depth management in sigma.ts to clarify the difference between
  zIndex and depth in nodes and edges data
- Adds depth management in all node programs
- Adds depth management in createNodeCompoundProgram
jacomyal added a commit that referenced this issue Jul 10, 2024
This commit is related to #1427.

Details:
- Copies code from node programs to edge programs to handle depth
- Adds code to clear the depth buffer before rendering
- Fixes various node programs depth issues (where the depth wasn't
  normalized)
@jacomyal
Copy link
Owner

FYI I've been working on a fix these last days, and it starts working:
https://github.com/jacomyal/sigma.js/tree/fix-1427

The main issue that remains is that using discard; means that we cannot draw behind anti-aliased pixels, and it is visible sometimes:

image

@jacomyal
Copy link
Owner

After some more digging, it appears that one solution to solve that glitch would be to implement some "order independent transparency" technique, such as this one.

jacomyal added a commit that referenced this issue Jul 22, 2024
This commit is related to #1427.
jacomyal added a commit that referenced this issue Jul 22, 2024
This commit is related to #1427.

Details:
- Updates depth management in sigma.ts to clarify the difference between
  zIndex and depth in nodes and edges data
- Adds depth management in all node programs
- Adds depth management in createNodeCompoundProgram
jacomyal added a commit that referenced this issue Jul 22, 2024
This commit is related to #1427.

Details:
- Copies code from node programs to edge programs to handle depth
- Adds code to clear the depth buffer before rendering
- Fixes various node programs depth issues (where the depth wasn't
  normalized)
@jacomyal jacomyal added this to the v4 milestone Sep 16, 2024
@jacomyal jacomyal added the postponed This will be handled later, in a furter version. label Sep 23, 2024
@rahst12
Copy link

rahst12 commented Oct 8, 2024

We've just run across this very issue during user feedback testing. Users zoom out and see images overlayed within the node layering on top of the other nodes. We use images inside the node to visualize what the node represents, especially when a user zooms out and the node label disappears.

As an alternative/workaround, is clustering of nodes supported? For example.. Two or more nodes would cluster/group together to form a node that says "+5" more nodes when zooming out.

Also, we're interested to see multi-node selection and the ability to collapse/expand sections of the graph.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug pinned postponed This will be handled later, in a furter version.
Projects
None yet
Development

No branches or pull requests

3 participants