search

immersive-web / anchors

https://immersive-web.github.io/anchors/
Other
50 stars 19 forks source link

IDL Proposal: Events for anchor creation and removal. #13

Closed judax closed 4 years ago

judax commented 6 years ago

Should anchor creation and removal be events too? The rationale for this could be that anchors could appear/disappear without an explicit user requests. Imagine anchors attached to trackables or anchors that are detected passively (while the system is doing world understanding) like what in ARCore is called a cloud anchor. I think this requires some other API ergonomics (even cloud anchors need to explicitly be created) but I think is worth discussing it separately as it is true that anchors attached to trackables could be a problem if the world understanding (the mesh, the plane) changes/disappears.

blairmacintyre commented 6 years ago

There should definitely be Anchor creation/removal events. For the reason you suggest. We did that in our WebXR experiment, it was essential.

Right now, I don't think anchors will get created except by the user. When we start exposing world knowledge in different ways, that will change; a new plane, for example, will result in a new anchor. Or a newly detected face, or image.

But, even for explicitly created anchors, the platform can destroy them if it no longer knows where they are. So we need events.

judax commented 6 years ago

I agree, and I think even with arbitrary anchors that most likely will never be destroyed by the system (at least in ARKit and ARCore does not happen AFAIK) I think there could be a way to have these events. The questions that I have then are:

blairmacintyre commented 6 years ago
  • Anchors are created and removed using promises. Should events be fired when an anchor is explicitly added/removed too?

Yes. I think so. Definitely for removed, since there is a chance they will be removed without your request. For creation, I think we will eventually have auto created anchors, so there is no reason not to include the event. Even ignoring that, it might help with code structure (e.g., I want to fire off a create anchor on an event in my UI code, but I want to listen for the event over in my content management code so I'll subscribe to events there instead of having to set up my own events and API to call from the UI promise over to the other module.)

  • What should these event names be? onadd, onremove?

That or oncreate / ondestroy ... parallel to whatever we decide on the method names.

bialpio commented 4 years ago

Few observations - my current approach to the API only allows for applications to create anchors (i.e. planes are not anchors). Since anchors can only appear at the explicit request of the application, the event that'd fire on anchor creation is not needed. As for anchor removal, this is currently not a must-have since the applications can inspect the trackedAnchors attribute on an XRFrame to figure out which anchors used to be tracked but are not tracked any more. An event for anchor removal should be an easy thing to add in the subsequent versions of the API, if we get a lot of feedback from consumers of the API that it's needed. I'm closing this issue, please reopen or file a new one if you disagree with the current approach to the API.