[Bug] onHover returns a huge and incorrect `info.index` when hovering over certain smoothstep colors

[jeffpeck10x]

Description

I am not sure how easy it is to make this into an example, but I will try to explain what is happening:

I have a custom layer that has in its fragment shader line rendering like this:

fragColor = mix(vLineColor, vFillColor, smoothstep(lineWidth, lineWidth + .1, abs(d)));

I also have a different layer that has an onHover callback that is printing info.index to the console.

When hovering over the points, for the most part, the indices look to be correct.

However, when I hover the cursor over certain sections of the first layer (the one with the smoothstep), it will show indices like 11009977 or 7733121. It will actually fire onHover events of a totally different layer. And the values seem to be random. (I don't have 11 million points in this data set!)

The interesting thing is when I replace the smoothstep with a regular step function, the problem goes away. And it seems to only happen when hovering over edges that go into alpha=0.

I am wondering if it is picking the colors along the gradient and associating it with a picking table that is connected to the other layer.

I wish I could make an example out of this. Maybe I can...

Flavors

• [ ] React
• [ ] Python/Jupyter notebook
• [ ] MapboxLayer
• [ ] GoogleMapsOverlay
• [ ] CartoLayer
• [ ] DeckLayer/DeckRenderer for ArcGIS

Expected Behavior

No response

Steps to Reproduce

Will think about if there is a good way to share this issue. For now, I want to put it out there and see if others are experiencing something similar.

Environment

• Framework version: 8.6
• Browser: Chrome
• OS: MacOS

Logs

No response

[jeffpeck10x]

Ok, after writing this out I had a thought. In my custom layer, I had accidentally commented out the line, while working on this:

DECKGL_FILTER_COLOR(fragColor, geometry);

I was curious about what would happen if I uncommented it... and voila! It is fixed! No more mysterious picking indices.

I suppose DECKGL_FILTER_COLOR is internally making an update to picking, which is pretty amazing!!

I guess the only "bug" I would report would be that it would be nice if the documentation said that certain shader hooks must be included in custom layers with their own shader implementations if you want picking to work.

Alternatively, maybe the inclusion of modules: [picking], could inject the necessary logic at the end of the fragment shader?

At best, if you want to close this ticket, at least it will exist for somebody else to find should somebody have a similar quandary.