If you’re reading this, you probably already know a lot about what Onshape does. But it may not be so obvious how it does it. A complete answer would be complicated! But this short, simple overview might help you get a feeling for how we can do what we do – and how modern CAD is totally different from its file-based predecessors.

What Onshape Isn’t

Let’s first look at what Onshape doesn’t do. It would certainly be possible to run a traditional desktop CAD system, or something very similar to it, on a server in the cloud, forwarding user input to the server, and “screen-scraping” to send graphics to the client. That could work. But the result would just be an old CAD system, except slower.

So that’s not what we did. We wrote Onshape in a different way from the ground up, to provide capabilities not possible in traditional CAD systems, to take real advantage of the cloud, and to use both server and client machines to their fullest capabilities.

What Onshape Is

A traditional file-based CAD system is a monolithic application, running on one machine, simultaneously limited by its capabilities and by not taking full advantage of them. Onshape, on the other hand, is like any other large-scale modern cloud application – a collection of servers and services. They can run on machines optimized for their purposes; and the number of instances can be optimized so that they are always busy, but not overloaded, to make efficient use of resources.

Some servers that handle things (such as user authentication and authorization, and finding and listing documents) process lots of requests, but do not do much “real work” themselves. They forward complex requests to other servers. Others know what is “inside” a document, and keep modeling sessions in memory, resulting in long-lasting sessions for modeling with documents.

Others, the admittedly unimaginatively named “geometry servers,” do all the math – these are optimized for computation power. These servers are the ones that reconstruct geometry from feature lists and FeatureScript, solve for instance positions in assemblies, and compute graphical tessellations. They make use of the venerable geometric modeling kernel Parasolid and constraint solver D-Cubed – both well-tested by many years of use in many CAD systems – which we license from Siemens PLM.

Clients and Graphics

Our clients, both browser javascript clients and mobile applications, are not particularly thin, but nor are they complete CAD systems in themselves. They communicate with the servers using both ordinary HTTPS/ReST calls and websocket connections, using our own wire protocol.

The client doesn’t receive pre-rendered images (as in the screen-scraping scenario), nor does it receive whole CAD models with precise geometry. Rather, its graphics are all in the form of triangles, rendered with WebGL (in browsers) or OpenGL (for mobile apps). Rather than using one of the third-party scenegraph libraries, we use our own custom renderers, with our own custom capabilities, and with the speed we need to display large models.

You’re Always Up To Date

Upgrading to a new version of a file-based CAD system is a perennial problem: All the users must install a complex new piece of software, with no guarantee that old parts will continue to work (indeed, you can usually be sure that something will break). With Onshape, there is no such thing as a user update. We release new software all the time, and you may not even notice, other than that new features are appearing.

There’s nothing new to install (unless you’re using our mobile apps, which you update just like any mobile app) because there was nothing to install in the first place. And the fact that all of our users’ data is stored on our servers means that we can check a vast range of documents for bugs in advance (without ever looking at them ourselves!), rather than letting you find them after it’s too late.

Data and Data Management

Just as we could have written a traditional file-based CAD system and run it in the cloud, we could have modeled our data management on traditional desktop systems as well, reading and writing files just as a desktop system does. In some ways this alone would be an improvement over old desktop systems — living in the cloud, those files would be available anywhere, not just on one machine on one desk. But it would certainly not take full advantage of the cloud and of the power of modern technologies.

Onshape stores its data not in files on a disk or in a PDM system vault, but in a database. And it doesn’t need to read and write all the data in a document every time it is opened or saved – we have no explicit “save” action at all. Instead, every change is recorded as an increment. As users work, we always write everything they do as they do it, recording only changes, not whole files. We don’t erase or overwrite old data, just add new data. Besides ensuring that you don’t ever lose work when you have a power failure, this is the basis of our unique data management capabilities. We have the basics of PDM built in to our most fundamental data format – every change is recorded, and can be recovered easily. “Saving” versions is trivial: We just add a tag at the appropriate point in history.

And there’s more: The increments we store make sense applied to any state of a document. This is what allows our seamless collaboration, and what enables us to merge sets of changes. Onshape just applies one after another. The result may not be exactly the part you want – two users can always make inconsistent changes – but it will always make sense. There is no need to check files out of a vault and lock them (although you can always restrict write access if you want to), because unlike any other CAD system, Onshape can reconcile multiple users’ work.

What Do You Want to Know About Onshape?

From time to time, key players from Onshape’s R&D, product development and UX teams share their insights in “Under The Hood” blog posts, explaining some of the more technical aspects of how Onshape works. Ilya Baran, Director of FeatureScript, has tackled why collaborative editing happens so smoothly. Principal Software Engineer Elif Tosun, leader of our Part Modeling team, covered why Onshape users don’t experience CAD crashes. And Ravi Reddy, our Director of R&D who leads the Mobile and Enterprise development teams, recently explained how Onshape’s iOS and Android mobile apps were built from scratch.

Of course, there’s a lot more to discuss. Are you curious about our thought process behind any specific aspect of Onshape? Please share your questions below or post them in the Onshape Forums.