Level with all lighting and contents
Procedural trusses allowed for the flexible, efficient, and quick creation of ceiling structures.
Using the HISM_Grid BP, the majority of other internal structures and interior contents could be populated with Hierarchical Instances of Static Mehses quickly and efficiently.
The new Procedural Sprinkler System afforded a more accurate, efficient, and visually appealing representation of the piping network within the warehouse.
Constraints
The VXR experience needs to run on the Meta Quest 2 at 72fps
The user should not notice a significant quality difference between the Vive and Quest experiences
Successes
Porting the VXR experience from a desktop-based Unreal Engine build to the Meta Quest was one of the most technically demanding projects I undertook at Viking. While I had had the opportunity to begin implementing best practices—leveraging interfaces and minimizing unnecessary casting—the project still carried significant performance overhead. This was primarily due to evolving scope and shifting user expectations before my time at the company, but these issues needed to be addressed nonetheless.
The scene contained an excessive number of high-poly meshes and ticking actors, which severely impacted performance on the Quest’s mobile hardware. To meet the strict CPU and GPU constraints of standalone VR, I conducted a comprehensive performance audit and systematically refactored core systems. This included eliminating unnecessary tick functions, consolidating actors, reducing draw calls, optimizing materials, and rebuilding several gameplay systems from the ground up with performance-first architecture in mind.
In many cases, rebuilding systems provided an opportunity not only to optimize but to improve usability and visual clarity. Features were redesigned to be more intuitive, lightweight, and scalable for standalone VR. Certain large-scale assets—such as portions of the warehouse environment—were strategically reduced or removed to maintain frame rate stability without compromising the core experience.
The resulting Quest-optimized version of VXR achieved stable performance within mobile VR constraints while preserving the integrity of the original experience. It was exceptionally well-received by users and ultimately became a benchmark for future Meta Quest development at Viking.
Flaws
Although the systems I streamlined for the Quest version of VXR were performance-heavy, they had originally been designed for maximum flexibility. Because client requirements frequently evolved, these systems were architected to support rapid iteration and feature expansion, resulting in broad functionality and modular—but resource-intensive—implementations.
Optimizing for standalone VR required a deliberate shift in priorities. To meet strict hardware constraints, I refactored these systems into more purpose-built, performance-focused implementations. The tradeoff was reduced generality: by removing bloated feature creep and abstraction layers, the systems became leaner and more efficient, but also more specialized. This represented a conscious opportunity cost—sacrificing some adaptability in favor of stability, performance, and reliability on constrained hardware.
Learnings
One consistent lesson from this process is that optimization often introduces rigidity. Across many projects, I’ve observed a recurring pattern: as flexibility and abstraction increase, so do system complexity and overhead—often at the expense of runtime efficiency. Conversely, highly optimized systems tend to be more purpose-built and constrained.
This is not an absolute rule. For example, the HISM_Grid Blueprint I developed demonstrates that it is possible to achieve both flexibility and performance through deliberate architectural planning. However, that balance requires intentional design and carries its own upfront cost.
Ultimately, these decisions come down to engineering judgment. Does the problem require a Swiss Army knife or a crescent wrench? The answer depends on the project’s constraints, the team’s capacity, and the long-term roadmap. Is there sufficient time and budget to invest in a more abstract, extensible system? Will that investment meaningfully improve future workflows or scalability? These tradeoffs are rarely binary, and navigating them effectively is a core part of technical leadership.