Selected work

Spectr

What started as an architectural BIM viewer in VR has grown into the modular framework behind nearly everything VR Base ships — industrial simulations for major clients, in-house games, and the BIM collaboration tool that kicked the whole thing off.

Where it started

Spectr began as Spectr BIM — a way for architectural clients to upload their BIM models to our platform and step inside them in VR or through a web stream. The experience is multiplayer: you and your collaborators walk through the model together, change materials, switch between day and night lighting cycles, hide or highlight structural elements like walls and pipes, take measurements, and record sessions for later review.

Where it is today

That BIM-viewer core grew into something much broader. Today, Spectr is the framework behind a wide catalogue of work — industrial simulations and interactive collaboration tools for clients including Kellanova, Mars, DEME, Lantis, and SPIE. Every client project shares the same Spectr foundation but layers custom code on top, so we ship bespoke experiences without rebuilding the common systems each time. The same framework also powers in-house VR Base games like Temple of Puchino and Nautilus.

My contribution

In 2020 we laid the foundation for what Spectr is today. We started with a team of three and have continued developing it as the studio has grown past nine developers. I laid the groundwork for the modular architecture, implemented the multiplayer framework, built tools that automate repetitive setup, and helped design the feature-selection system that lets each project opt into exactly what it needs — locomotion, interaction, hardware integrations, BIM tooling — without dragging the rest along. That modularity is what makes the per-client custom-code approach viable at the scale we now run it.

Blackwood

A free-roam co-op VR medieval shooter. You play as a knight wielding a crossbow, holding back the evil that has fallen upon the land.

The project

Blackwood is a location-based co-op VR experience built for free-roam arenas, supporting 1–12 players per session. Players wear knight armor and weapons, move freely in physical space, and defend their hometown — called Blackwood — across a series of escalating encounters with the evil forces overrunning the kingdom.

My contribution

As project lead, my responsibility was bringing Blackwood to a good end. I laid out the development timeline, scoped tasks across the team, and coordinated the milestones — but I also stayed in the codebase, implementing core features myself.

Specifically, I built the AI behaviour systems for the enemy waves, the leaderboard infrastructure, the narrative and dialogue triggers, and a significant portion of the gameplay loop.

Cargo

The studio's first true free-roam team deathmatch. Two arenas stitched into one 27 × 13 m space.

The project

Cargo is VR Base's second largest team deathmatch, and the first where two opposing teams could move freely between each other rather than fighting from fixed positions like a tower shooter. We stitched two VR arenas together to create a single 27 × 13 m playable space.

My contribution

This was the first big project I led at VR Base. Because it was our first free-roam team deathmatch, much of the work was solving problems that don't exist in fixed-position shooters: players hiding in geometry, players walking through walls, players camping with infinite ammo. A lot of the project was finding the right balance between traditional shooter design and the unique advantages — and constraints — of LBE VR.

I also got my first deep dive into fast-paced multiplayer networking, which was new territory for me at the time. Beyond the systems work, I did the level design, built some of the 3D models, and put together the full gameplay loop.

Performance, Tools & Systems

VR forgives nothing — a missed frame is a noticeable hitch. Years of shipping PC VR titles have made performance work part of how I write code, not a phase tacked onto the end. Most of the editor tools and runtime systems I've built grew directly out of that constraint.

How I approach performance

Performance work is measurement first. I lean on the Unity Profiler and Memory Profiler for CPU and GC, and the Frame Debugger and RenderDoc for GPU and draw calls. The goal is to know where time is actually going before I change anything — guessing burns days.

Tools & systems I've built

When the same performance problem shows up across projects, I write a tool for it. A few highlights — most of them sit at the intersection of VR performance and large BIM scenes, and some live on GitHub:

• Realtime occlusion culling — CPU-based, multi-threaded occlusion culling that runs every frame with no bake step. Massive draw-call drops on large or constantly-changing scenes that Unity's baked culling can't handle.
• Scene streaming — automatically splits massive BIM scenes into chunks and streams them in and out at runtime, so memory stays bounded. Makes real-scale building models loadable in VR without blowing the budget.
• Sequential async light baker — bakes a queue of scenes one after another with live progress. Pick a 'develop' profile for fast iteration or 'release' for final quality, and the whole project re-bakes without having to reconfigure each scene by hand.
• Area light placer — automates the tedious process of manually placing area lights in windows to fake ambient light coming in. Open source.