Bug 58648 - ARPlaneAnchor.Extent property seems incorrect but changes to correct value after Debug access
Summary: ARPlaneAnchor.Extent property seems incorrect but changes to correct value af...
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: XI 10.99 (xcode9)
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Vincent Dondain [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2017-08-08 19:33 UTC by Larry O'Brien
Modified: 2017-08-22 07:25 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
screencast showing behavior (3.63 MB, video/mp4)
2017-08-08 19:37 UTC, Larry O'Brien
Details
Xamarin program demonstrating behavior (93.82 KB, application/zip)
2017-08-08 23:43 UTC, Larry O'Brien
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Larry O'Brien 2017-08-08 19:33:31 UTC
In ARKit, the system generates `ARPlaneAnchor` objects whose `Extent` property holds the size (in floating point meters) of the detected plane. 

When attempting to read the `Extent.Z` value, I get vanishingly-small numbers. When I put a breakpoint on the line, it appears that the .Z value is initially incorrect, but then when I step over it, it "magically" becomes correct.

I have attached a video showing the effect. Note that when the first breakpoint is hit, the `anchor`s `Center.Z` and `Extent.Z` properties are equal to the (small) .Y value. But when I step over the breakpoint, these values have changed to reasonable values (0.7m). 

Simply accessing the property in code does not seem to be enough to trigger the change. For instance, if I `Console.WriteLine($"planeAnchor extent {planeAnchor.Extent.X}, {planeAnchor.Extent.Y}, {planeAnchor.Extent.Z})");` the Extent value continues to hold the incorrect value.
Comment 1 Larry O'Brien 2017-08-08 19:37:53 UTC
Created attachment 24083 [details]
screencast showing behavior
Comment 2 Larry O'Brien 2017-08-08 19:39:19 UTC
In watching the video again, I note that the `Center.Y` property also changes from near-zero to a "Correct" -2 (meters from camera).
Comment 3 Vincent Dondain [MSFT] 2017-08-08 23:27:12 UTC
@larry can you please provide a test case so we can reproduce this? Also always add all version information.

I also wonder what happens in swift, any chance you're porting a sample and can look at some original swift code?
Comment 4 Larry O'Brien 2017-08-08 23:43:23 UTC
Created attachment 24087 [details]
Xamarin program demonstrating behavior

Behavior can be seen in `ARDelegate.PlaceAnchorNode` and `DidUpdateNode` methods.
Comment 5 Larry O'Brien 2017-08-08 23:48:46 UTC
I isolated the behavior in https://github.com/xamarin/private-samples/tree/ARKit_Exploration/ios11/PlacingObjects which is a close port of Apple's Placing Objects demo https://developer.apple.com/sample-code/wwdc/2017/PlacingObjects.zip

The relevant code in that is `PlaneDebugVisualization.init` and `.update`. I added basic logging code:

 NSLog("anchor init \(anchor.extent.x), \(anchor.extent.y), \(anchor.extent.z)")
       
and get results such as:

2017-08-08 13:42:41.354400-1000 ARKitExample[472:62265] anchor init 0.343202, 0.0, 0.366565
2017-08-08 13:42:42.032914-1000 ARKitExample[472:62021] anchor update 0.343202, 0.0, 0.366565
2017-08-08 13:42:42.133526-1000 ARKitExample[472:62021] anchor update 0.428282, 0.0, 0.566799
2017-08-08 13:42:42.233628-1000 ARKitExample[472:62021] anchor update 0.428282, 0.0, 0.570653

which seems correct. (.x and .z holding the extent of the horizontal plane)
Comment 6 Larry O'Brien 2017-08-08 23:50:54 UTC
Visual Studio Community 2017 for Mac (Preview)
Version 7.1 Preview (7.1 build 1267)
Installation UUID: 6b94f136-026d-4a5a-bf6d-af2c0d8dc019
Runtime:
	Mono 5.2.0.196 (2017-04/478c04a) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 502000196

NuGet
Version: 4.3.0.2418

.NET Core
Runtime: Not installed
SDK: Not installed
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.2.0/lib/mono/msbuild/15.0/bin/Sdks

Xamarin.Profiler
Version: 1.4.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Apple Developer Tools
Xcode 9.0 (13213.5)
Build 9M189t

Xamarin.iOS
Version: 10.99.3.19 (Visual Studio Community)
Hash: c5721c0
Branch: xcode9
Build date: 2017-08-04 14:58:21-1000

Xamarin.Android
Version: 7.3.1.2 (Visual Studio Community)
Android SDK: /Users/larryobrien/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.3   (API level 10)
		4.0.3 (API level 15)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)

SDK Tools Version: 25.2.5
SDK Platform Tools Version: 25.0.5
SDK Build Tools Version: 25.0.3

Java SDK: /usr
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Xamarin.Mac
Version: 3.99.3.19 (Visual Studio Community)

Xamarin Inspector
Version: 1.3.0-alpha2
Hash: fa030e0
Branch: master
Build date: Thu, 01 Jun 2017 20:55:26 GMT
Client compatibility: 1

Build Information
Release ID: 701001267
Git revision: 342f47be42098b95880cf4c6d957719b5fef53e3
Build date: 2017-07-12 17:43:22-04
Xamarin addins: e513cc1830b4daa75f67c608e2c722e811b23ab2
Build lane: monodevelop-lion-d15-3-xcode9

Operating System
Mac OS X 10.12.6
Darwin 16.7.0 Darwin Kernel Version 16.7.0
    Thu Jun 15 17:36:27 PDT 2017
    root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
Comment 7 Egorbo 2017-08-21 19:37:08 UTC
when I access Center and Extent properties:

(from logs)
Center: (-0.003668251, NaN, 3.820471E-37);  Extent: (0.2427081, NaN, 3.820471E-37)
Center: (-0.005034357, 3.820471E-37, -3.081979E-19);  Extent: (0.3391773, 3.820471E-37, -3.081979E-19)
Center: (-0.0003953725, 3.820471E-37, -3.081979E-19);  Extent: (0.2495491, 3.820471E-37, -3.081979E-19)
Center: (0.03730459, 3.820471E-37, -3.081979E-19);  Extent: (0.3540491, 3.820471E-37, -3.081979E-19)
....

y and z components should not have values like that. 
snippet to reproduce the issue:
https://gist.github.com/EgorBo/5cca491049d7040d6d0d8e3aaaf61be6
repro project:
https://www.dropbox.com/s/thquta972k0edrn/ArPlaneAnchorIssue.zip?dl=0

Steps:
1) compile & deploy the project to any ARKit-enabled device (6S or later)
2) point your device to a some horizontal plane and wait a while until DidAddAnchors is triggered.
(UI in the repro project is a blank white screen - it doesn't have to render ARKit to reproduce the issue)

Device: iPad Pro 10.5 with iOS 11 beta 6
XCode 9 beta 5 (9M202q)
Xamarin.iOS 10.99.321
Visual Studio for Mac: 7.2
Comment 8 Vincent Dondain [MSFT] 2017-08-21 21:29:57 UTC
Fixed in https://github.com/xamarin/xamarin-macios/pull/2517

I tried with the sample provided by Egor and the values now match Apple's doc and a Swift test case, with y = 0 and z around 0.3 when I tried.