Picking bug with overlapping nodes #1397
Comments
jacomyal
added a commit
that referenced
this issue
Dec 18, 2023
The solution is to encode item IDs in only 3 channels (R, G and B), but sending a full 4 channels color, but with a hard-coded alpha at 1. It is non-optimal (we encode a 3 bytes data as a 4 bytes integer in the ByteArray), but it solves the issue quite well. Details: - Updates indexToColor and colorToIndex to fit our solution - Updates all vertex shaders so that the `v_color.a *= bias;` correction is also applied to the picking layer colors - Updates program.ts to enable alpha blending for the picking layer
|
Big thanks to @paulgirard for the idea for the fix 🙏 (basically, we send a 3 bytes colors with alpha always at 1, but we encode it as a 4 bytes integer). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For context, with all built-in programs in sigma, each node is first rendered as a square (for
node.pointandnode.image) or a triangle (fornode.circle), and then, the related fragment shader colors each pixel either as transparent (when outside the circle) or colored (when within the circle).With the new picking implementation, item IDs are encoded as RGBA colors, so most colors in the picking layers are probably partially transparent. There is an issue right now with alpha blending that causes the following bug: When a node is drawn over another node, the transparent pixel (from the fragment shader) override the existing pixel colors from previously drawn nodes.
Here is what the picking layer looks like:
This means that, when the mouse is over those "erased corners", no collision will be detected.
I tested two fixes:
The text was updated successfully, but these errors were encountered: