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 to the quest was one of the most challenging projects I undertook at Viking. Fortunately, most blueprint scripting had undergone most basic optimizations - using interfaces, not casting, etc. However, there was still a lot of bloat in the project. Shifting constraints and user expectations early in the project meant that there was an excessive number of meshes and ticking actors in the scene, causing lag. Many systems had to be rebuilt from the ground up. Through this process, I was able to improve those systems, making them more user-friendly, efficient, and visually appealing. Still, some things, like the size and contents of the warehouse, had to be cut. Regardless, this newer, more efficient version of the VXR was very well received by our users and became a poster child for future Meta Quest projects.
Flaws
While the systems I trimmed down for this version of the VXR experience were bloated, they were also very flexible. They had been created to respond to shifting client expectations at a moment's notice and had many features because of this. The opportunity cost of building this more efficient or specific system was also to create a more rigid one.
Learnings
The takeaway that optimization often means rigidity is something I have often found to be true. This is a pattern that I have seen repeated throughout many projects I have worked on. It is not an absolute truth; for instance, the HISM_Grid BP I created is very flexible and efficient. However, typically, as flexibility increases, so does complexity, resulting in decreased efficiency; the inverse also turns out to be true. I find this plays out as a matter of judgment. Does the problem at hand require a Swiss army knife or a crescent wrench? It depends on the needs of the project and the team. Do you have the overhead and time to create a more complex system? Will more time now justify improvements to future workflows? The answer depends.