Support for Picker on WebGPU

[mvaligursky]

• New public API for both WebGL and WebGPU:

// async version of the existing API returning a Promise resolving to an array of MeshInstances
Picker.getSelectionAsync(x, y, width, height)

• existing API (WebGL only, blocking):

Picker.getSelection(x, y, width, height)

example of use:

picker.getSelectionAsync(10, 20, 5, 5).then((meshInstances) => {
    console.log(meshInstances);
});

• updated the picker and gizmos example to use the async version on both platforms.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
engine	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 20, 2024 10:58am

[slimbuck]

Is read meant to supersede downloadAsync? Seems there is some duplication here. Couldn't there just be a single function that does it all?

Also, I prefer the name downloadAsync (to match upload) more than read.

[mvaligursky]

yes, downloadAsync is "deprecated" and will be removed. I left it there as there likely is some user of this.

read matches StorageBuffer read and write, download seems more internet term which seems confusing to use on the Texture.

[mvaligursky]

I removed downloadAsync - only the model viewer seems to be using it, and we can easily swap it to use read when we update it to the new engine

[slimbuck]

So you'll rename upload to write as well? You think the functions read/write describes what is happening?

[mvaligursky]

write function would take user data, set it on the object and upload internally.
upload just uploads already provided data
read rives user a copy of data for reading

I think read is a pretty descriptive and simple name for what the user wants to do - read the content of the texture. Note that for now this is a non-public API, and we can revise this in a follow up PRs.

[slimbuck]

This seems real messy. I would prefer one way of getting texture data on both (even if one implementation must emulate the other).

[mvaligursky]

This is backwards compatibility, which a lot of users depends on, and so I left it there. Deprecating this would create a breaking change for no reason for now, people can move over to the newer API without us forcing it at this stage, as that could be a larger impact change. Including the Editor.

[mvaligursky]

There is one way to get the data on both, called Texture.read - this is async and works on both WebGL2 and WebGPU.
Public API Picker.getSelectionAsync uses it, and works on both platforms.
Existing Picker.getSelection is left there an a synchronous WebGL2 only method, to avoid a breaking change, and prints an error on WebGPU platform, forcing people to upgrade at that point.