The Dynamic library build for the Metal Library fails when built from the downloaded copy. It uses the name of the download as the directory name which has spaces and does not give a syntactically correct file name. Renaming the folder in which the build files reside seems to resolve that problem. Then the header files for the Dynamic library get an access denied error when trying to compile. Why are these demos released with such trivial problems? Surely someone has tried to run it previously and the demo should have been fixed or the short Readme should have been updated with instructions on how to set it up.

In the presentation there was a reference to a Parent/Child relationship. The parent for doors and Windows might be Walls but the relationship between Walls or multiple Windows or doors would be that of a "Sibling" or "Peer" component to maintain logical consistency of the objects. I would also recommend a Junction Object, which means more than an Edge because it would describe the two peer objects that were being joined, and the angle of that junction between the objects. The Junction could also describe the shape of the junction to capture any curvature or discontinuity of the junction. Multiple junctions might also be peers because they would have a junction between other adjoining surfaces giving a more complete description to the structure of the room. The parent of all of these surfaces and junctions would be the Room itself. Such a description would be useful in an architectural review of the room structure.

I was happy to see the improvements in the Capture Side of RoomPlan, particularly the Polygon handling for the walls. Unfortunately, the Walls with 5 Vertices (Great Room Ceilings, Garage exteriors, etc) are projected in the viewers as having 4 Vertices and the top edge of the wall is projected upwards to the highest point between the two vertices leading to the peak. I am presuming that from this manifestation there must be some presumed 4-ness of all walls that leads to use of the Extent of the uppermost point rather than a projection of the lines to the point where the lines meet at the top. What viewer can be used that properly handles this misrepresentation of the imagery? I have imagery but your download only accepts pure files and will not take a USDZ file even retyped as TXT files

The definition for PolygonCorners given in the document at the index https://developer.apple.com/documentation/roomplan/capturedroom/surface/polygoncorners. Is woefully lacking. To validly link the sides of a polygon from the definition of a corner there needs to be an incoming and outgoing line descriptor that points to the next subsequent corner of the polygon. Just like a line has two endpoints, the edges of a polygon have corners to which any corner may be linked and it is an ordered set forwards and backwards, in the case of a 2D polygon. In the case of a 3D polygon, such a corner would likely have at the very least third directional connection giving depth of that point. In a 3D geometry you may have one point that has multiple points going in another direction much like the facet cuts of a Brilliant Cut Diamond. This sibling relationship of the corner points would complicate the definition but not impossibly so.

Precisely what is the difference between measurements from the LiDAR camera depth data and that provided by the TrueDepth camera? Where is the camera selection done so I can examine the code that sets up the LiDAR camera?

Why are there differences between the Sample application in the download and the code presented in the video? Specifically there are different Imports. I noticed that when I made references to some of the AR functions in. change I made it would not compile clean until I added an import of the ARKit and the Reality Kit even though both are in the RoomPlan import. Does the scope of definitinons get limited to that of the Imported symbols?

I have some confusion over the definition of MediaType versus DeviceType on the calls. It seems to me that because of similarities between the various cameras and the vague dichotomy between TrueDepth and LiDARData for measuring Depth there may be some need for refinement of the calls. My own preference would be to pass an Attribution Mask based on the bit position of the various characteristics of the device and having the bits prioritized so the BEST selection of the available devices would be chosen. For example With True Depth and LiDAR cameras both have depth data but the LiDAR is preferrable for accuracy reasons but some applications could get by with the photogrammetry mode True Depth camera if the LiDAR camera was unusable for some reason. I could see an option that said "Depth but no LiDAR" being selected. The same thing would be true for telephoto lenses versus combined with Wide or Ultrawide (or Hyper-Wide later). Audio streaming would have the same kind of issues with performance levels for input and output being narrowly defined. The question also arises why Device Type allows an array to be passed but not Media Type. It would seem reasonable for both.