Step into the shoes of a technician as you perform a routine procedure at a substation. Start at the office, grab your PPEs, enter the site, and perform the gas switching procedure. Watch the full playthrough below.
This is the second Substation project I've worked on. The first version is a walkthrough featuring this same environment, discussing all the equipment found onsite.

At the time of this project, this had the most complicated interactions I’ve had to design. So many pieces attached to each other, but the interaction system I wrote was able to handle it intuitively. It’s very fun and satisfying when assembling the SF6 gauge yourself. Every dial and button gets interacted with, and the gauge has a digital screen that actually animates. The hoses are dynamic and add a bit more realism to everything. If I was able to work on it again, I would improve the placement with the hands to feel more immersive. Timestamp is 9:00-11:00.

The primary concern with this project was rendering everything in the substation. It’s a giant open space with nothing blocking the view. We couldn’t split the scene or use occlusion culling. I experimented with LODs but didn’t find it satisfactory. We ended using our batching tools to squeeze everything into as few draw calls and batches. Interestingly, I remember we were able to get both below 100 calls/batches which is the recommended guideline for Quest, but our poly counts were over a million! We were getting acceptable frame rates ranging around 30-72. While 40 is very low, it worked out because the substation was completely static and the Quest had an interesting feature called space warp that would interpolate frames, so the low frames were hardly noticeable. When the user needed to interact with something, they usually looked down away from everything, which was a happy coincidence.

Another issue I’m very proud to have solved was that the app would sometimes crash when trying to load the substation scene. It was very confusing to debug or reproduce; there were no errors or crash logs. Plus it only occurred on the headset. Based on these signs, I looked more into the real-time stats on headset when the crash occurs. I noticed every time it happened, the available memory would RAPIDLY drop to zero, probably causing the crash. The solution was to load an empty intermediary scene and to switch to IL2CPP, which used 64 bit memory address. I think loading such a large scene prevented the app from freeing up enough memory addresses, eventually causing it to all be used up. I was so proud of solving this, since I’m not really knowledgeable in memory issues or Android, so this came down to my experience in developing and problem solving.