Another option is to export the CapturedRoom as a parametric file that you can use later. CapturedRoom confirms to Encodable so it can be turned into a JSON file if you want to import it later. The only fly in the ointment is that it looks like the serialising is currently broken. It throws an error on re-importing dimensions. For our apps, we have written our own encodable struct to handle saving. But it means that we can pass the parametric room information between apps and people very simply. Obviously, this only works if you have control over the whole process.

Yes, the CapturedRoom.surface has a category that includes door(isOpen:Bool) which will give you that information. I have occasionally seen open doors classified as openings instead of doors that are open, so it's best to prompt the user to close doors to be sure.

But a quick and dirty way if your room is always rectangular is to find the rotation of the longest wall and rotate your floor by the same angle.

If you find the corner vertices of your walls you can create the floor using an extruded SCNShape. The tricky part is to make sure your vertices are in logical order, but after that, you can draw a bezier it using the x and z coordinates of your points. You'll have to rotate it by 90 degrees and position it but it should already have the correct rotation. This will help if your room is not rectangular. I'd add code but it's still on my list of things to do I'm afraid. But broadly my plan is to pick a wall and choose a corner, find the wall that's got a corner in the same position, presume it's the next in line and iterate through all the outside walls.

No specifically. Though you can infer the ceiling height from the height of the walls - presuming your walls are all the same height. Slipping and drop ceilings confuse Roomplan. It doesn't give you the floor either. The coordinate system if relative to the point the device was first fired up.

I just got it to work with this code  private var roomCaptureSessionConfig: RoomCaptureSession.Configuration = RoomCaptureSession.Configuration()   var arSceneView: ARSCNView!   var session:RoomCaptureSession!     override func viewDidLoad() {         super.viewDidLoad()         arSceneView = ARSCNView.init(frame: self.view.bounds)         self.view.addSubview(arSceneView)         roomCaptureSessionConfig.isCoachingEnabled = true         session = RoomCaptureSession()         session.delegate = self     }     override func viewDidAppear(_ animated: Bool) {         super.viewDidAppear(animated)         session.run(configuration: roomCaptureSessionConfig)     }      func captureSession(_ session: RoomCaptureSession, didStartWith configuration: RoomCaptureSession.Configuration){          arSceneView.session = session.arSession     }

My understanding is that if you want access to the RoomPlan session you need to use the data api rather than the RoomCaptureView. You create a RoomCaptureSession and hand that over to an ARSCNView and listen to all the callbacks from the RoomCaptureSessionDelegate. It will update you with a new version of the room as it finds it. It's up to you to then build the room from the data it gives you. This was the conversation I had with the apple engineer this morning, but I've yet to try it.

I have the same stutter scrolling on a pro-motion device when using a regular UIScrollview and a content offset. Older devices work fine, turning off pro-motion on the iphone 13 stops it too.

I'm now only getting the error on a device with iOS15 beta installed. And that device also seems to fail to sync with new server data. IOS14 devices have no errors and receive new records added by a different device. Syncing with private databases works fine on ios15 but public throws the error described above and never seems to receive updates.

I have the same problem wth the public database but mine is compounded with needing to be pre-seeded with a few thousand records. Some devices happily update when you add new records, some do not This may be an ios 15 beta issue). All are using the same apple id. I also found that the CDMR type was never added to the dashboard despite there being logical connections between entities in coredata, so I had to create that by hand. Deleting records from the public database through the dashboard never seem to be reflected on the local database.

Unparing a networked iPhone in devices and simulators worked for me too.