You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
function onXRFrame(timestamp, frame) {
let detectedPlanes = frame.worldInformation.detectedPlanes;
detectedPlanes.forEach(plane => {
let planePose = frame.getPose(plane.planeSpace, xrReferenceSpace);
let planeVertices = plane.polygon; // plane.polygon is an array of objects
// containing x,y,z coordinates
// ...draw plane_vertices relative to plane_pose...
});
"planes" are usually requested by a user pointing to a certain area and then the logic tries to detect a plane in that area. It's not an ongoing process (such as meshing and headpose).
I think it would be better if this API takes a direction and some sort of area and then returns a promise with the detected planes.
The text was updated successfully, but these errors were encountered:
I think it's important to be able to maintain identity of the detected planes across multiple frames (so that we have a way of saying that "plane A disappeared in this frame", "plane B got modified in this frame") - do you know if that is something that is possible on systems where plane detection is not an ongoing process? Would it be possible to keep requesting detected planes over the entire area in front of the device to simulate it being an ongoing process?
Implementation note is that both ARKit and ARCore expose plane detection as an ongoing process. Based on my internet searches, Unity seems to have added abstractions to their AR Foundation that build on top of those APIs that also looks like an on going process.
I no longer work for Magic Leap so I can't comment on how their plane logic works.
However, if theirs was event based, it seems that it could be adapted to your proposal that maintains a list of detected planes.
From the proposal:
"planes" are usually requested by a user pointing to a certain area and then the logic tries to detect a plane in that area. It's not an ongoing process (such as meshing and headpose).
I think it would be better if this API takes a direction and some sort of area and then returns a promise with the detected planes.
The text was updated successfully, but these errors were encountered: