8 min read
Geometry Coding in the Time of Robots

During my PhD, I wrote a vector math and geometry library, libgeometry. When I joined Autodesk, I and a few others developed libgeometry into a much more comprehensive math and geometry library. The I left, and wrote another math and geometry library, geometry3Sharp. Then I joined Epic Games, ported geometry3Sharp to C++, and I and a few others developed it into a much more comprehensive math and geometry library.

Two of these libraries are open-source. If geometry3Sharp has what you need, and you are using C#, you don’t need to build it yourself. But the “good” ones are owned by companies (Autodesk and Epic). Epic’s model allows the library code to be available, although the license terms mean you can only use it with Unreal Engine. Autodesk’s version is completely secret. “IP”, they call it.

An enormous number of Corporations also each have their own version of these libraries. Each has substantial overlap - code for vectors and matrices, curves and surfaces, solvers and optimizers. If you work in this space, you could have a pretty solid career just going from one company to the next, implementing the same geometry data structures and algorithms in different codebases.

None of these libraries are the core business of the companies that own them. They are never the product. They don’t generate revenue. If anything, these libraries are liabilities. You would not believe how often I can look at a high-level tool in a 3D app and see the issues in the underlying geometry implementation. Issues that I’ve coded myself, and then later learned how to fix.

However the rules of large corporations are such that these libraries must be considered “Intellectual Property”, and protected. Despite everyone having basically the same code and data structures, mainly standard textbook implementations, often not having changed substantially in decades. Somehow this is considered so valuable it must be kept locked down.

When you think about it, the waste of human time and effort in just this tiny corner of software development is staggering. Generally you have to be a pretty good coder to work on a geometry library. You need substantial background in mathematics, data structures, performance optimization, testing and debugging, and so on. Someone who can do this could do a lot of other things. But so many of us have spent so much time writing the same code, each in our little silo.

What about Open Source? A solution to nearly any geometry problem is out there somewhere as Open Source. But Open Source is a land of Chaos. So we have hundreds of incompatible libraries, singe-file headers, demos, unmaintained “sample code”, broken source dumps, and so on. In every possible programming language. Again, the vast expenditure of human time and effort, to build the same thing over and over. The mind boggles.

And frankly, it’s been getting worse over time. Each new code language spawns new versions of completely standard geometry libraries (as well as physics simulators, file parsers, game engines, …). Finite human effort is continually being fragmented into an increasing number of language and platform silos. If it could be measured, I think we would see that nearly all the action in geometry libraries is re-implementation. The Robots found me 12 different Rust crates for LAPACK.

Of course doing the same thing over and over, in one place and then the next, has been how humanity has always worked. We can’t all share the same house. But this is software. There’s no reason to do the same thing over and over. Despite being trivially shareable, we have treated software like a physical asset because of the time investment taken to create it. Despite being infinitely malleable, we have started from scratch innumerable times because of the time-cost of…malle-ation (?). Making changes is hard and not-fun, so build your own!

It’s like if every company said “we need to invent our own proprietary type of electrical wiring” and every open-source coder said “I just wanted pipes that were slightly smaller so I designed a new plumbing system from scratch”. That would be insane. But that’s exactly what we do in software.

Enter The Robots

Over the past year, Magic Coding Robots have evolved to the point where they can take in this sum of human labor - all (public) geometry libraries coded by humans - and synthesize a new one tailored for your exact purpose. It still can be a bit rough, but there is no reason to believe that these Robots will not eventually be able to write you “the best” geometry code for your problem, on command.

Consider the implications. All that top-secret proprietary geometry code? Clearly it has no value, if a Robot can produce something comparable-or-better for a few dollars. The bottom has fallen out from under any argument that “utility” code like a geometry library is Intellectual Property that must be Protected. The only remaining utility for a proprietary geometry library is to open-source it so that the Robots can consume it and be able to do a better job of generating the application-level code that calls it (where there is still some value, for now).

And the open-source libraries? Well, to be blunt - they are fodder. Grist for the mill. As an open-source developer, this is not the happiest thought. It’s a new reality we have to adapt to, and adaptation is painful. But it’s not going away. If you write an open library, the main consumer of your code will be the Robots. What comes out of the other end probably won’t be “yours” anymore. And even if your library is used directly, it’s probably going to be a Robot using it.

I was depressed about this for a while. Like, what’s the point now, if it’s just for Robots?

But what was ever the point? Were you making your Rust geometry processing library for the fame and fortune? I hope not!! At some level, every Open Source developer has to recognize that the collective project is to advance humanity, and by donating time via code, you are making a tiny contribution.

It took me a while to come around, but now I think it’s actually very freeing. I have always had a lot of ideas about how to improve geometry3Sharp, my C# geometry library. But (a) I didn’t really have time for large-scale work and (b) the changes often would break things. Breaking user code has always been a hard decision because it creates downstream work for users. My “improvements” are spending their time.

But the Magic Coding Robot doesn’t care about time. It has all the time in the world. It can grind through my codebase-wide refactors. I won’t miss how my eyes would start to twitch and go blurry after a few hours of copy-and-paste refactoring. And it can help turn my new ideas for this library into actual working code. Sometimes I will have to step in. It’s not going to be able to read my mind, and I can only type so many instructions. But big changes are way, way more plausible now.

The Magic Coding Robot also doesn’t care about breaking changes. It can upgrade to the new API, no sweat. It can ingest the new, better code, and now everyone on the planet has access to it. In any language (code and human). Isn’t this what we were trying to achieve with Open Source the entire time? To make things better for our fellow programmers? Or were we really just in it for the Attribution?

So I’ve changed my mind about the Coding Robots. It’s certainly not all good - I don’t know how the kids are going to really, truly understand Splines or Meshes without writing the code. But on the flip-side, they aren’t going to be boxed-in by how quickly they can type, or their proficiency with CMake. Their capacity to turn an idea into a working app or tool is going to be 100x what mine was.

I will really miss sitting down with a cup of coffee on a quiet Sunday morning and adding something new to one of my geometry libraries. Sketching out the design, the Zen-like flow state of cranking out the initial implementation, and then the battle of testing and debugging, until that Eureka moment in the fading afternoon light when I get that first working result. It’s been one of my favourite things to do.

But maybe it wasn’t the best use of my time. Maybe I should have been building up, not out.