-
Notifications
You must be signed in to change notification settings - Fork 373
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
GPU based picking with points #1721
Conversation
It's subtle, and difficult to capture on video, but I think the hits might be off by a pixel or two. This is recorded on a retina screen: pixel-imperfect.mp4If the pointer enters from the top left, the thing is immediately "picked". If it enters from the bottom right, the cursor can penetrate ~2pixels before picking occurs |
Hmm could be that some calculation isn't entirely watertight yet! There is plenty of room for error here: The picking demo uses the "middle pixel" of the picking rectangle. That already is probably wrong since the rectangle has an even number of pixels. Sources of errors that need to be checked:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lack of high-level comments makes the code quite hard to follow
|
||
// TODO(andreas): Move this into a utility function? | ||
let picking_data_without_padding = | ||
picking_rect_info.row_info.remove_padding(data); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel already that we should have a helper layer between the user and gpu_readback_belt
. If every users need to store the original rectangles so that they can remove the padding, then there should be a helper layer that does all that for us
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's what I meant with the comment :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although, not having the user store the originals is kinda hard I think. I didn't want to do dynamic dispatching on the level of the readbackbelt, i.e. not categorizing all the possible kinds of readbacks on the re_renderer side
there's some other work I have planned to deal with the problem of conjoined buffers. I'll have a look into higher level layers then.
0be31be
to
c0601f9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
let picking_target = ctx.gpu_resources.textures.alloc( | ||
&ctx.device, | ||
&TextureDesc { | ||
label: view_name.clone().push_str(" - PickingLayerProcessor"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah right. Maybe a .concat(…)
helper or similar to make it slightly more obvious it is not a normal string
label: view_name.clone().push_str(" - PickingLayerProcessor"), | |
label: view_name.concat(" - PickingLayerProcessor"), |
Oh, and make sure you test on web! |
uneven rect size & coverage handling for points
I might be imagining this but I think the last commit fixes the accuracy issue you mentioned. I need to try on an low res screen later again, I have a hard time squinting at these high dpi screens and make out much difference |
Major step towards GPU-based picking layer and retrieving thereof. (towards solving #1615)
Screen.Recording.2023-03-28.at.20.33.33.mov
Recording of an earlier version of the demo running in a browser, with the debug view enabled (at this point the picking layer was still rendering out color)
https://user-images.githubusercontent.com/1220815/228007386-5c630db4-9ee3-4324-9ee2-e71f9ed3f140.mov
Our GPU based picking needs a separate draw pass for its picking layer. The flip side of this is that the picking layer is tiny! Only a small requested rectangle needs to be rendered.
Afaik this is somewhat unusual - picking layers, when done on the GPU, are often done as an additional render target during the main draw phase. However this has a few advantages for us:
Disadvantages are the same as for e.g. an additional shadow-map pass:
Next steps...
Note that unlike previously with outlines we can't do a step-by-step update of rendering primitives as all primitives need to be present in the picking layer for a usable result.
Checklist