Geotechnical Data Viewer

Would it be possible to take the output of every major mine design package and combine it with arbitrary geotechnical data? That was NIOSH's question. It opened a multi-phase research plan, and phase one was only supposed to establish whether the thing could be done. They were expecting a report. They got their answer as an app.

Ground failures in mining can cause serious injuries, economic losses, and in the worst case loss of life. Mines monitor the ground more intensively every year, but the readings pile up in spreadsheets and databases while the mine itself lives in a 3D design package, and every package on the market speaks its own proprietary format. The data describing the ground and the model of the workings around it couldn't be looked at in the same place.

Everyone expected the formats to be the project: Vulcan, Surpac, MineSight, Deswik, MicroMine, DataMine, each speaking its own notoriously closed file formats, each presumably needing its own reverse-engineered importer. I had a better idea. I came at it as an interface problem: not "what's inside each format?" but "what can each package export, and what can rendering software ingest?" Find where those two lists touch and there's nothing to crack. Building the export list myself would have meant licenses to a stack of expensive proprietary packages; what I do have is a network. Friends at mining companies walked me through formats that are genuinely hard to get information on, and the newer, better-documented operators filled in the rest. The lists touched. DXF, the mid-90s AutoCAD interchange format, is a lingua franca practically every mining package still exports. And assimp, the Open Asset Importer, is an open-source C++ library that reads an absurd number of 3D formats, DXF among them, and writes them too. That closes the loop: anything a mining package can save, assimp can read, natively or by way of DXF, and assimp can write it back out in whatever a renderer wants. A universal interface. We needed about a dozen formats; assimp covered those, plus a few hundred we didn't need.

That was the formal end of the planned work, with a good chunk of the budget still standing. And honestly, the answer made me a little uneasy: it looked almost too simple, and simple can read as underdelivering. The surest way to show it really was this straightforward was to build the workflow and let them watch it run. So I reached out to NIOSH and asked: would you like to see a prototype of what you can do with this? They would.

That turned the question into which tools. The bridge had left the rendering side wide open: with clean glTF coming out of assimp, virtually any 3D engine could take it from there, so the choice came down to what NIOSH could actually use. The obvious candidates, Unity and Unreal, came to mind first, but neither felt right: 900- and 1,200-pound gorillas for what is, at heart, a data viewer. But I'd spent a lot of time around the modern web, and I knew WebGL had been coming on hard. A little research turned up BabylonJS: a capable, permissively licensed engine that looked like an excellent fit, with room to grow into a hosted web app or even a mobile port down the road. For distribution, the easiest path was to wrap it all as an Electron app: self-contained, easy to install, something NIOSH or their industry partners could run without new funding to host and maintain anything. I tried a few different setups with Babylon and landed on extending their open viewer code, which got me a bunch of great features without hand-rolling them myself. From there I built it out to load converted mine workings next to CSVs of geotechnical readings.

The genuinely new ground, for me, was native code. I hadn't compiled anything since Java, and getting assimp into the app raised a question I'd never had to answer: how do I call a C++ binary from JavaScript? The answer I landed on: compile assimp myself, ship the executable inside the app, and call it as a child process to convert whatever a researcher dropped in to glTF. Converting a mine model became: open the app, pick a file, click convert. No command line anywhere.

That gave me a functional, frankly beautiful viewer that could pull in any mine's workings, with the geotechnical points stubbed in by a script I'd written. The stub was the part that left something to be desired. A researcher should be able to upload any arbitrary set of points, tell the app which columns are X, Y, and Z, reorient the points if they arrive in a different coordinate space, and bring along whatever data rides with each point, like the magnitude of a reading, then pick any of it and see it. So I built a CSV importer into the app and let any column be mapped to a color gradient, rendering the readings alongside the workings as a sort of three-dimensional heat map.

This worked great, with one problem. Mine workings are big, complicated, three-dimensional structures, and the readings sit all around them: buried inside a working, or hanging on the far side where you can't see them at all. It was genuinely hard to tell where a point sat in relation to the rock. My answer was transparency, and workings this complex are exactly the kind of model that usually makes transparent rendering fall over. This was where building into the off-the-shelf Babylon viewer turned out to be magical: it exposed every rendering parameter to test and tweak, and with some clever tuning I landed on a configuration that gave me the most satisfying semi-transparent rendering I've seen to this day. For the nerds, the recipe came down to partial alpha on the working materials with back-face culling turned off and the back faces given their own color, so the far side of a working stayed drawn and legible instead of vanishing. The workings turned to glass, every data point hanging exactly where it sat in the rock. I wrote the exact settings into the report.

Fitting, because the app wasn't really the deliverable either. The literal ask was step one of proving something bigger: that an expert could look at geotechnical data and see what it means, what to tell the frontline, what to do about it. Data you act on before something happens, instead of examine after. Phase one was supposed to say whether that future was possible. Instead, NIOSH finished it flying through a mine with the ground data lit up around them.