vasturiano / globe.gl

UI component for Globe Data Visualization using ThreeJS/WebGL
https://vasturiano.github.io/globe.gl/example/world-population/
MIT License
2.03k stars 301 forks source link

.2 precision in globe.js #30

Closed ryan-veracitek closed 3 years ago

ryan-veracitek commented 3 years ago

Have had to patch this static value to .05 to get accurate behavior. Is there a consequence? Would you consider .05 as the default?

Thank you.

vasturiano commented 3 years ago

@ryan-veracitek are you referring to the lineHoverPrecision? This would affect only the interaction precision of the arcs and paths layers, when in Line mode (undefined stroke).

The set value was picked as it works relatively well in most circumstances. Could you describe the problem you're trying to solve by modifying it? If justified we could potentially make it customizable.

ryan-veracitek commented 3 years ago

Sure, and thanks for your response. We overlay polygons, with it at .2 we see it return the wrong object onHover. It will often return an adjacent object. With it at .05 we get much better accuracy on detecting which polygon is being hovered over. It's ok if you don't want to change the codebase, we're patching fine, but it's a tricky one if someone stumbles on it.

vasturiano commented 3 years ago

@ryan-veracitek my understanding is that this precision only affected the raycaster precision of line objects, so polygons or any other 2+ dimensional objects should not be affected by it.

It's being applied here: https://github.com/vasturiano/three-render-objects/blob/master/src/three-render-objects.js#L245

And according to threejs docs on the line threshold param: https://threejs.org/docs/#api/en/core/Raycaster.params

Are you sure you're observing a difference in the polygon hover when modifying this value?

ryan-veracitek commented 3 years ago

Yessir, absolutely when I patch that single value .2 into .05 rather than return the adjacent polygon (in certain rare cases) the hover returns the correct one. The effect can be seen somewhat readily among adjacent polygons if you set that number from .2 to 1 and then show the tooltip on hover with unique identifiers among the polygons. Call one A & another B... you'll find you can move well beyond the border of B before the callback changes the tooltip to A. The higher that number the worse the effect.

Perhaps it's using those lines for border/boundary detection and the higher precision value causes that border to appear much wider to the algorithm? .2 worked in most cases, even with much smaller polygons but it seems that if a small polygon is positioned in just the right spot between two others it would effectively disappear to the hover.

Thank you again for your response.

ryan-veracitek commented 3 years ago

I checked your COVID map and you're not showing an Andorra polygon. I suspect if you had polygon hovers and showed Andorra you'd see the mouse hover not work correctly at .2 and work correctly at .05.

vasturiano commented 3 years ago

@ryan-veracitek sorry for the hold on this case.

The mystery is finally revealed. The part of the polygon object that was being affected by the line hover precision is the polygon stroke. That contour line surrounding the shape, and activated by polygonStrokeColor, is a Line object and that's what was introducing the artifact related to the hover margin.

To address this, I've exposed the lineHoverPrecision method. Its default value remains the same at 0.2, but it can be modified to other values (including 0, if no hover margin is desired) like so:

myGlobe.lineHoverPrecision(0.01)

Hopefully this fixes your case.

ryan-veracitek commented 3 years ago

No problem at all this really should cover it! Thanks.