Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
A Discussion About OnShape As a Tool For Makers, Artists and Educators
neobobkrause
Member Posts: 105 EDU
OnShape has been generating a fair amount of buzz lately, though the word I’ve been hearing is simply that it exists. So in order to learn more about it I recently spent a week working with OnShape to perform a detailed assessment for myself.
Though I really wanted OnShape to meet my needs, instead I found the tool to be quirky, slow to the point of unusable, lacking a number of minimally basic features, and presenting a very dated UX (User Experience) inherited from antiquity (i.e. Autocad and Solidworks).
Let me fill in some rather techie details about my evaluation on which the above conclusions are derived.
• I've experienced the OnShape team to be helpful, knowledgable and friendly.
• Taken together, the help system, the video tutorials, the community forums and the support staff are all fantastic.
• I liked the versioning features of the app. I found them to be well-thought out, easy to use, and complete enough to address all my requirements.
• Though I didn’t use the collaboration features during my evaluation, I did read through the documentation to the point that I was left with the impression that they were, again, well-thought out, easy to use, and complete.
• Flatly: OnShape is using the wrong geometry kernel to address the current and long-term needs to makers, artists, educators and even the mechanical engineers that are the products primary target. Those who know a bit about CAD may scoff at this statement. It’s based on the fact that OnShape’s geometry engine won’t allow it to easily accept and manipulate scanned volumes, imported meshes (like STL and OBJ files), nor scale to meet the real-world requirements of users today, and certainly not those that are coming. OnShape was founded by the same team that founded Solidworks, a well-respected commercial engineering 3D solid modeling tool. I believe that the choice of a BREP graphics engine will ultimately relegate the app to forever remain a niche product — even if the niche is large enough to survive. All I’m saying that their product didn’t meet my requirements as an educator, maker and artist.
• OnShape is billed as a professional grade mechanical engineer tool. Yet it couldn’t handle the same real-world design that I’d brought over from Tinkercad -- a tool seemingly designed for kids.
• Simply moving the mouse across a OnShape Part Studio canvas with only a few objects in place causes the mouse to jump around to the point that even the simplest UX tasks like changing focus in a textedit box of a dialog box becomes almost impossible. I believe this is due to background javascript code running whenever the mouse happens to fly over an object. These background processes seem to be causing the app to temporarily stop tracking mouse movements.
• The UX calls upon users to interact far too often with dialog boxes rather than direct manipulation controls.
• Though parametric capabilities have recently been added to OnShape -- the feature I was most interested in exploring in OnShape -- I experienced the UX for these capabilities to be quirky and rudimentary.
• The system appears to not include basic data management of parametric values beyond individual single-value variables. Support for multi-value variables is missing, as is the ability to import data values, create spreadsheet-like data libraries, or the ability to create data value reference lookups.
• The system lacks refactoring support to address even basic use cases — such as renaming a variable.
• Requiring that all 3D solids and surfaces be derived from 2D sketches, while still common in many traditional MCAD systems that evolved from 2D ancestors, creates a huge drag on user productivity and results in a level of complexity that would likely limit OnShape's use to high school and college level engineer students. That a “new” “out of the box” application like OnShape would bring that UX forward is a significant statement about the mindset of the founders. I get the thinking that resulted in that UX being chosen given all the other, lower-level decisions that have been made. But it results in a massive loss of productivity.
• I found system availability of the application to be flawless during my week of use. Yet during my evaluation a number of real-world boolean operations (sort of like a Tinkercad group operation) ate up so many CPU cycles on the server that the graphics engine eventually gave up without notice after I’d wasted 15 minutes waiting for the operation to complete. I fear that OnShape will ultimately face many of the same challenges that other calorie-rich, latency-intolerant applications have struggled to overcome. I would love to see whether the OnShape team is able to create a service that keeps their users productive under heavy user loads.
• The current system lacks a grouping feature. The union boolean doesn’t support unification of spatially disjoint part bodies.
I would really appreciate a response from OnShape architects to the points I’ve raised above.
- Bob
Comments
I am a maker and don't find the traditional sketch based modeling a serious problem (yes, there are many, many features that everyone wants) but the fact that I have to start with a sketch is less of a limitation (it does encourage rational geometry, as opposed to badly used CAD packages that work more like 3D animation/modeling packages, that people can create totally irrational 3D objects that when fed into a CNC of some type (mill, printers, etc) do not produce valid output.
Totally agree on the variables part (and there should be variables independent of the feature list - variables outside of time)
In my experience trying to do the kind of precise dimensioning that OnShape focuses on is not great with polygons. In other words I think expecting OnShape to handle direct editing of meshes (as it does with other imported file formats, which is amazing) is more or less the wrong tool for the job. Direct mesh editing would call for something like Blender, IMO. What I would like to see in this area is the ability to bring in meshes or point clouds visually to use as a base for sketches, similar to what is possible with images.
On a slight tangent, going from scanned data/photogrammetry into a 3d-printed object is a very commonly desired function among makers I work with. The layman's expectation is to scan an object and print a "copy," but in my experience so far any scan isn't going to be nearly precise enough for any part more complex than a doorknob. Possibly more expensive laser scanners could do better but for the non-professional it's usually easier to take measurements and rebuild from scratch, which I find OnShape to be great at. What the industry standard process is for this kind of project would be an interesting benchmark for OnShape capabilities.
The comparison with Tinkercad is interesting, as that was what I primarily worked in prior to OnShape for 3D maker projects. It's telling that I rarely if ever use Tinkercad anymore, mainly because I find making precise or complex parts in that environment a bit of nightmare. For instance I designed a gear train in Tinkercad which took probably 20 hours, but more like 2 in OnShape. In contrast, for anything with complex boolean operations, especially of irregular or organic objects, Tinkercad is superior to anything I've seen.
I would love to see some of the improvements you mention to variables, but I certainly don't find the current implementation to be frustrating or rudimentary. Similarly, I've rarely seen any noticeable slowdown in OnShape. The only time I've seen it struggle is with very large linear patterns. I haven't tried anything with organic shapes but as mentioned I would probably use a mesh-sculpting software (eg Blender) for that kind of thing anyway. I also believe I read elsewhere on the forum that multi-value variables are possible, I'll have to check on that.
Some examples of your real-world projects that OnShape couldn't handle would be very useful to keep the discussion focused on what you're trying to do.
I'm hearing from engineers who say that OnShape's UX meets their needs and that its features are well matched with their requirements. That said, we're also hearing some engineers who say they would benefit from mesh support were it included. And we're hearing from those with their maker hats on saying how they (myself included) appreciate the rigor and preciseness that comes with designing in OnShape. OnShape is awesome in that regard.
I don't really expect to be able to sculpt a mythical 3D creature in OnShape. I'll use some other app to accomplish that. But I can imagine wanting to create the creature's skeletal structure in OnShape, which I then export to a sculpting app. But design is iterative by nature. I need to know that I can take my design back and forth between applications as necessary. And that's at the core of my concern about OnShape. The requirements for engineering design projects will increasingly include sampled data. Requirements will be much more complex. The capabilities of engineering tools like OnShape must be richer. They must be capable of handling larger datasets. -- Meaning more parts, more intersections, higher poly surfaces, more "flow" between tools.
It's this notion of "Flow" that is central in my mind as I look at OnShape. The file formats that it supports in both directions are mostly engineering focused. (See https://cad.onshape.com/help/Content/translation.htm) Surface meshes and volumetric solids aren't supported as full-featured native data types. But Flow is more than just support for a file format. It encompasses the notion of a natural and productive user experience at every touch point. That's what I'm not seeing. And that's why I'm going so far as to suggest that OnShape's BREP graphics kernel may have been a poor choice for addressing the requirements of today and tomorrow's engineers -- let along makers, artists and educators.
My two cents. I have more change in my pocket, but that's it for now.
- Bob
OS is listening to our feedback, that's what I like about OS, any improvement they make and everyone benefits. I can't say that about SW, they've gotten to big to listen anymore. OS has only been around for a little while give them some time and they'll get things squared away.
I've been in the parametric world for a long time and I believe these guys have built a refreshing interface to the alternatives.
When I start a 2D sketch, I put as much information into that first sketch as I can to include things like pockets, cutouts, mounting holes and bosses. This keeps my feature tree less crowded, and if I have to make changes it can be done by returning to that sketch instead of adding more features to the tree. Fusion 360 has this basic solids feature and I never use it. I can see how others might prefer to start their models this way (and maybe OnShape can include this as a feature), but I would never want the sketch derived modelling style to go away.
The question I have been returning to time and again while evaluating OnShape is whether the application's on-ramp can be widened to include a broader group of users -- those both young and old. There was a time when SolidWorks was the only viable solid modeling option. The set of choices today are expanding rapidly. Even Solidworks is releasing a dialed back version geared toward kids. How will OnShape respond to the evolving expectations of 3D modeling UX going forward?
- Bob
I'm trying to guard against falling into some old-fashioned fuddy-duddy curmudgeon reaction, but I'd really have to see an example of how dragging and dropping primitives is easier, faster and more powerful than sketch-based modeling for anything more complex than one of those simple shapes.
- Bob
Since we're speaking in the OnShape forum, I'll give a first approximation of what I think OnShape is still missing...
* More, much more, direct manipulation. I want to drag, scale and rotate selected objects across and around a user-placable workplane.
* Grouping support. I want both to preserve (nested) selections as groups, and perform booleans on the selection. Both types of groups MUST be un-groupable, though I appreciate the implementation and UX challenges of supporting un-group.
* Support for meshes as first-class, read-only objects. Something along the lines of what
philip_thomas has suggested: The ability to import real-world -scale meshes and point clouds, and to reference the vertices/points in order to create b-rep geometry.
* Much richer, direct and natural data management support. Adding single-value variables into the feature chain may be a simple way to initiate variable support, much richer support is needed. Necessary features may include multi-value variables, table / spreadsheet references, nested scoping rules, and a richer, more natural equation syntax that includes references to library functions.
* Object library support. I think that it's imperative that users and teams be able to create, publish, and evolve libraries of "template" objects, be they 2D sketches or 3D objects that can include scoped variable references and constraints. Perhaps template objects could be made accessible via object palettes from which users can chose to add to a design.
* A rethink of a feature list. It should be possible to express your design intent without needing to see or reference the feature list, if you choose. The feature list should include nested blocks of variables, sketches and 3D build-outs.
Again, my two cents.
- Bob
https://www.youtube.com/watch?v=LIk32bU82RA
Thanks for the link.
- Bob
@neobobkrause I totally agree on most of your points (and for most, nothing to do with teaching kids, that's just usability for all of us). I'm not trying for 4th graders (since my youngest is in HS), but I do cad work with HS kids at work and part-time teaching at my old HS, and they are pretty quick to pick up parametric CAD. In fact one huge advantage of sketch based cad, is they finally see a reason for having taken geometry!
And just like an arduino and your mac can both be programmed in C, the fact that the arduino can affect real-world things makes it infinitely more appealing, CAD has the same attribute in that your work turns into a real-world object via 3D printing or milling.
I agree you don't as quickly get working, but on the other hand tinkercad has a very small number of primitives. To get basic things made you can pretty quickly get up to speed. Fusion360 has sketch and direct modeling, but is way, way more complex with tons of features.
I do agree kids (and me for that matter) want to be able to import mesh objects to use as basis for dimensioning, etc. The issue is the OS is mostly based on you designing something and handing it off to someone to manufacture "for real" rather than I am my own CAM shop with a 3D printer or X-Carve.
henry_feldman calls "successive approximation," and productivity gains that come from a library of template objects. So I continue to contend that there's value in both perspectives -- the precision and rigor of MCAD, along with the explorative, mesh-able, and fully 3D nature of Tinkercad and its ilk. Can we also agree that there's synergy in a hybrid system that supports both? If not, then which of the OnShape improvements I've suggested above would you argue as a waste of resources?
BTW, I would also challenge the assertion of
henry_feldman that Tinkercad isn't used for "real" projects. It is. I use it to design lighting fixtures and know other several industrial and product designers for whom Tinkercad is their primary design tool. That said, I'm sure many of us would readily move to a hybrid tool like OnShape with the capabilities I'm suggesting. In a heartbeat!
Really great comments from all. This is a strong, diverse and open community.
- Bob
Dries
www.keyshot.com
As for learning from failure (successive approximation), here is my thought. I am a physician and and my medical school class was the last class at NYU to perform manual gram stains of bacteria in class. They taught us this, not so that we would ever do it again (we don't, it's all automated) but so that we would understand the failure modes (and my god could we create failures - there is a reason they don't let us do it
Right now, in my lab, I am redesigning the classic Finnocietto sternal retractor (the thing we use to crank open your rib cage for open heart surgery) and had my summer high-school student interns do the modeling of the current one (they were CAD familiar from school) so that we could start to do the redesign; they were incredibly fast to a finished design on screen. They were used to the successive failure model of learning. The problem was their failures were the parts didn't mesh. The rack-and-pinion didn't mesh properly, the teeth weren't chamfered properly and the slider driven by the crank didn't fit correctly (they used sketchup). Sure they might have eventually gotten to the correct answer (they had a reasonable looking model on screen, but when 3D printed it didn't work because of imprecise dimensioning and more important inter-part constraining).
Not sure what we learned from that other than precision parts need precision. And as they fixed some of the dimensions (hard to do since it wasn't sketch based there wasn't a lot of inter-part constraining, and each iteration through the printer takes forever). That is a different learning-from-failure than mine, when I redesigned the part using OS with precise measurements on sketches, I had failures of purpose. My parts meshed perfectly, but in use with my thoracic surgical colleagues on test ribs (also 3D printed), we decided the new design didn't quite work due to some clearances and shapes of the blades getting in the way of their instruments. This is where real learning came about. We learned a lot about what angles surgeons can really work at, and how that surgery is performed; and we are iterating over the design learning at each stage. To me this is learning from failure, by using failure to expose gaps in knowledge of the underlying problem, not producing things that don't work because you didn't use the right tool.
Fusion360 has a very strong powerful set of direct manipulation tools and can do full sketch style mCAD in the same document. And of course with full application of constraints you can produce high-precision projects in Fusion360, but it is very easy (and we all know that teenagers will take the shortcut) to produce something that looks good but in fact is so imprecise as to be useless.
This is also similar to the 2 philosophies of teaching kids to ride bikes: some parents use training wheels while others use the no-pedals approach. It's true the kids with training wheels instantly start riding their bike and have low anxiety but don't learn balancing (high-satisfaction/low-precision) while the kids with no pedals are more frustrated having to flintstone around, they learn balancing very quickly (with the backup that their feet are free to prevent falls) and ultimately are better early bikers albeit with more early anxiety and likely early failures.
I agree that better data management is essential and has a long way to go and I have to assume they are working on that.
I guess I'd just have to say that I suspect Onshape is unlikely to allocate limited resources on "dumbing down" a powerful product in order to entice a market that is not a primary target.
# 1 You can't please everyone all of the time.
# 2 Use the right tool for the job at hand.
Kids learn to ride a bike by using training wheels and then eventually taking them off. One day they might learn to ride a Harley. No one suggests that we should create a hybrid Harley with training wheels on it in order to attract people who haven't learned to ride a bike yet.
I guess there is a significant difference between "Makers" and Real Engineers (tm) that may not be obvious. I'll have to rant about that later.
I suspect that packages like Tinkercad use primitives because they lack the sketch functionality, not because primitives are better.
I find using drag handles to adjust things to be imprecise, tedious and frustrating. It is a "manual" process that feels like I'm building "by eye". That's why the parts didn't fit together.
An essential element of parametric modeling is handling changes. In Bob's rounded box video, you plop down a box, create a smaller box, position it inside the first box and subtract to make it hollow. What happens when you want to change the size of the box? How about changing the wall thickness? How do you ensure that the lid re-sizes when you change the box?
One area of OnShape that I've struggled with relates to some oddities in its equation syntax. OnShape's equation support includes an awareness of units, such as distance, area and volume. I've posted previously about how I believe the grammer related to units needs to be updated in order to remove these oddities. What I refer to is surprising and counter-intuitive syntax like (#a + #b) + millimeters, or where syntax accepted by almost every programming language since Algol was released some 50 years ago may generate an error if the units of 2 variables are in the same domain (e.g. length) but assigned different units of measure (e.g. inches and meters) results in an error, as in: #a + #b
I can imagine that most OnShape old-hands respond to my depiction of this syntax as a problem with some scorn. Some may again say that there aren't sufficient resources to "dumb down" a powerful product like OnShape and that those resources are and should remain focused on new, even more powerful features ME's can appreciate and take advantage of. But let me give you one slice of an educator's perspective.
In choosing the tools to use in the creation of a engineering, innovation and design course, one of a curriculum designers' primary goals in to create an inclusive "path to success" for every student. The students that I teach such a class to have never used Solidworks or AutoCAD. (Some of them weren't even BORN when Solidworks was initially released.) Teachers like myself have only an hour to an hour and a half, at most, per class. So we can't afford to lose time explaining the idiosyncrasies of each tool. If a student does encounter an error, like using incorrect equation syntax for the tool, they must see a clear and informative message explaining what's wrong. If they don't then the instructor loses valuable classroom time. The stakes are even higher when an error is encountered outside the classroom when students are working on deadline and on their own.
The Catch-22 that I'm seeing in my limited experience with OnShape is that the company doesn't feel that it has the resources to "dumb down a powerful tool" so that it's accessible to up and coming engineering students, yet teachers can't find a wide enough path to success that they need to commit to curriculum development based on OnShape.
I'm stuck. I like the rigor that OnShape brings to design. I like that the site is always up, always responsive -- a rarity as every other product transitions their codebases to the cloud without full appreciation of the operational implications.
I'll come back to revisit OnShape again in the fall to see if there's been any movement toward educators' perspectives.
- Bob
It combines both parametric and direct modeling methods into a single environment.
Aerospace Research & Development Group, LLC
www.aerornd.com
CAD tools are tools and which one you use depends on the context and task. If I'm hammering, I select the mallet, sledge, ball-peen, roofing or geologists hammer as appropriate to the task. Likewise, if I'm arting, I select the medium that lets me express what I want to express. When I'm working with geometry, I select the best tool available for the job. Whether that is modeling clay, a mesh based modeler, a brep based modeler, or something else depends...
You seem to be here because you have not found suitable tools to do what you want yet. Welcome! There's a strong possibility that these are also not suitable tools.
I guess it depends on what you are trying to teach to your students. Were I to teach a class in 3D computer geometry creation to makers and artists (of any age) I think I'd focus more on the approaches available and strengths and weaknesses of each. An individual can get tool specific education on their own (or seek out the training/tutorials that suits their learning style).
I completely understand the desire to simplify the interface so that the student can learn one thing at a time. If you believe this is truely important for your course, you are in luck. The front-end of Onshape is html+javascript and you or someone you hire can tweak it for you pretty easily.
For instance, to remove buttons (distractions) from the interface, you can install a plugin called 'stylish' to firefox or chrome and add the following CSS to remove the Draft tool.
os-tool[tool-id="server:::Draft"]{
or remove the whole toolbar subsectiondisplay: none;
}
os-toolbar div:nth-child(3){
It doesn't get any easier than that....display: none;
}
However, I prefer natural complexity when teaching. I found that kids I was teaching had no problem with dealing with the complexity of Maya for instance. They used the 4 buttons I showed them (out of the tens showing on screen) and created a castle and forest out of unmodified spheres, cylinders and cubes. The one kid who was actually interested asked 'and what does that button do' and got to learn as deeply as he wanted.
Regarding the variables, I'd expect this to evolve over time as equations and parameter tables are an area that's still in need of development in onshape.
Using the '#' as a variable indicator is an odd choice for me too. I feel like the author really meant to type '$', had a heart attack, and no one noticed. I'm really curious of the origin of using '#' if anyone inside @support knows.
However I side with Ilya regarding the units syntax.
Anyway, I've run out of commentary. I'm curious to see if your curriculum has evolved when you come back in the fall.
Remember how much you loved Solidworks when it fist came out? Beyond pricing, probably the biggest long-term challenge that's developed in Solidworks' place in the market is how it's fallen apart at the ends. It's quirky and inefficient. Users no longer view it as able to innovate.
I suggest that the way it got that way is very similar to what I'm hearing from both users and OnShape developers in these forums. Putting in the effort to evolve the user experience doesn't seem to be valued enough to invest in. "It works," people say, "Don't dumb it down." So you end up with a frumpy app with low productivity that newcomers can't relate to -- which is the essence of what I'm complaining about today. Play that forward 10 or 20 years and you end up with a shrinking, unenthusiastic user base and competition sprouting all around.
- Bob