AR and VR Development

CAD Models Do Not Drop Into an Engine

Mechanical CAD describes solids as trimmed surfaces and analytic curves. Engines draw triangles. Every conversion tessellates that geometry, and the tessellation setting decides whether a flange reads as round or faceted, and whether an assembly arrives at 200,000 triangles or 20 million. Assemblies built for manufacturing also carry every fastener, internal component, and hidden feature, while a training scene needs the parts a person sees and touches. Stripping the rest is most of the conversion work, and it has to be done without collapsing the subassemblies that must still move, which means keeping them as separate objects with usable pivots.

A standalone headset renders two eye views at a high refresh rate on a mobile class GPU with a tile based renderer, so draw calls, overdraw, and material count usually bite before triangle count does. Materials are the other thing lost in conversion: CAD appearances are not PBR materials, and a converted part typically arrives with a flat color, no UV layout, and no map set. Anything that has to look like painted steel, a worn label, or a specific machine on your floor gets authored after the conversion, not during it.

Units and axis conventions cause more bad imports than corrupt files. Unity is Y up and treats one unit as one meter by default. Unreal is Z up and its default unit is one centimeter. Revit, IFC, and most mechanical CAD are Z up. A model that arrives on its side, or 100 times too large, is almost always this and not a broken export.

Georeferenced site data adds a second problem. A model exported in survey coordinates can sit tens or hundreds of thousands of meters from the world origin, and engine positions are 32 bit floats carrying roughly seven significant digits. At 100,000 meters out, the gap between representable values is on the order of a centimeter, so vertices jitter, shadows crawl, and coplanar surfaces z-fight, and it gets worse the further out the geometry sits. The fix is rebasing the model near the origin and keeping the real world offset as data rather than as position. None of that can be scoped from a screenshot, so this is what has to come from your side first:

• Native CAD or a STEP export for machinery, or the Revit or IFC model for a building. A PDF drawing set or a rendered image is not a starting point for conversion.
• Which subassemblies have to move, open, or come apart, since only those need to survive conversion as separate objects.
• Real dimensions, or one known reference measurement, if the source geometry is not already dimensionally accurate.
• Photographs of the installed equipment, including what the model leaves out: guards, conduit, labels, signage, and wear.
• The part names and numbers the people doing the work actually use, which are often not the names in the engineering model.

What Measurable Has to Mean Before It Is Built

Measurable is a data schema decision, not a reporting feature added at the end. Something has to define what an attempt is, when it opens and closes, what counts as a step, what separates an error from a recoverable deviation, and what a passing attempt looks like. The useful events are specific: step entered, step completed, wrong tool selected, sequence violated, time in step, hint requested, attempt abandoned. Where that is not decided up front, the build ends up recording completion and a duration, and nothing anyone can act on.

On the integration side, the application posts statements to a Learning Record Store over HTTPS, and cmi5 defines how an LMS launches the activity and reconciles it afterward. That means you supply an LRS endpoint with credentials and a learner identification scheme. Identity is the awkward part on shared hardware, because a headset is a device and not a person: the working approaches are a code entered at the start of a session, a badge scan, or a session launched from a facilitator's device that already knows who is wearing it.

Correctness itself comes from a subject matter expert, and that person's availability is the schedule dependency most often underestimated. It is not a review pass at the end, it is source material. Real procedures usually have more than one acceptable order, and deciding which deviations are wrong rather than merely unusual is a judgment somebody in your organization has to make and stand behind, because the software will enforce it identically every time.

Device Support Decides Feature Scope

Mobile AR capability is per device, not per operating system version. ARCore runs only on Google's certified device list, and within that list the features are tiered: depth based occlusion, image and object tracking, body tracking, and geospatial anchoring each depend on the specific hardware, and geospatial anchoring additionally depends on Street View coverage at the location. On iOS, several ARKit features require an A12 chip or newer, and scene meshing depends on a LiDAR sensor that only some models carry. Designing around occlusion or a mesh of the room and then meeting the actual fleet is the standard way a scope changes late.

The no install path is WebXR, which gives immersive sessions in a browser on Android and on several headsets and removes application distribution entirely. What it costs is tighter performance limits, smaller asset budgets, and no vendor specific features. Immersive AR in Safari on iOS has lagged Android, so a link based AR experience on iPhone usually ends up as a USDZ model in AR Quick Look, which is a viewer rather than an application. Anything using the camera or an XR session on the web has to be served over HTTPS. The native equivalent of that gate on iOS is the camera usage description string in Info.plist: if it is missing, the app terminates the instant it requests the camera instead of showing a permission denial, which looks like a crash and gets debugged as one.

Headsets have their own limit worth knowing early. Passthrough is composited by the system, and access to raw camera frames is restricted at the platform level, so computer vision work that is routine on a phone may simply not be available to your application on a headset.

Signing, Accounts, and the Update Path

The developer accounts and signing keys should be in your organization's name from the first build, because they are difficult to move later. An Android application is identified by its package name and its signing key: a build signed with a different key cannot update an installed app, and changing the package name, or the bundle identifier on iOS, produces a new application rather than an update, so existing installs stay where they are and every device reinstalls. Organizational enrollment in the Apple Developer Program also requires a D-U-N-S number for the legal entity, and that registration is a paperwork step with its own lead time. It is a common reason a first build cannot be installed on the day it is ready.

Platform review is the specific mechanism behind the distribution difference: a public store update is queued for review before it reaches anyone, while a build delivered to enrolled devices through device management goes out when you push it. On iOS the private routes are TestFlight for testing and a custom app distributed through Apple Business Manager. Moving an already deployed fleet from consumer accounts to managed enrollment is not a settings change either, because on several platforms enrollment only happens during device setup, which means factory resetting devices that already have users and content on them.

Push a build to one real device, through the route you actually intend to use, while the scene is still gray boxes. Enrollment failures, account type mismatches, blocked domains, and provisioning problems are not fixed in code, and they surface at the worst possible moment when the first install attempt is also the delivery.

The Room, the Battery, and the Throughput

Inside out tracking needs something to look at. It locks onto texture and edges in the surrounding environment, so it degrades in dim rooms, against blank painted walls, and in spaces dominated by mirrors, glass, or large moving machinery. Roomscale movement also needs a genuinely cleared area, with the boundary set where a user at full arm extension holding a controller still cannot reach anything hard. Where the available space does not support that, a seated or standing design is the honest answer rather than a boundary people walk through.

Fit decides how the build is judged before the content does. Headsets have a limited interpupillary distance adjustment range, and users outside it get a soft or doubled image that they will report as bad software. Glasses wearers need either a spacer or prescription lens inserts, and inserts are per person and ordered against a prescription. Facial interfaces used by more than one person want wipeable covers rather than fabric.

Throughput is arithmetic worth doing before hardware is bought. Active runtime on a standalone headset is a couple of hours, not a working day, so a session schedule is really a battery schedule: how many devices, how long a module runs, how long between groups, and whether devices charge between sessions or run tethered to a power bank. Take module length, add fitting and instructions per user, then divide the group size by the number of headsets. If that arithmetic says one group consumes the entire day, it is a device count and scheduling problem to settle before the build, not after it.