[mlevental]

you can see it here in their demo

https://youtu.be/tXwVg2S9wuY?t=60

the "salient points" are called keypoints and their feature vectors are called descriptors

https://en.wikipedia.org/wiki/Scale-invariant_feature_transf...

you are correct that the challenge is collecting and indexing/retrieving but there have been techniques that do this for a while

https://web.eecs.umich.edu/~michjc/papers/p144-park.pdf

(they even tested against SIFT descriptors)

the real thing that i'm puzzled by with blue vision is how they're registering against ARKit descriptors (if they are at all) since apple doesn't expose them in the ARKit api (only the point cloud itself). ARCore used to expose them (https://stackoverflow.com/a/29012790) but i don't think it does anymore. they must be doing the registration because they only support devices that are running ARKit/ARCore (and without it they would just have built a SLAM system - albeit backed by an "arcloud" - that sits beside ARKit/ARCore and would most likely be inferior).

[iltaiuti]

> the real thing that i'm puzzled by with blue vision is how they're registering against ARKit descriptors (if they are at all) since apple doesn't expose them in the ARKit api (only the point cloud itself). ARCore used to expose them (https://stackoverflow.com/a/29012790) but i don't think it does anymore. they must be doing the registration because they only support devices that are running ARKit/ARCore (and without it they would just have built a SLAM system - albeit backed by an "arcloud" - that sits beside ARKit/ARCore and would most likely be inferior).

I have had a look at their API documentation, and what they do is they provide you with an anchor, and that's where you attach your SCNode-s. They use the built-in ORB-SLAM to position your SCNodes, but these are all relative to the main anchor, hence achieving stability and persistence.

[mlevental]

yea that's clever. that way you don't have to track just identify. still leverage arkit/arcore to do the tracking.