PERCEPT / TECHNICAL EVALUATION
Image tracking SDK evaluation
Use an image on a physical surface as the reference for an AR experience. Percept accepts evaluation requests for planar image targets and custom native integration. Start with the target and the conditions in which people will use it.
Image targets: start with the printed surface
Describe whether the target is a flat card, manual page, package panel or product label. Provide the final artwork and its physical dimensions if available. A digital design alone does not capture the effects of printing, glossy coatings, folds or changes in lighting. Include photographs of the physical print when possible, and identify which areas must remain visible.
Detection, pose tracking and recovery are separate tests
A successful initial detection is only one part of the experience. An evaluation should also measure how stable the overlay looks when the camera moves, when tracking is lost, and what happens when the image comes back into view. Define expected distance, viewing angle, motion and partial occlusion. Agree on the measurement method before comparing engines; frame rate alone does not describe tracking quality.
Unity and native mobile integration
For Unity, identify the Unity version, rendering pipeline and any existing AR or camera framework. For native iOS or Android, describe who owns the camera capture session and how frames and timestamps are made available. Coordinate conventions, image orientation and lifecycle behavior need an explicit integration contract. Percept integration feasibility and SDK interfaces are discussed during evaluation; a public drop-in package is not available yet.
Build a repeatable target test
Use the same physical target, devices, camera settings and sequence of movements for each candidate. Include a normal-use sequence, a difficult-lighting sequence and a loss-and-recovery sequence. Record failures as well as successful runs. Compare initialization time, loss events and overlay stability alongside memory, battery and thermal constraints. Thresholds should come from your application, rather than an unrelated vendor demo.
No reference image yet?
You can begin with a description of the object or surface and the desired user interaction. A photo of a similar surface can help discuss feasibility, but it is not a substitute for testing the actual target. We will agree on what data is needed before an evaluation starts. If the target is a three-dimensional object rather than a planar print, use the object tracking guide instead.
3D object tracking for your physical product ↗What to include in your evaluation request
- Target type, physical size and expected number of distinct images
- Artwork or photographs, if available; otherwise a description of the surface
- Devices, Unity or native platform, and camera framework
- Expected distance, viewing angles, lighting and recovery behavior
- Evaluation deadline, deployment size and any data-handling restrictions
Project-based integration with the Percept engine team.