Detected plane is under the floor?

This sounds like the device is reading an incorrect depth when creating the plane. How is the lighting in the room? Is the floor surface glossy/shiny? Is the floor texture noisy or relatively continuous? What devices are you seeing this on (just one device or multiple)?

 

Boy is there ever egg on my face. My apologies for letting this post go for this long. Let's start off with the most relevant best practices here.

The general best practices for any AR application are:

• Have a well lit space
  • Helps the device to gain an understanding of the space faster.
• Don't try to track glossy surfaces
  • Most devices have a tough time recognizing highly reflective surfaces and therefore anything extremely glossy will cause issues for tracking.
• Noisy surfaces track more easily
  • Monochrome materials don't really provide a lot of "feature points" that AR devices need to help understand the space.
• Give the device time to understand the space
  • AR APIs tend to need some time to develop a "confidence" in the space they are tracking currently so it's important to give the device enough information to provide stable tracking.

Unfortunately, this is often out of our control as developers so it is imperative that you provide guidance to your end user so that they can be provided with the best experience. You may use something like a coaching overlay to do this (we provide some samples for this in our AR Foundation Samples Repo and our Demos Repo). Depending on what your experience is intended to be you may need to make some additional assets to provide proper training on the app usage.

For plane tracking specifically, the above guidelines will provide the best overall experience but there are some things in AR Foundation that could help further stabilize the experience.

First, planes are continuously updated as the space is analyzed by the device. If you are seeing planes appear above planes, keep scanning as planes can be subsumed by other planes (which can be checked via the subsumedBy property on the ARPlane after a plane has been updated). If the plane is not subsumed you could check the tracking state of the plane in question to determine whether there is a confidence in the tracking of the plane and disable it if the tracking is not consistent.

Barring that you can always implement your own heuristic to enable or disable planes as you see fit though the heuristic you use is very dependent on your application needs. You could try subscribing to the planesChanged event on the ARPlaneManager and disable smaller planes that are too close to other larger planes and share alignment but you could be potentially locking yourself out of a better understanding of the environment (what if plane 1 grew and subsumed plane 0).