We've been back online for a while now, and honestly- it's been a great couple of months. Getting back to work on Unlimited Detail and re-engaging with our customers has reminded me exactly why we built this in the first place. The problems we set out to solve haven't gone away. If anything, the timing for what we're building couldn't be better.
When our client-side CPU renderer for massive point cloud data was built, the pitch was straightforward- stop depending on expensive hardware and centralised systems just to view your survey data. Access terabytes of point clouds from commodity storage - a local drive, a network share, or blob storage without breaking the bank.
That was a compelling argument a few years ago. Today it's an urgent one.
GPU prices haven't come down. Cloud compute costs continue to climb. The economics of rendering dense, high-fidelity point cloud data the "conventional" way are getting harder to justify, especially as survey data is getting cheaper and is significantly higher resolution. More data, better data, and more of it landing in pipelines that weren't built to handle it efficiently.
That's the gap we sit in, and it's widening in our favor.
Our two off the shelf products are in a good place right now.
udSDK gives developers and teams the ability to embed massive point cloud handling directly into their own applications and workflows, without having to reinvent the wheel on the rendering and data access side. If you're building something that needs to work with large-scale spatial data, it's designed to drop into your stack cleanly.
udStream fills a different but complementary role - it's where we focus on quality assurance, monitoring, planning and overview workflows for digital twins. If you need to validate, inspect, or get a fast read on your captured data collaboratively, that's what it's built for.
My core focus across both is straightforward: make massive digital survey actually manageable. They're still genuinely hard to work with at scale - whether the challenge is density, geographic extent, or the combination of both. We have real solutions for this, running on hardware you already own.
"Meeting customers where they are" is something I mean quite literally. Our products run on Windows, macOS, Linux, and in the browser - so whatever your team's environment looks like, you're not being asked to change it. And on the data side, you put your data where it makes sense for you: local storage, a network drive, WAN, a secure private cloud, a public cloud, or some combination of all of the above within a single scene. That last part matters more than people might expect - in practice, a lot of teams have data spread across more than one location, and we don't force you to consolidate it just to get things working. More importantly, your team can collaborate across that entire mix: different people, on different platforms, pulling from different storage locations, all working within the same scene.
Beyond platform and storage, one thing I care a lot about is turnaround time. When a customer has a problem or a workflow gap, we want to close it fast, not queue it up for a roadmap review six months out.
A good example from recently: we had a request to support XREF for projects. The goal was simple, customers should only need to create their datasets once and then embed them in larger master projects rather than duplicating work. We turned that around within three days and shipped a public release. That kind of maintainability improvement has real downstream impact on how teams manage and scale their project libraries.
This is the pace we want to operate at. Close to customers, responsive to what they actually need, and shipping.
The udSDK trial program is now open, and we're actively onboarding new customers. If you're working with large point cloud datasets in your current applications, or if you're trying to build something that needs to handle that scale without a GPU-heavy infrastructure bill - I'd genuinely like to talk.
The opportunity here is real. Survey capture is getting cheaper. Data volumes are going up. The expectation from end users (engineers, inspectors, project managers) is that they can access and work with that data without waiting for a specialized machine or a cloud rendering job to finish. We can help you meet that expectation on the hardware your team already has.
If that sounds relevant to what you're building, reach out and let's get you into the trial.
The GPU Was Never the Right Tool for Point Clouds. The Shortage Just Made It Obvious.
Your GPU queue is 26 weeks. Memory prices are up 90%. NVIDIA shelved its professional line through 2028. That is not a shortage. That is a permanent reallocation. The architecture was already failing you before it happened.
Why the Geospatial Industry Keeps Paying Twice for the Same Data
Six-figure LiDAR surveys get delivered, filed, and forgotten. The industry treats spatial data as a project deliverable instead of an enterprise asset, and pays the cost every quarter the data sits unused.