Skip to content
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

Need to expose geometry in a way that is generic, but doesn't throw out too many semantics #1

Closed
blairmacintyre opened this issue Apr 17, 2019 · 4 comments

Comments

@blairmacintyre
Copy link

A simple solution to world geometry is pick a lowest-common representation, like "a forest of meshes".

But, then ARKit/ARCore planes become meshes, and lose semantics: we no longer know that they are meant to correspond to vertical or horizontal planes. Similarly, faces could be exposed as a mesh that comes and goes, as could moving objects or detected images, etc.

So, a slightly less "wasteful" approach might be to say

  • we expose a forest of meshes
  • a mesh does not need to satisfy any particular geometric properties, aside from sharing a set of vertices that are used to construct the "mesh".
  • each mesh has an origin in world coordinates, and be defined relative to it. That origin could change each frame (e.g., so ARKit/Core planes/faces can be represented this way, as can tracked objects if the browser supports such a thing)
  • each mesh can be typed, perhaps just using string names, and have additional information with it beyond the mesh that depends on the type. Apps that know of the type can use it, others will just use the mesh.
    • planes might have a surface normal
    • faces might have an array of blend shapes
    • when other things are detectable, they can be exposed similarly. So, if we exposed "image detection and tracking", the detected image could have a mesh defined for it that corresponds to the image in the real world -- same for objects being detected (the real-world equivalent OR the thing used for detection could be returned)
@johnpallett
Copy link
Contributor

Thanks Blair! There are certainly a few approaches we could take here, and exposing individual planes should not preclude exposing mesh data (either as an alternative to planes, or through metadata on the planes)... at the very least, having planes doesn't limit other API options in SLAM systems that I've seen today.

Can you take a look at the explainer and let us know what you think about the approach?

@blairmacintyre
Copy link
Author

ha, I will. That wasn't there when I posted this. At a casual glance, I have "comments", will post later (meetings now)

@johnpallett
Copy link
Contributor

@blairmacintyre I think this discussion topic is now captured now in #6 - can you confirm?

@blairmacintyre
Copy link
Author

yes, let's close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants