Constantine Peros

What if the interface was the room you're standing in?

The headset on the shelf stands in for the biggest slice of the work in here: VR and mixed reality built in Unity for Meta Quest, Apple Vision Pro, HTC Vive Focus and HoloLens.

RehearsalXR

RehearsalXR is XRTech's simulation platform for rehearsing conversations and procedures that are too expensive, too rare or too sensitive to practice for real. A trainee stands in a believable environment, talks to photorealistic characters, and works through a branching scenario where each choice changes what happens next.

The public demo is a caregiving scenario called The Wallet. Your mother cannot find her wallet, she is frightened, and the fear is coming out as anger. Three decisions, nine paths, about four minutes. It runs in a browser, so it can be tried without a headset at all.

What makes the platform reusable is that scenarios are authored as data rather than code: a graph of conversational beats, each with its line, its environment and its branches. The same engine has been pointed at veteran peer support and suicide prevention, aviation pre-flight inspection, automotive diagnostics, warehouse and forklift certification, clinical knowledge checks, and conversational language learning. Environments are full 360 captures, so a customer can drop in a photo of their own workplace and train people in the room they actually work in.

One content base runs on Quest, desktop, phone and the web. The platform detects the device and offers the matching controls: controller rays in VR, click on desktop, tap on mobile. Every session logs the choices made and any quiz results, so a trainee's run can be reviewed afterwards rather than taken on trust.

What's in this pile

• Joshua Tree Music Festival, stereoscopic 360 sets from six artists, shipped on the Meta Quest store for Quest and Apple Vision Pro
• VR Concussion Therapy, 25+ rehabilitation modules on the B.I.T.S. platform, with a clinician's tablet driving the headset
• Guardians of the Kelp, my first VR build: urchin AI, a great white, and a hammer
• AR Surgery, HoloLens and MRTK in an operating room
• Secret of the Menehune, location-based AR anchored to real Waikīkī landmarks
• Björk's Vulnicura VR album, launched on the Meta Quest store with PulseJet Studios
• Battle Tank Simulator, an Oculus Rift project with hand tracking

The Process

Every one of these is the same set of problems wearing different clothes. Frame budget first: a Quest is a phone strapped to your face, and a scene that runs at 90fps on a desktop will make people sick on standalone hardware. Then interaction, where hands, controllers, eye tracking and gaze each give a different right answer per device and per user. Then comfort, which is not a polish item but a design constraint you build around from the first prototype.

The rest is Blender: reducing, re-baking and re-lighting art until it renders at frame rate without looking like a compromise.

Outcome

Shipping to Quest, Vision Pro, Vive Focus and HoloLens in the same few years has been the best possible education in what these devices are actually for, and in how differently each of them wants to be talked to.

What if a language app could tell you were too tired to learn, and got out of your way?

Gabb is a neuroadaptive VR language platform out of UCLA, backed by Pharrell Williams, UCLA, The Clinton Foundation and Verizon. It adapts every lesson to the learner's real-time cognitive state — stress, focus, fatigue, read from biosensors rather than inferred from a streak counter. Six languages, pronunciation scored at the phoneme level, vocabulary built around the trip you are actually taking.

The founder had a working prototype he had vibe-coded himself, and no production backend under it. He found me the way people find contractors now — he asked an AI who should build it — and XRTech took the whole server side.

The Process

The brief was the part a prototype never has: real accounts, real money, real student data, and a school district's tolerance for none of it going wrong. My rule on this kind of build is to own the application logic and rent the things that carry liability — I want auditable third parties I can hold accountable for auth and payments, and learners signing in with credentials they already trust.

• Auth — Clerk. Google SSO as the front door, so no password ever lands in our database. Sessions, org membership and role claims come out of Clerk and drive what a learner, a teacher or an admin can see.
• Data — Supabase. Postgres with row-level security as the actual enforcement boundary, not a convention in the API layer. Learner sessions, per-word accuracy, neural profiles and class rosters, with the policies written so a teacher reaches their own roster and nothing else.
• API — Render. The service layer that owns scoring, session state and the adaptive pacing logic, kept off the client where it can be read and gamed.
• Billing — Stripe. Consumer tiers alongside a per-seat School plan, with entitlement checks derived from subscription state rather than stored as a flag someone can flip.
• Delivery — Vercel. The web client and preview deploys, so the founder can see a branch running before it merges.

The neural profile view is where the whole idea becomes visible: eight regions — hippocampus, Broca's and Wernicke's areas, prefrontal and motor cortex, visual cortex, parietal and temporal lobes — lit by live activation as the learner works, and the same signal that drives the picture drives the difficulty.

The school dashboards run on top of the same session data, banding a class into strong, steady and struggling by accuracy so a teacher sees who needs the next ten minutes.

Outcome

The platform is live and taking real sign-ups, with early traction among schools in Southern California. It is the same stack I reach for on every SaaS build — Supabase, Clerk, Render, Stripe, Vercel — and this is the clearest case for why: one engineer stood up auth, data, an API, billing and hosting for a product handling student data, and the parts most likely to end a company are run by people who do only that.

What if a surgeon never had to look away from the patient?

A mixed-reality operating-room digital twin, built on Microsoft HoloLens. It is the first fully customizable mixed media solution for surgical teams, keeping imaging, notes and reference material in the surgeon's field of view instead of on a monitor across the room. The headset tracks where the surgeon is already looking, so the information follows their attention instead of asking them to break it.

The Process

This was built for a surgical technology client, in a stack of HoloLens, Unity and the Mixed Reality Toolkit. Working in an operating room removes most of your usual inputs: no controllers, no touching anything, no time to fight a menu. That pushes everything onto hand gestures, gaze and voice, and onto making the gesture set small enough to stay reliable when the person using it is concentrating on something else entirely.

The other half is spatial mapping: the headset builds a mesh of the room, and content has to stay locked to real surfaces and real equipment as people move around it. Getting anchors to survive an operating theatre's lighting, reflective surfaces and constant movement was the difference between a demo and something a clinician would actually trust.

"Fully customizable" is the requirement that shaped the architecture: every hospital, every specialty and every surgeon wants a different layout, so the panels, sources and gesture bindings all had to be configurable rather than hard-coded.

Outcome

Medical XR is the clearest case I've worked on for mixed reality being genuinely better than a screen: the information goes where the attention already is. It's also the least forgiving. The bar for reliability in an operating room is nothing like the bar for a game.

The platform was later ported to Apple Vision Pro. Press coverage followed, including features from Gizmodo, Metro, TechRadar, Futurism and others, and it was recognized among a major national magazine's picks for the year's most notable inventions.

What if every destination tour got more interactive with hidden stories, and places?

An iOS AR experience for the Anheuser-Busch Brewery Tour, built with AR Foundation and Google Cloud/Geospatial Anchors. It features photo ops with life-sized Clydesdales, a 360° brewmaster's suite, and an animated, step-by-step beer-making journey.

The Process

This tour was built to be more than a novel AR moment. It is a fully interactive, location-aware journey powered by "AR Everywhere," a proprietary AR-browser platform I worked on at Another Reality Studio. It lets clients build custom on-location experiences (tours, exhibits, scavenger hunts) in a modular, cost-effective way.

For the brewery, we customized it into three stops, each locked precisely to its location with Google Cloud Anchors and Geospatial Anchors in Unity AR Foundation 5:

• Stop 1: pose with life-sized Clydesdales and a dalmatian in the stables
• Stop 2: explore a 360° photosphere of the brewmaster's exclusive suite
• Stop 3: watch the entire beer-making process come alive with maps, animations, and video

The biggest challenge was keeping everything aligned and responsive both indoors and outdoors. Cloud Anchors needed careful planning for persistence, while Geospatial Anchors tied outdoor content to exact GPS coordinates. Each scene was optimized for quick loading and smooth interaction on iPhone and iPad. For the brewing process itself, we turned a static poster into a living AR guide walking visitors through every stage from mashing to shipping, with an on-screen compass leading people from stop to stop.

Because AR Everywhere is hardware-agnostic, this same architecture can power future tours, exhibits, or brand activations without starting over.

Outcome

This project sharpened my ability to engineer location-aware AR at scale, solve complex spatial computing challenges, and deliver memorable, on-brand experiences through close creative collaboration.

What if artificial turf installation could be measured and visualized instantly on site?

ForeverLawn is a national leader in synthetic turf, serving clients from backyards to Disney and ESPN. They needed a tool to help their dealer network work smarter, so I built an AR app that lets reps measure areas with LiDAR, preview turf in real time, and generate professional estimates on site.

The Process

This app had to be iOS-only, built around the iPhone's LiDAR sensor for accurate, high-performance measurements and visualizations.

• AR area measurement: users drop AR anchors at corner points; when closed, the polygon fills with a realistic turf shader. Validated against Apple's own Measure app and Polycam, it holds over 98% accuracy even on large spaces like basketball courts.
• High-performance turf simulation: the turf material was GPU-optimized to render thousands of blades of grass in real time, keeping smooth framerates from small yards to full sports fields
• Custom PDF export: a native iOS plugin generates templated PDF reports embedding area data and preview images, which reps can instantly email or share via NativeShare
• Advanced tools: hole-cutting, point saving for future edits, and drift correction for reliable measurements over long sessions

Outcome

This project sharpened my ability to engineer location-aware AR at scale, solve complex spatial computing challenges, and deliver memorable, on-brand experiences through close creative collaboration.

What if the revenue of local small businesses could be boosted through an AR app?

Together with DAS Labs, we built an app that helps tourists explore the town of Ouray, Colorado and discover nearby restaurants, bars, and points of interest through their camera, helping local businesses catch the attention of visitors, attract more foot traffic, and increase revenue.

The Process

Using the Google Visual Positioning System (VPS) and the Google Places API, the app locates a visitor precisely enough to place landmarks and points of interest (POIs) in real time.

The app showcases a wide range of attractions (restaurants, bars, hot springs, hiking trails, ice climbing spots and gold mines) so visitors can fully enjoy their stay in Ouray while local businesses gain visibility. Combining Google VPS with the Places API enabled accurate positioning, automated information loading, and intuitive AR navigation.

Outcome

The Ourway app gives tourists visiting Ouray, Colorado an immersive way to explore the city, discover local businesses, and boost revenue for the small businesses that depend on foot traffic.

What if trading cards came to life in augmented reality?

An AR card game where monsters battle it out with magical elemental powers before your very eyes. Scan your deck of cards one by one with your phone. Once both teams are set, battle your opponent in AR.

The Process

Built in Unity with the Vuforia plugin, the game recognizes individual playing cards on any surface through an Android or iOS camera, then renders two teams of three monsters that fight it out until a winner is decided.

The core mechanic is an elemental damage system in the spirit of Pokémon: an expanded rock-paper-scissors, where each monster's type is super effective against some types and weak against others. Fire creatures deal double damage to grass creatures but only half against rock. I stored each element in a two-dimensional array referencing a damage modifier against every other type.

Sourcing 3D assets from marketplaces like TurboSquid and CGTrader was its own challenge, since there's no standard file format between sellers. I learned to extract textures in Blender and re-import them into Unity so every character would render with cohesive colors and materials during a battle.

Outcome

This was a fun project that just kept growing: 22 monsters, 44 unique primary and secondary attacks.

What if painting a digital world was at your fingertips?

A body-tracking "Splatoon-type" painting game built to demonstrate the power of Azure Kinect DK technology. Players use their whole bodies to digitally paint on the walls with projections. No joysticks, no controllers.

The Process

This was a fun collaboration with the Create(X) projection space at the University of Hawai'i at West Oahu and the Laboratory for Advanced Visualization & Applications (LAVA). Our small team was tasked with a new interactive demo to help visitors engage with the projection screens.

Groups of players controlled a paint sprayer with their arms to cover as much of the world in color as possible, with a scorekeeping mechanic tracking who'd covered the most area. We built the game in Unity; the hardest part was working with multiple Azure Kinect DKs at once. The tracking system tended to lose a player moving from one sensor to another, or double-count someone visible to two nearby cameras.

One approach was calculating the ratio of distances between body parts to identify individual players, based on physical proportions or limb angles, but that broke down when two nearby players were a similar height and pose. In the end we used player position data to disambiguate: if a player was visible to more than one camera, the game only displayed them from whichever camera they were closest to.

Outcome

Multiple projectors were set up with Azure Kinect DKs tracking every section of wall around the lab, a setup with promising applications for art exhibits, advertisements, and conventions.

What if underwater robotic research didn't have to stop to recharge?

As lead electronics engineer, I developed and assembled a resident underwater remotely operated autonomous vehicle for research at the University of Hawaii. The goal: a vehicle that self-charges underwater, so it never has to surface mid-mission.

The Process

Based on the Blue Robotics BlueROV2, this vehicle operates remotely and wirelessly collects data from a suite of sensors on ocean conditions. For over a year I worked with graduate students at the Robot Autonomy and Navigation (RAN) lab, assembling and testing its circuits. It carries an onboard Linux computer for self-piloting missions, with the ultimate goal of piloting via optical and acoustic modems for data transfer.

The key goal of my work was making the ROV recharge itself between missions on a docking platform, like a Roomba, and secure itself in place with powerful electromagnets. The obstacles were constant: remote operation, data transmission, corrosion. It demanded both computer science and electronics skills, drawing on my Arduino experience and my two Associate of Science degrees in General and Digital Electronics.

I drew and built both sides of that system: the vehicle's own harness, and the permanent dock it returns to. The diagrams below are the ones the soldering iron followed: every sensor, thruster, modem and induction coil that had to keep working while submerged.

Outcome

This is one of the longest-running projects I've worked on. It took over a year before every component was assembled and tested in the water. The ROV has since supported several graduate students' theses, now that it can run programs and execute commands on its own.

What if the interesting part of a project is the part with wires coming out of it?

Before the Unity work there was a soldering iron. Circuit design, microcontrollers, sensors, and the firmware that ties them together. The layer where software finally has to admit that the physical world exists.

This is the electrical half of the bench. The printed parts that hold all of it in place are on the 3D printing page.

Where it comes from

I hold an Associate of Science in Digital Electronics and General Electronics, but the degree I reach for most often is the Bachelor of Science in Computer Science from the University of Hawaiʻi at Mānoa. Nearly three years as lead electronics engineer at the university's Robotic Autonomous Navigation lab turned the electronics side into practice: schematic capture, board assembly, testing, a great deal of soldering, and the low-level C, C++ and Python that talks to sensors and motor controllers. The resident underwater ROV came off that bench. A vehicle that finds its own dock and charges itself underwater is an electronics problem long before it is a software one.

The pattern that keeps repeating is a small board, a sensor, and one honest question about what that sensor can actually tell you.

Face tracking, end to end

An old Android phone runs a Unity app built on OpenCVForUnity. It finds a face in the camera feed, works out how far off center that face is, and sends a correction over a USB serial link to an ESP32. The ESP32 drives the two servos. Print the mount, flash the board, install the app, and the rig follows you around the room.

The awkward part was the link between the phone and the microcontroller. Unity on Android has no USB serial support of its own, so the project wraps a native Android serial library and exposes it to C#. I published that wrapper separately, because it is the piece anyone doing phone-to-microcontroller work will need, and the piece least likely to be fun to write twice.

Using a phone as the vision sensor is the point. A handset three generations old is still a calibrated camera, a fast processor and a battery in one package, which beats bolting a webcam to a single-board computer. The mechanical side of the rig is on the printing page.

Reading a mechanical event without touching it

A magnet rides the blowback assembly of a gas blowback airsoft platform. A hall-effect sensor watches it from a fixed distance. When the bolt cycles, the field at the sensor changes, the unit registers a shot, and it pulses a laser so a target system can score the hit.

Choosing a hall sensor over a microswitch is the whole design. There is no contact, so there is no wear surface, no bounce to debounce, and nothing that eventually breaks from being struck a few thousand times. The sensor never touches the moving part. It just notices it going past. It also means the unit does not care how the replica is finished, because a magnetic field reads the same through paint or plastic.

Paired with a laser and a target, this turns a training replica into an input device for a virtual range. I built it as R&D toward a government training simulator, and it is still a prototype. The printed housing is the part that has to survive the recoil.

Randomness out of a laser

Point a laser at a rough surface and the reflected light interferes with itself, producing a shifting grain called speckle. It is not a pattern you can compute ahead of time. It falls out of the microscopic texture of the surface and the air in between.

The Eye of Sauron is an old Android phone with its camera pointed at exactly that. The app samples the speckle, turns it into entropy, and serves the result over an embedded web server on the local network. There is a REST API, dice endpoints for the obvious use, and a statistics page that runs a chi-squared test on the output, so the quality can be checked rather than taken on trust. When the camera sensor glitches, the affected data is discarded instead of used.

The clip is a close-up of a real speckle from my own laser, shot at enough zoom to be grainy in more than one sense. The housing that holds the phone and the laser in fixed alignment is a printed part.

Watching an environment

A temperature and humidity sensor on an ESP32, showing live readings on a small display as an animated vine. It began as a display experiment and became a controller. The firmware is split into a sensor manager, a display manager, a real-time clock, a Bluetooth manager, an actuator controller and a task scheduler, so adding a fan or a mister is a wiring job rather than a rewrite.

Splitting firmware up like that matters more on a microcontroller than on a desktop. There is no operating system to schedule anything, so if the display code blocks while it draws, the sensor read is late and the clock quietly drifts. The vine was the excuse to build all of that. Animating a growing plant frame by frame on a small display is a far harder scheduling problem than printing two numbers, which is most of why it was worth doing. A related idea, live weather turned into color on a wall of LED panels, has its own page.

A board of my own

Most of the above lives on a breadboard. The 8-motor driver board is the one I laid out properly: an RP2040 Zero on a carrier with four L293D drivers, which is eight motors driven bidirectionally from a single board. An 820µF bulk capacitor sits on the motor rail with 100µF per driver, because motors are electrically rude to everything sharing their supply. Screw terminals for the outputs, breakouts for 3.3V and 5V, and a status LED on a spare pin.

The control protocol is deliberately dull. The board listens on UART for eight signed bytes, one per motor, where the sign is direction and the magnitude is duty cycle. Anything that can write a byte can drive it.

Toolchain work

Getting C onto a Raspberry Pi Pico from Windows was irritating enough that I wrote down the short version: the Arm toolchain, CMake and Ninja, compiling to an ELF and converting it to a UF2, with no IDE in the way. The repository and the four-minute walkthrough exist because plenty of people hit the same wall.

Outcome

Every XR project in this room touches hardware somewhere: a LiDAR sensor, a depth camera, a headset's tracking volume, a drone. Knowing what those parts do at the pin level is what turns a demo into something that still works after you hand it over.

What if the outside weather influenced the lights in your home?

A Python program that pulls from the OpenWeather API for a given location and displays the conditions as color patterns on linkable Nanoleaf light panels. Take the guesswork out of whether you need an umbrella. The lights will tell you.

The Process

The idea came from the LAVA lab at the University of Hawai'i, which has no doors or windows to see the weather outside. We'd often be surprised to leave and find it was already dark, or raining. That inspired a program that constantly pulls weather data for supplied GPS coordinates and displays a representative color pattern on the panels, so everyone stays aware of the world outside.

Using Python and POST requests to talk to the WiFi-enabled Nanoleaf panels, I mapped colors to conditions: a dim purple-and-black flicker at night, pastel gradients for sunrise and sunset, blue-and-green flashes for Hawaii's tropical rain, and dark colors with bright flashes for thunder and lightning. Brightness scales with temperature, brighter when hot and dimmer as it cools, with color selections for nearly every weather pattern, from snowfall to volcanic ash.

Outcome

This was a fun, rewarding way to learn about working with API calls and POST requests, and it made me confident pulling and parsing JSON data from live APIs.

What if the hobby and the job kept pointing at the same place?

The board is here because I surf, and because the ocean shows up in a surprising amount of my professional work.

Why it's here

Living on Oʻahu means the water is a few minutes away in almost any direction, and surfing is the part of the week that has nothing to do with a screen. It's also the reason a lot of the rest of this room exists.

I'm PADI scuba certified, and I hold a Marine Science Technology certificate in Aquaculture and Aquarium Science from Saddleback College, which is a strange thing to find on a Unity developer's résumé until you see what it led to. It's why I spent nearly three years as lead electronics engineer on a self-charging underwater research ROV, and why my first VR project was a game about kelp forests collapsing rather than something with spaceships in it.

Being in the water regularly is also the best possible calibration for VR. You learn very quickly what real presence feels like, the scale and motion and weight of things, and how much of it a headset is still faking.

Outcome

Surf, dive, print, solder, ship. The ocean keeps ending up in the work, and I've stopped fighting it.