ARKit中“真实世界对象”、平面与AR锚点的技术差异问询

Great question—let’s dive into the technical differences between real-world objects, planes, and AR anchors in ARKit, plus clarify how the hit test methods tie into each concept.

1. Real-World Objects #

These are physical, distinct items in the user’s environment that ARKit can detect and track as unique 3D entities.

• ARKit uses computer vision to recognize them: either via pre-trained custom object detection models, or by matching visual features of arbitrary objects you’ve scanned beforehand.
• When you run hitTest(_:types:) with the .existingObject type, ARKit checks if the hit ray intersects the 3D bounding box (or mesh, if available) of a previously detected real-world object.
• Key trait: They’re content-specific—ARKit identifies them as individual physical things, not just generic surfaces or spatial markers.

2. Planes #

Planes represent flat, horizontal or vertical surfaces (like floors, tables, walls) that ARKit detects by clustering visual feature points from the camera feed.

• ARKit continuously refines the plane’s position, orientation, and extent as it collects more environmental data.
• Hit testing for planes uses .existingPlane (for the full estimated infinite plane) or .existingPlaneUsingExtent (to prioritize the plane’s known, mapped boundary).
• Key trait: They’re surface-focused—ARKit doesn’t care about the surface’s material (wood, concrete, etc.), only that it’s a flat, trackable area.

3. AR Anchors #

Anchors are the foundational spatial reference points in ARKit. They act as virtual markers that tie virtual content to a specific position and orientation in the real world.

• All detected real-world objects and planes automatically create corresponding anchors (ARObjectAnchor and ARPlaneAnchor respectively) to maintain their spatial position over time. You can also create custom ARAnchor instances manually to pin virtual content to any spot.
• Running hitTest(_:types:) with .existingAnchor checks for intersections with any anchor’s transform, regardless of whether it’s linked to a plane, object, or custom point.
• Key trait: They’re spatial glue—they ensure virtual content stays aligned with the real world, even as the camera moves.

• Purpose:
  • Real-World Objects: Track unique physical items (e.g., a toy car, a poster)
  • Planes: Provide flat surfaces to place or interact with virtual content
  • AR Anchors: Maintain spatial consistency for any virtual content, acting as a reference point
• Tracking:
  • Real-World Objects: Feature matching/object recognition; tracked as 3D volumes
  • Planes: Feature point clustering; tracked as evolving 2D surfaces
  • AR Anchors: Transform matrix tracking; auto-created by ARKit or manually placed
• Hit Test Behavior:
  • Real-World Objects: Returns intersections with the object’s bounding box/mesh
  • Planes: Returns intersections with the plane’s surface (infinite or mapped extent)
  • AR Anchors: Returns intersections with the anchor’s origin/transform

The three hitTest methods you referenced serve distinct use cases:

• ARSCNView.hitTest(_:types:): Built for SceneKit-based AR experiences. Casts a ray from a screen point into the 3D scene, checking intersections with both real-world elements and virtual SceneKit nodes.
• ARSKView.hitTest(_:types:): Tailored for SpriteKit-based AR. Maps real-world hits to the 2D SpriteKit coordinate system, making it easy to place or interact with 2D sprites.
• ARFrame.hitTest(_:types:): A lower-level method that operates directly on camera frame data. It returns raw hit results without tying to a specific view’s rendering system, useful for processing hit test data outside a view context.

Hope this breaks down the technical nuances clearly! Feel free to ask follow-up questions if you need deeper details on any specific part.

内容的提问来源于stack exchange，提问作者smartdog