feat(core): Add pickable: '3d' option to all Layers#9937
feat(core): Add pickable: '3d' option to all Layers#9937felixpalmer merged 11 commits intomasterfrom
Conversation
|
|
||
| import {Deck} from '@deck.gl/core'; | ||
| import {GeoJsonLayer, ArcLayer} from '@deck.gl/layers'; | ||
| import {Tile3DLayer} from '@deck.gl/geo-layers'; |
There was a problem hiding this comment.
Use this just to test, I don't intend to merge the changes
There was a problem hiding this comment.
I've been wondering if we can somehow support PR-specific demos. Essentially, a Github action that builds deck and deploys a static bundle of a relevant example and deck itself to something like Cloudflare.
Then PR authors can make a one-offs like this that aren't merged in, and/or can test with an existing example
Would you use something like a codepen/Codesandbox that consumes a deck bundle for this PR? Or find it useful to have the layer browser deployed in a PR when a layer module is updated?
There was a problem hiding this comment.
Certainly I think there is value in providing an easy way for reviewers to test, but it also needs to not introduce friction for the author of the PR. Modifying an example like this is nice because the reviewer just needs to pull the branch and run the test.
Things that would improve the flow for me would be:
- An auto-build & deploy feature so reviewers (who may not always be technical) can easily run the example.
- A rule to prevent such changes being merged
Perhaps we could have a template in the deck.gl repo, e.g. examples/code-review which when modified and push as part of a PR is;
- built and deployed, with a link added to the PR
- Ignored (changes dropped) when the PR is merged
|
@juice928 stop For posterity, I did review both these suggestions and they are both nonsense, lacking an understanding of the codebase:
Both these suggestions are symptomatic of bad LLM "code review" - they only look at the narrow surroundings of a line of code and think they can be "helpful" by inventing low-hanging fruit issues and offering plausible sounding fixes |
|
Oof, yeah that's not useful. Who ever added cursor bugbot on the other hand.. thank you, that one catches real issues and cleans itself up with fixes are pushed |
Background
Currently the GPU picking infrastructure only returns the xy (often latitude, longitude) of the picked point in callbacks like
onClick&onHover. For many scenes, but in particular 3D tiles, having the ability to obtain the z component is useful.This PR adds a new option for the
pickableprop,'3d'. When enabled on a Layer the picking engine will perform a depth picking operation and then unproject the view to obtain the full 3D position. The altitude is available simply asinfo.coordinate[2]and so can easily be integrated into the usual tooltipsScreen.Recording.2026-01-15.at.15.47.29.mov
Screen.Recording.2026-01-15.at.15.48.43.mov
Note: videos made with this luma patch included
Change List
Deckclass to specially handle layers withpickable: '3d'