Virtual Try-On (Optics)

Paid pluginsize Lplanned, not built

Indicative price, not an offer: €49/mo; AR/WebGL, face detection, support for 500+ frames

Generated from docs/plan/paid/virtual-try-on/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

WebGL/AR viewer for optics allowing customers to visualize frame fit on their face before purchase. Reduces 40% return rate to 15% by letting customers try frames virtually. Face detection runs client-side via TensorFlow.js; 3D frame models load per SKU. Admin uploads 3D models (glTF/GLB) and tags frames by face shape for recommendations.

The problem

Online glasses shopping has 40% return rate because customers cannot visualize how frames look on their face. They buy a style they like from photos, but when it arrives, fit or aesthetics disappoint. In-store opticians have mirrors; online shops have only product images. Virtual try-on cuts returns to 15%.

What it does

• WebGL/Three.js AR viewer with Three.js environment setup for rendering 3D frame models
• Client-side face detection using TensorFlow.js (runs in browser, no server processing)
• Camera access permission flow with fallback to photo upload for iOS Safari
• Frame position adjustment UI (translate up/down/left/right, rotate, scale)
• Mirror view toggle (flip horizontal, show reversed perspective)
• Save screenshot to device or email to customer
• Face-shape detection (oval, round, square, heart) and frame recommendation by shape
• Admin upload interface for 3D frame models (glTF/GLB files)
• Admin face-shape tagging (select recommended shapes for each frame)
• Try-on history tracking per customer (saves screenshots + frame choices)
• Mobile-responsive viewport (no horizontal scroll on iPad/iPhone)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Training custom AR models per merchant — bespoke 3D modeling is €20k+ per merchant; support burden unscalable. Reason: ML training cost + ongoing model maintenance.
• Facial analysis for cosmetic suggestions (shape recommendations beyond basic) — liability + algorithmic bias concerns; could suggest styles that demean or reinforce stereotypes. Reason: ethical risk.
• Integration with in-store AR kiosks or hardware — hardware lock-in; no standard API across vendors (Technolas, Zeiss, etc.). Reason: vendor fragmentation.

Data model

New table: frame_models (skuId, model_url, model_version, recommended_face_shapes (array), created_at, updated_at). SKU schema: add hasArModel (boolean), arModelId (fk). Customer schema: add tryOnHistory (array of {timestamp, frameSkuId, screenshot_url}). No schema migration needed for document storage.

API

• GET /api/frames/{skuId}/ar-model
• POST /api/try-on/screenshots
• GET /api/customers/{customerId}/try-on-history
• POST /api/frames/recommend-by-face-shape
• POST /api/admin/frames/{skuId}/ar-model
• DELETE /api/admin/frames/{skuId}/ar-model

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Frame model upload interface (drag-drop glTF/GLB). Model viewer preview (rotate, zoom). Face-shape tagger (checkboxes: oval/round/square/heart, select recommended shapes). Try-on usage analytics dashboard (which frames tried most, conversion rate from try-on to cart, try-on abandonment).

The seam — why this is paid

Core owns: SKU extensions, customer history storage, file upload infrastructure, generic AR viewer UI. Paid pack owns: pre-built 3D frame model library, face-detection TensorFlow.js integration, frame recommendation algorithm, AR viewer polish.

Support commitment: AR model training for new frame styles, face-detection library maintenance

Dependencies

• SKU/product system
• File storage (S3 or equivalent)
• Customer profile system
• Analytics/event system

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Loading a frame SKU with a 3D model renders the model in AR viewer (not blank/error)
• Face detection runs in-browser on camera feed (no server call for detection)
• User adjusts frame position in all 6 degrees (translate XYZ, rotate); model updates in real-time
• Saving a screenshot stores it on customer record; retrieving customer history shows all saved screenshots with timestamps
• A frame tagged for ‘round’ faces appears when calling recommend-by-face-shape with faceShape=‘round’
• An SKU without a 3D model shows error message ‘AR not available for this frame’
• Try-on history is private to logged-in customer (no cross-customer data leaks)
• Admin uploads a new 3D model; it appears in AR viewer within 30 seconds (cache busted)
• Mobile viewport properly scales AR viewer on iPhone SE 11 (375px width, no horizontal scroll)
• Analytics show count of try-on sessions per frame SKU aggregated per week

Risks

iOS Safari requires user permission for camera; if denied, no AR possible (fallback to photo upload mitigates but reduces UX). 3D model file size unoptimized (multi-MB .glb) kills AR load time, user leaves before trying (test < 500KB per model). Face detection fails on dark skin tones due to training bias, creates poor experience for subset of users. 3D model URLs exposed in network tab; competitor scrapes entire library. Model loading fails silently (network error); user sees blank frame, thinks feature is broken.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.