Heavy Equipment Training Simulation
Globalsim is a heavy equipment simulation company, focusing mainly on some of the largest cranes in the world used at ports for moving very heavy loads. This means that the simulation software critically needs to be accurate, data heavy, and accurate.
Render pipeline
I I was the only dev on the team that understood the complexity and details in what it took to move to a new render pipeline. We were stuck very firmly in the old built in render pipeline but I know we needed to move into more detailed, accurate, and performant systems. I pushed for us to move into HDRP and so we did. I worked close with out art director and changed every single visual the sim had.
I worked on:
All new custom shaders for our use cases
Completely new and custom weather system built in house
All new water for dynamically updated ships based on their size, weight, and weather conditions like wind and sea state.
Particle effects that are fully GPU based with VFX graph that do collision detection with the cameras depth buffer that all interact with the custom weather system
All new volumetric sky system with dynamic and live updatable clouds, sun, moon, fog, lightning, etc.
A light cache system for performance updates on hundreds of live lights all casting shadows at runtime in a fully dynamic scene
Custom render pass full screen shaders for doing things like outlines of meshes for training tools
And so many more things I’m sure I forget. All of the pictures are using all of the custom systems I built, this project was almost completely built by me. I did have some help with our non technical art director for what he wanted the end result to look like. This simulation software after these updates is pretty well known to be the best looking sim system in this space right now.
Lights, camera, weather
A short little video made mid development cycle showing things working in real time changing the weather, lighting, volumetric fog, etc.
VR
When I first started at the company they were very locked into the Unity SteamVR system with leap motion hand tracking. But at that time the quest 2 was out and quest 3 just around the corner, they had some people using quests but still passed everything over to steamVR so things like hand tracking just didn’t work.
I updated everything to work with the OpenXR standards and now any OpenXR runtime can run the software in a native state without multiple translation layers. This also means you can have hand tracking with any headset that supports it. We now have clients running Meta, SteamVR, Varjo, Windows MR, and Pico headsets all natively with few issues. This included support for Varjo tracking markers, SteamVR vive trackers, hand tracking on all that support it, pass thought visuals on all that support it and so much more.
Beta installers
Our customer support team was having issues keeping up with testing and installs on systems, so I had the idea of making beta installers. They install to a custom location without touching the production builds but allow the customer support team to install a bet version of the software for a customer and have them validate and test anything to make sure it all works to their liking before we upgrade the beta to the production version. This update also added a version to the exe file that is shown in the simulator with it’s bata state and custom install build definition. That way any issues reported or crashes that happen the version is auto added to the bug ticket.
Controller firmware
We used to have belly box controllers that run with BLE modules on an arduino mega, and “Premium joysticks” that were running Arduino nanos. both of these had custom firmware, but the belly boxes used BLE modules and connected using serial over bluetooth, this made the battery life about an hour of running, and the serial over USB that the nanos used caused compatibility issues with windows 11 drivers.
I helped design new custom circuit boards for each of these use cases, and make new custom firmware that is uniform between all devices that communicates over the HID standards, this means it had compatibility with every system, and the battery life with the same battery on the belly boxes is around 18 hours now. The BLE systems are using an ESP32-S2 and the USB connected devices can either use an ESP32-S2 or RP2040 chips on our custom boards. This change upped compatibility, lowered cost of development, lowered cost of hardware, faster installs, battery battery life, and easier and more reliable use for users.
Dev tools
I built a lot of dev tools, the image here shows an example of a tool I made that when a build has some kind of crash the system will auto report a bug into the project that build was made for. It includes a full system report with the issue. This format is also used for an in simulator bug reporter that includes auto tagging, screen shot from your view in the system etc.
This bug reporter gives us a lot more benefit than just what happened with a log. I also built a tool for unity that you can copy paste a link to the bug and unity will then go download all of the bug information, more it to in progress, and then start the editor into the same exact state that the bug was reported in, this helps prevent back and forth asking for more info on the bug, can’t reproduce issues, etc. For me alone this group of tools instantly made it so I could close around 5x as many issues in the same amount of time.