What Is Onshape?
I was setting up to do an interview with John McEleney on Onshape, but I realized the conversation won’t mean much if we don’t know much about the software. So I need to cover some basic facts about Onshape first, before we continue talking about more esoteric details with John. Onshape has been around for a few years by now, but to be honest, I just haven’t paid much attention because I’ve been wrapped up in other things.
First, and this is more for my benefit than yours, it’s Onshape. Not OnShape or On Shape, On-Shape, ONSHAPE, or even One Shape. CAD companies and their capitalization/concatenation fetishes…. And yes, it’s full-on cloud CAD. Why am I of all people reporting on cloud CAD? First, I think there is some value in cloud CAD, even if it’s not for everyone. Second, there has been more development here than just cloud development.
The cloud CAD bit gets all the headlines, but you can decide for yourself if that is warranted later on. After taking a look at Onshape, I personally think the choices of what to develop and what not to develop have gone well past the simple cloud/local question. It is this list of other things that interests me most about Onshape for the purposes of this article in particular. In this article, I want to enumerate some important objective facts about Onshape (and this has all been checked by Mr. McEleney) to make sure we are basing opinions on real information, not on debatable statements or opinions or misconceptions or worse yet, lies.
Here are some aspects of Onshape that you will find familiar:
1) History-based – I was frankly hoping for something from Onshape that transcends history, but this is the route they went. History-based modeling has obviously worked for a lot of people for a long time, but the reasons for relying on it no longer exist, and I think we can do better. Onshape is making the most of this method, but to me personally, real progress in CAD would come in the form of something that steps beyond this aging paradigm.
2) Parasolid – Parasolid is powerful and popular. The Onshape team is familiar with it from SolidWorks days. What’s not to like here?
So, what is it that makes Onshape more than just SolidWorks reprogrammed for the cloud? When you look at the software, it does have that general appearance of looking like SolidWorks, or Solid Edge, or Creo, with the feature tree on the left, toolbars on the top, orientation tool in one corner. A lot of it looks familiar. But here is some stuff that isn’t so familiar:
1) Database
The data in Onshape is stored in a database, not in traditional discreet files. This has a lot of implications, such as infinite undo, sharable features, a new solution to the external reference problems in traditional CAD, searchability, automatically attached metadata, total traceability, no need for pdm system (which in itself has a whole list of benefits), google docs sort of sharing, simultaneous file access, go back to any point in time on the design, there is no need to save – everything is a transaction. You can be designing on your laptop, shut the screen and login from some other device (no need to install software) and you are exactly where you were prior to shutting the screen. If the software crashes, there is no loss of data. It also means, for better or worse, you don’t share, transmit, or store data in the same way. For example, you can’t take native data out of the system, but on the other hand, there is no need to, because Onshape only exists on the Amazon AWS cloud servers.
2) Cloud
Yeah, the software runs on cloud servers, and the data is stored in a database on cloud servers. Without pounding on the disadvantages of cloud (we’ve done that before, likely might do it again in the future), there are some advantages of being in the cloud, if you believe what the cloud proponents say. Centralizing the executables gives you certain efficiencies. First, only the administrator of the entire system has to do the upgrades when they come out every 3-4 weeks. That’s big. So you’re always using the latest stuff. No more downloading and testing, scripted installs, blah blah blah. You don’t have to have dedicated hardware (aside from a GPU in your device), so if you have a connection, you can CAD. This means distributed design teams, contractors with weird hours, and customers. The cloud also gives Google Docs type sharing. Just flip the switch for sharing. Subscription – as long as you keep paying, you still have access to your data. Usually this means smaller up-front costs than perpetual licenses, but you’re going to have to discover that for yourself, I’m not here to do a cost analysis this time. It looks like they have some partners set up for rendering, flow analysis, and CNC, but this would be another very important area where the whole cloud scheme could potentially hit a roadblock. Again, I’m not checking into this aspect at this time. Later we will have to ask questions such as what happens to your data when you stop paying? What happens if Onshape develops a new kernel? What happens if Onshape goes out of business? These are all valid possibilities that you should have answers to before committing the future of your company to this manner of storing your data.
3) Feature Script
This is a very cool programming language that allows Onshape users to create their own custom features. It treats the feature tree as a script, and as you remember, the feature tree is already stored in a database, so you wind up with scripts stored in the database. It essentially embraces the often-used criticism of history-based modeling that building a history-based model is more like writing a program than doing design or engineering. For example, if you want an asymmetrical fillet, you can copy the Fillet feature code, and change a few things to make a fillet that is twice as wide on one side as the other. Yes, you have to have some sort of programming skill to take advantage of this, but once its made, you can use it internally or share it with other users on the Onshape community. This is similar in some ways to a combination of libraries and macros, but feels more integrated.
If you’re looking for detailed functionality on a specific feature, you’re probably going to need to get a demo or a trial license to answer that type of question. For now, I’m just looking at this as generally as I can. You can get the full schpiel at Onshape.com. My next blog on Onshape will be the interview with Mr. McEleney where he will address some of the specific issues I’ve raised about cloud CAD in a previous blog post.
Uh, I’ve already paid off my student loans, now I’m paying yours. You can do your own homework. 8:)
When Cloud Software goes out of business this is what happens
http://home.lagoa.com/2017/11/time-to-say-goodbye-to-lagoa/
Below snippet from the above link.
Next steps for a successful transition:
As of Dec 22nd 2017, the rendering functionality will be turned off. Take the time between now and then to finish up your projects.
As of March 2nd 2018, the site will be shut down and all stored data will be deleted. Prior to that date you can download any uploaded zip files or rendered work via your project page.
Hey Matt,
Thanks for the write up. Might I humbly suggest there is a fundamental advantage that feels missing from the review. It comes up at the end of the write up. You describe a process where users can go get a demo and or request a trial in order to see what Onshape can do.
When you say that, what feels missing is the point that anybody can just start using the software. They can do so at anytime, on just about any hardware, from just about any location. No downloads, no licenses, no prerequisites. While of course you can request a trial for or Pro license. You don’t need it. Just login and start using Onshape. If you did not create an account yet. We ask a few basic questions. We do thisone time and whala you are good to go.
Don’t get me wrong, I would have said the same thing when I worked for SolidWorks. Hell I was working on the “cloud” products internally at DS. SWMC, Xdesign or whatever they calling it these days. Lets just say those project reminds me now of Pro/JR… when PTC was trying to port their UNIX software to run on Windows.
My first day using Onshape, I simply opened the box of a new laptop. Booted it up. Logged in and started using Onshape immediately. I also went to several other legacy systems that day, picking up exactly where I left off… Used it all day. Never even worried about saving crashes etc…
Had I been using SolidWorks. or just about any other Software in MCAD….. it would have taken work. and planning. and I would have had files to deal with and licences etc…. and I would have spent a lot of wasted time and effort….
This may or may not seem like a big deal. But It was an ah ha moment for me. Today when I use a software that is downloaded and or installed it feels like taking a step backwards. It’s the same way felt when WIndows software started replacing MS DOS and Unix.
Consider the entire ecosystem of Integrated Cloud Apps. The Onshape App Store offers instant access to MCAD, Stress, CAM, Rendering, ECAD, etc… Multiple choices, each just a click away. No files, no installs… Just like Onshape, Integrated Cloud Apps follow the same accessibility. And as an extra bonus they don’t require you do have super CPUs, and rendering GPUs…. My local CPU remains relatively untaxed even with analysis and rendering. I can render, run analysis and model all at the same time. On a low end machine if I want. You cannot do this when it’s all being done locally.
LIke I said, this may not seem like a big deal. All I know as a long time veteran of using many CAD systems. This is one of the things that still surprises me today in a good way.
Freedom…..
Joe
John already mentiobed GIT but I’ll say something about it. You ought to listen to Linus Torvalds talk about git. If you can get your head around git then Onshape solves another problem that many companies have and don’t realize.
When I was managing Solidworks at a company ages ago one of the biggest problems was getting people to follow best practices and build models that work the way intended. 3D modeling, especially parameteic modeling has a lot in common with programming. Maybe that’s because graphical communication went from the realm of people who design pencils to people who design programs. Every programmer has there own style and so does every modeler. And every program can have bugs, bad approachs and other problems. Parametric models also can have modeling bugs in addition to incorrect geometry. git helped get around that in the programming world, but you’ll have to let Linus explain how Onshape get’s around that in the CAD world.
Torvalds on git:
https://youtu.be/4XpnKHJAok8
Good question, Scott!
The answer is Onshape is both history based and time based. Let me explain.
Onshape is history based in the sense that parts in Onshape have a parametric history of features that create the geometry – like SolidWorks, Creo Parametric, or Inventor.
Onshape is also uniquely time-based (or transaction-based in database lingo) in the sense that every transaction that contributes to your CAD data is sequentially remembered forever. This is true whether you edit is to parts, assemblies, drawings, or properties. You never lose time or data due to crashes like you do in other systems. (And in fact, Onshape crashes much less than traditional installed file based CAD systems due to its cloud architecture, but that is another subject).
It is this transaction level intelligence that lets multiple users work on the same data at the same time without messing each other up – like in Google Docs – and unlike every other CAD system out there – where having to send files around effectively means only one person can work on them at a time.
Also, as you correctly note, Onshape also has built in branching and merging on top of this transactional data (like Git), so users can work what-if scenarios without impacting one and other in parallel and compare the differences (like software merge tools), and even merge them back. Onshape’s transaction system even works seamlessly across multiple interrelated Onshape documents – you can always get back to any prior state of any document and the appropriate state of all documents it referenced.
Just to come back to parametric history for a moment, while it is easy to learn how to model in Onshape if you are a SolidWorks, Creo, Inventor, or Solid Edge user, there are also things about parametric modeling in Onshape that are very unique.
First, Part Modeling is Onshape is inherently multi-part – one parametric history can drive the definition of multiple parts that can then be used independently and repeatedly in assemblies. This may sound like a simple idea, but it is tremendously powerful and it is fundamental to Onshape, and those traditional CAD systems don’t support it. Onshape extends the power of parametric modeling to top down.
Second, as Matt mentioned, Onshape parametric modeling is fundamentally different in that it is based on a powerful, open programming language called FeatureScript. The language itself is published, and the code for all built-in Onshape features is published, and any Onshape user can create and share (or not share) customized features. While most users will never program their own features, they can take advantage of custom features others create and share. This level of openness and deep customization has never existed in the parametric modeling world before.
Third, Onshape does have powerful “direct modeling” features that allow Onshape users to take in models produced in other systems and modify them effectively. These are “remembered” in the parametric history like any other modeling feature. There are intense arguments inside the CAD community about history-based vs. non history-based modeling. Without getting into these debates , these features are used heavily and allow the many 000’s of commercial Onshape users to modify imported data edit to get their jobs done.
Have you done the interview yet and are waiting to post it? If not, or even if you have and you have time to go back and ask John a follow-up question, consider this.
Onshape is not history-based, it is time-based. See if John agrees with the differentiation. While the feature tree may look like the usual recipe of history-based CAD, the commands stored to create the geometry are much more discrete than that, which allows for some pretty cool ways to develop versions, revisions, ideas, branches, merges, rollbacks, and more. Or I could be completely off, and if so, ignore this comment.
Good question. Maybe John will respond here on the blog comments.